Find en plugin- eller temakonflikt i WordPress uden at ramme live-sitet

Kort svar: Reproducer først fejlen med en fast URL, brugerrolle og handling. Klon derefter sitet til staging eller brug Health Check Troubleshooting Mode, som kun ændrer din egen session. Test med standardtema og kun nødvendige plugins. Aktivér de øvrige plugins i halve grupper, til den mindste fejlende kombination er fundet. Dokumentér versioner, logs og browserrequest, og rul alle testændringer tilbage.

Fagligt gennemgået: 2. oktober 2026

Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. En kontrolleret A+B-konflikt og isoleret normaltilstand er efterprøvet med Hostious Article Lab 1.4.1; produktionsfejl skal reproduceres med sitets faktiske komponenter og versioner.

“Det virker, når alle plugins er deaktiveret” er kun en grov observation. En brugbar konfliktanalyse skal vise hvilken kombination, hvilken handling og hvilket bevis der får fejlen til at forsvinde og komme igen.

Før du ændrer noget: Tag database- og filbackup. Brug staging til checkout, formularer, medlemskab, cache, sikkerhed og integrationer. Deaktivér ikke komponenter på live, hvis de beskytter eller behandler brugerdata/transaktioner.

Symptom, mulig årsag og afgørende kontrol

Symptom	Mulig konflikt	Kontrol, der kan afgøre det
500 eller kritisk fejl efter aktivering	PHP-funktion, class, hook eller versionskrav kolliderer	Samme request + fatal stack med mindste pluginpar
Editor/gem giver 401, 403 eller invalid JSON	Security-plugin, REST-filter, cache eller nonceflow	Network-route/body og sikkerhedslog ved samme timestamp
Knap eller checkout reagerer ikke	JavaScript-fejl, dobbelte globals eller delay/defer	Console-stack og assetliste før/efter kandidat
Layout bryder kun på bestemte templates	Temaoverride, builder-addon eller CSS-specificitet	Standardtema + samme plugins og DOM/CSS-sammenligning
Fejlen rammer kun anonyme	Sidecache, cookievariation eller optimeret asset	Frisk anonym request versus indlogget/cachebypass
Fejlen rammer kun cron/CLI	Runtime, hook eller manglende requestkontekst	Samme job i samme runtime med log og versioner
Funktionen virker med enten A eller B, men ikke begge	Ægte samspilskonflikt	A alene, B alene og A+B med identisk protokol

Tabellen er en hypoteseoversigt, ikke et facit. En Console-fejl i en tredjepartsfil kan være følgefejlen efter, at en anden komponent fjernede et DOM-element. Kræv derfor både en stabil komponentmatrix og et teknisk signal, før ejerskabet placeres.

1. Lås et reproducerbart testscenario

Skriv en kort testprotokol:

• URL og trin-for-trin handling;
• brugerrolle og loginstatus;
• forventet resultat;
• faktisk resultat;
• timestamp;
• relevant Network-request, Console-fejl eller loglinje;
• hvor ofte fejlen opstår.

Eksempel: “Som redaktør åbnes indlæg X, blok Y ændres, og Opdater klikkes. POST-requesten til route Z giver 403 hver gang.” Det er langt mere testbart end “editoren virker ikke”.

Hvis fejlen ikke kan gentages, skal du først undersøge cachevariant, timing, brugerdata eller ekstern integration. En konfliktmatrix uden stabilt symptom giver falske konklusioner.

2. Vælg staging eller Troubleshooting Mode

Staging er førstevalg, når testen kan skrive data, sende mail, kalde betalingsgateway, ændre filer eller påvirke cron. Blokér udgående mails/webhooks og brug testnøgler, så staging ikke kontakter kunder.

Health Check Troubleshooting Mode kan bruges til rene visnings- og adminproblemer. Moden deaktiverer plugins og skifter tema kun for din bruger/session; besøgende ser fortsat normal opsætning. Kontrollér alligevel, at den konkrete handling ikke har irreversible writes.

Tag før testen en liste over:

• aktivt tema + parent/child;
• aktive plugins og versioner;
• must-use plugins/drop-ins;
• PHP/WordPress-version;
• cache/CDN/objektcache;
• miljøtype.

I Health Check & Troubleshooting 1.7.1 startes sessionsmoden fra Værktøjer → Webstedssundhed → Fejlfinding på den testede installation. Kontrollér versionsnummer og sessionsindikator; menunavne kan variere med adminsproget. Åbn siden privat: besøgende skal fortsat se normal opsætning. Ellers stop og gendan.

3. Etabler en minimal baseline

På staging eller i Troubleshooting Mode:

1. Aktivér et kompatibelt WordPress-standardtema.
2. Hold kun det plugin aktivt, som funktionen absolut kræver.
3. Medtag dokumenterede afhængigheder, f.eks. baseplugin + addon.
4. Ryd kun relevant testcache.
5. Gentag den låste protokol.

