A Admatic StackDocumentation 5.14.2
Download stack DA

Admatic Stack

Dokumentation til release 5.14.2

Søg, installer, brug og reparer den koordinerede Elementor-stack til websiteproduktion.

Search

Navigér

Dokumentation

Installation

Stack-arkitektur

Brug af builderen

Design og medier

→ Fejlfinding

Opdateringer og vedligeholdelse

Versionsnote

Dette site dokumenterer stack 5.14.2. Stacken forventes at udvikle sig, så opdatér versionsmærket og ændrede procedurer, når en ny koordineret bundle udgives.

Fejlfinding

Find det første lag, der fejler, ret den præcise årsag, og fortsæt det samme projekt. De fleste fejl skyldes versioner, parring, midlertidige filer, mediereferencer, pakkevalidering eller renderet QA.

Start med det korrekte diagnostiske lag

1. Core health

Kontrollér Core-readiness, connector scopes, capability negotiation, projektstatus og status for det parrede site.

2. Staging preflight

Kontrollér komponentversioner, Elementor/Pro-parring, Worker-status, ZIP-understøttelse, OpenSSL, midlertidige filer, uploads og baggrundsjobs.

3. Workflowrapport

Læs det første fejlende trin, rækkerne i pakkevalideringen, screenshot-QA og blokeringer i release gate.

Almindelige fejl og rettelser

Installer de præcise koordinerede staging-versioner. Ved false-mismatch-problemet i 5.14.2 skal central Core erstattes med 2.14.3, hvorefter alle health checks køres. Core sammenligner nu kontrakter semantisk og accepterer kompatible Core patch-releases inden for samme major/minor-linje.
Opdatér den licenserede Elementor Pro-pakke, så dens major/minor-version ikke er ældre end Elementor Core, og kør derefter preflight igen.
Åbn Remote Worker på staging, generér en ny kode, der gælder i ti minutter, indsæt pairing-bundlen under Core → Sites, og kør health checks igen.
Afbryd den forældede Worker-post, og par igen. Genbrug ikke en udløbet kode.
Konfigurér en skrivbar midlertidig PHP-mappe, og kontrollér, at WordPress kan oprette en midlertidig fil. Kør staging preflight igen.
Aktivér PHP ZipArchive, eller kontrollér, at WordPress-fallbacken PclZip er tilgængelig, før en pakke importeres.
Opdatér til den koordinerede Kit Factory-release, ryd browser- og WordPress-cache, genindlæs det moderne arbejdsområde, og kontrollér REST-workflowresponsen. Den aktuelle release indeholder null-sikker håndtering ved opstart af workflows.
Betragt ikke tallet alene som en design-score. Kontrollér, at global header/footer er godkendt, og at hver page section enten har evidens for en godkendt komponent eller en eksekverbar afgrænset native komposition.
Kontrollér, at filerne er kommet ind i Mediebiblioteket og det aktuelle projektmanifest, før du forlader siden. Tilknyt manglende aktiver igen med stabile referencer, og generér den aktuelle projektpakke på ny i stedet for at oprette et nyt projekt.
Reparer den præcise manglende reference på det samme Core-projekt. Core rapporterer den uafklarede nøgle, så mediemanifestet kan rettes uden at erstatte projektet.
Kontrollér, at project.json findes, at skemaet understøttes, at filtyperne er tilladte, at pakkestørrelsen er inden for grænsen, at lokale aktiver findes, at relative stier er gyldige, og at Elementor ikke bruger eksterne billeder uden lokal kopi.
Installer Chrome/Chromium lokalt, eller konfigurér det centrale Screenshot QA-endpoint. Advarsler om kun capture kan være vejledende, men manglende renderet sammenligningsevidens blokerer en referencebaseret release.
Læs den blokerende årsag. Ret den navngivne region, reference eller pakkefejl, og kør derefter det samme projekt igen. Poll det eksisterende workflow i stedet for kun at bygge igen for at kontrollere status.
Kontrollér, at Elementor Pro er aktiv, at sider bruger elementor_header_footer, at skabelonerne bruger header/footer-taxonomien og include/general-betingelser for hele sitet, og at de påkrævede frontend-markører findes.
Fjern negative margins og direkte positionering, angiv eksplicitte mobilbredder, og brug et Grid med én kolonne på mobil. Lad Elementors Flexbox Container-indstillinger for Wrap/No Wrap være tomme, medmindre et konkret design kræver en bevidst tilsidesættelse.

Det skal indsamles til support

  • Stackversion og hver koordineret komponentversion.
  • Eksplicit Core-projekt-ID og aktuel revision.
  • ID eller label for det parrede staging-site.
  • Workflow-ID og første fejlende trin.
  • Resumé af pakkevalidering og blokerende rækker.
  • Release-gate-status.
  • Screenshot-QA-rapport og fejlende regioner.
  • Core execution trace eller tilhørende diagnostikfil.
  • Den præcise manglende mediereference eller kontrakt-uoverensstemmelse.

Hold hemmeligheder ude af supportsager

Indsæt ikke OAuth-tokens, HMAC-hemmeligheder, private filsystemstier eller rå loginoplysninger. Core- og browserdiagnostik er udviklet til at maskere dem.

Sikre recovery-regler

  • Fortsæt det eksisterende eksplicitte projekt.
  • Dupliker ikke et projekt alene, fordi et build eller QA-pas fejlede.
  • Erstat ikke gemte medier, medmindre det refererede aktiv faktisk er forkert.
  • Brug det seneste change preview før et destruktivt rebuild.
  • Opret eller behold et recovery snapshot før erstatningsbuilds.
  • Poll det eksisterende workflow, indtil det når en slutstatus.

Når alle normale rettelser fejler

Det er tilladt at bruge AI-hjælp som Claude eller ChatGPT, og det kan hjælpe med at identificere det fejlende lag, fortolke logs, sammenligne versioner eller foreslå en sikker reparationsplan. Fjern loginoplysninger, tokens, hemmeligheder og private stier, før diagnostisk materiale deles, og verificér alle foreslåede ændringer, før de anvendes i produktion.