Hvis fejlen stadig findes i minimal baseline, er “konflikt med et andet plugin” mindre sandsynlig. Undersøg selve pluginet, WordPress/PHP-kompatibilitet, data og serverlog.

Hvis fejlen forsvinder, fortsætter du med at tilføje komponenter systematisk.

4. Brug binær aktivering i stedet for én ad gangen

Ved 24 uafhængige plugins tager én-ad-gangen-metoden op til 24 runder. Binær søgning reducerer antallet:

1. Del de inaktive plugins i to grupper.
2. Aktivér gruppe A og gentag protokollen.
3. Hvis fejlen kommer, ligger årsagen i A eller samspillet med baseline. Del A i to.
4. Hvis fejlen ikke kommer, deaktiver A og test B.
5. Fortsæt, til én komponent eller en lille kombination er tilbage.

Plugin-afhængigheder må ikke splittes tilfældigt. Hold baseplugin/addons, WooCommerce/gateway eller builder/addon som navngivne grupper. Ellers kan du skabe en kunstig fejl ved at aktivere et addon uden dets base.

Gem resultatet for hver runde: aktive grupper, status, request/log og screenshot. Ændr ikke flere andre indstillinger undervejs.

Binær opdeling finder hurtigt en komponent, der udløser fejlen sammen med baseline, men den kan overse et samspil mellem én komponent i A og én i B, hvis ingen af grupperne fejler alene. Når en kandidat er fundet, skal du derfor altid teste kandidaten mod den fulde normale opsætning og derefter mod de mest sandsynlige ejere af samme funktion: cache, security, builder, formular, WooCommerce eller gateway.

Brug en matrix, der kan læses bagefter:

Runde	Tema	Baseline	Gruppe/kandidat	Resultat	Bevis-ID
0	Originalt	Fuld opsætning	Alle	Fejl	Request/log T0
1	Standard	Kun nødvendige	Ingen	Bestået/fejl	T1
2	Standard	Nødvendige	Gruppe A	Bestået/fejl	T2
3	Standard	Nødvendige	Kandidat X	Bestået/fejl	T3
4	Originalt	Fuld opsætning	Rettelse aktiv	Bestået	T4

Hvis du rydder cache, skifter bruger eller ændrer testdata mellem runder, skal det stå som en ny variabel i matrixen. Ellers kan resultatet ikke gentages.

5. Test temaet separat

Når pluginsættet er afgrænset:

• test standardtema + fejlende pluginsæt;
• test originaltema + samme pluginsæt;
• test child- og parent-tema efter dokumenteret metode;
• sammenlign template overrides og hooks;
• gentag den samme protokol.

Hvis fejlen kun opstår med originaltemaet, er det en tema- eller kombinationskonflikt. Det betyder ikke nødvendigvis, at temaet alene er “forkert”; plugin og tema kan bruge samme hook, JavaScript-global eller template på uforenelige måder.

6. Brug browser og logs til at forklare konflikten

Når den mindste kombination er fundet, skal teknisk bevis forklare mekanismen:

• PHP fatal/warning med fil og stack;
• REST/AJAX-request, der skifter status/body;
• JavaScript-fejl og stack;
• duplikeret event handler eller global;
• CSS/DOM-ændring;
• databasequery eller hookprioritet.

For JavaScript- og optimeringsproblemer tester du defer/delay/minify som en separat faktor. Slå én funktion fra på staging og se, om samme asset/request ændrer sig. Skriv den minimale exclusion – ikke en bred liste over alle scripts.

7. Vælg en permanent løsning

Prioritér i denne rækkefølge:

1. opdater til en version, hvor konflikten er dokumenteret rettet;
2. rul den seneste fejlende komponent tilbage midlertidigt;
3. erstat overlappende funktionalitet, så to plugins ikke ejer samme opgave;
4. brug leverandørens dokumenterede indstilling/hook;
5. lav kun en smal kodeændring med test og ejer, hvis ingen native løsning findes.

Lad ikke staging stå med “alle andre plugins deaktiveret” som løsning. Gendan den reelle konfiguration og bevis, at den valgte ændring virker i fuld kombination.

Husk komponenter, der ikke står på pluginlisten

Must-use plugins, drop-ins som objektcache, servercache, CDN/WAF, snippets og hostingspecifik bootstrapkode kan påvirke testen, selv om den almindelige pluginliste ser minimal ud. Registrér mindst mu-plugins, aktivt object-cache.php/advanced-cache.php, PHP-version og servercache som selvstændige matrixrækker.

På staging kan du teste en drop-in eller serverfunktion efter platformens dokumenterede metode, men undlad at omdøbe ukendte filer på live. En objektcacheændring kan påvirke alle sessionsbrugere og bør have sin egen purge-/rollbackplan.

Før/efter-test med genfremkaldelse

En stærk konklusion har fire trin:

1. Før: den låste protokol fejler mindst to gange med samme status/logsignatur.
2. Isolation: fejlen forsvinder i minimal baseline.
3. Genfremkaldelse: den vender tilbage, når den mindste dokumenterede kombination aktiveres.
4. Rettelse: den fulde normale kombination består mindst tre gange med valgt opdatering, indstilling eller rollback.

Mål ikke kun det synlige symptom. Ved checkout skal ordreantal, betalingstest og callback også kontrolleres. Ved formular skal du verificere både validering, lagring og den blokerede testmail. Ved cache-/frontendkonflikt kontrolleres både anonym, indlogget og mobil viewport. En rettelse, der flytter fatallen til et baggrundsjob, er ikke bestået.

Hvis konflikten kun er periodisk

Fastlås de variable, der ofte skifter: cache HIT/MISS, brugerrolle, dataset, browser, cronstatus og samtidige requests. Kør en lille serie med samme seed og tidsstempel. Hvis fejlen kun findes under samtidighed, skal udvikleren have antal parallelle requests og den fælles logsignatur; en almindelig én-request-test kan ikke afkræfte race conditions.

Hvis en ekstern API er nødvendig, brug leverandørens testmiljø eller en lokal stub, og registrér requesten uden hemmelige headers. En ekstern nedetid må ikke fejldiagnosticeres som plugin-konflikt, blot fordi deaktivering af integrationspluginet skjuler symptomet.

Verifikation

• Den låste testprotokol består mindst tre gange.
• Fejlen kan genfremkaldes ved at genaktivere den dokumenterede fejlende kombination på staging.
• Fuld normal plugin-/temaopsætning med rettelsen består.
• Anonym og relevant indlogget rolle er testet.
• Ingen ny PHP-/Console-/Network-fejl opstår.
• Form, login, cache, cron og handel testes, hvis berørt.

Rollback

Afslut Troubleshooting Mode og kontrollér den aktive liste. På staging gendannes database/filer eller den noterede komponentmatrix. I produktion gendannes tidligere version/indstilling, hvis rettelsen fejler. Fjern midlertidige snippets, testbrugere, mailsluser og gateway-testnøgler.

Hvad skal sendes til leverandøren?

Send:

• præcis protokol;
• WordPress/PHP/tema/pluginversioner;
• mindste fejlende kombination;
• anonymiseret fatal-/Console-/Network-bevis;
• om fejlen findes med standardtema;
• hvad der blev prøvet og rullet tilbage.

Send ikke adminlogin, databaseeksport eller en liste over 40 plugins uden testresultater.

Hvornår skal hosting eller udvikler hjælpe?

Er alle plugins slået fra og temaet skiftet ud, og fejlen stadig er der, ligger den under WordPress. Med dansk support døgnet rundt kan nogen læse serverloggen med det samme i stedet for, at du bruger en aften på det.

Hosting skal hjælpe, hvis konflikten afhænger af PHP-extension, servercache, WAF eller processgrænser. Udvikleren/pluginleverandøren skal hjælpe, når den mindste kombination og stack er dokumenteret. Hostious WordPress-support kan bygge den reproducerbare sag.

Sådan dokumenterer du en konflikt

Vis den mindste kombination, der skaber fejlen, og den tilsvarende normale tilstand:

1. Fast testscenario med forventet/faktisk resultat i staging.
2. Troubleshooting Mode-banner og sessionspecifik pluginliste.
3. Enkel konfliktmatrix med grupper A/B og testresultater.
4. Før/efter Network/Console/log for mindste kombination.

Gem versionseksporten, konfliktmatricen og den relevante request eller logstack. Fjern domæne, brugerdata, cookies, nøgler og interne stier.

Ofte stillede spørgsmål om konflikttest

Hvordan finder jeg hurtigst det plugin, der skaber fejlen?

Med binær søgning: deaktivér halvdelen af dine plugins, test, og halvér igen i den gruppe, hvor fejlen følger med. Så finder du synderen på få runder i stedet for at teste ét ad gangen.

Kan jeg teste for konflikter uden at påvirke mine besøgende?

Ja. Brug staging – eller Health Checks Troubleshooting Mode, der kun ændrer noget for DIN session, mens alle andre ser sitet normalt.

Hvad gør jeg, når jeg har fundet det fejlende plugin?

Tjek om en opdatering løser det, søg i pluginets support-tråd, og find eventuelt et alternativ. Genaktivér aldrig bare og håb – konflikten kommer igen ved næste sammenfald.

Læs også

• Hub: WordPress fejl og fejlfinding
• Kritisk fejl i WordPress
• Hvid skærm i WordPress
• WordPress REST API-fejl
• Staging i WordPress
• WordPress hosting hos Hostious – hosting hvor supporten kender WordPress