Nejprve přesně reprodukujte chybu a zkontrolujte PHP i konzolové logy. Na stagingu přepněte na základní šablonu a pluginy testujte systematicky, ne na produkci. Potvrďte konkrétní dvojici, verze a scénář, poté aktualizujte, upravte integraci nebo zvolte náhradu a proveďte regresní test.
Konflikt pluginů ve WordPressu vzniká, když dvě komponenty očekávají odlišné verze knihovny, mění stejný hook, načítají překrývající se skript nebo pracují s nekompatibilním formátem dat. Projevem může být nefunkční editor, pokladna, chyba JavaScriptu i výrazné zpomalení. Vypnutí náhodného pluginu může web dočasně opravit, ale bez reprodukce nevysvětlí, která kombinace a podmínka problém způsobila.
Diagnostika musí chránit produkční objednávky, formuláře a návštěvníky. Proto se provádí na stagingu se stejnými verzemi a reprezentativními daty. Změny se provádějí po jedné nebo systematickým dělením množiny a každý krok se zaznamenává. Cílem je minimální reprodukční případ, který lze opravit, nahlásit autorovi nebo bezpečně nahradit.
Definujte reprodukovatelný projev
Zapište URL, roli, zařízení, vstupy a očekávaný výsledek. Rozlište, zda chyba vzniká při načtení, kliknutí, uložení nebo naplánované úloze. Pořiďte snímek konzole, síťového požadavku a PHP logu s časem. Zkontrolujte, zda problém začal po konkrétní aktualizaci, ale nepředpokládejte automaticky, že naposledy změněný plugin je jedinou příčinou.
Vyčistěte pouze relevantní cache a zopakujte test v anonymním okně. Pokud chyba závisí na přihlášení, vytvořte testovací účet se stejnou rolí. U e-shopu používejte testovací platbu a produkt, ne skutečnou objednávku zákazníka. Dokud scénář nelze zopakovat, každé vypnutí komponenty poskytuje jen slabý důkaz.
Vytvořte staging shodný s produkcí
Kopie potřebuje stejnou verzi PHP, WordPressu, aktivní šablony, pluginů, konfigurace a relevantních dat. Rozdíl v cache, CDN nebo serverovém modulu může konflikt skrýt. Produkční API klíče, e-maily a platby nahraďte bezpečnými testovacími hodnotami. Staging chraňte před indexací i veřejným přístupem.
Před testem zaznamenejte aktivní verze a exportujte konfiguraci. Pokud se chyba na stagingu neprojeví, porovnávejte prostředí místo okamžitého experimentování na produkci. Může jít o souběh, reálný objem nebo obsah uložený v cache. Během diagnostiky nepovolujte automatické aktualizace, které by měnily základ pod rukama.
- Shodné verze a serverové prostředí
- Bezpečné testovací integrace
- Chráněný staging bez indexace
- Zmrazené automatické změny během testu
Izolujte šablonu a pluginy systematicky
Nejprve ověřte konflikt s šablonou pomocí podporované výchozí šablony, pokud to web umožňuje. Poté deaktivujte polovinu podezřelé skupiny, zopakujte scénář a podle výsledku pokračujte v příslušné polovině. Binární postup je při velkém počtu rychlejší než zkoušení po jednom. Kritické závislosti deaktivujte společně nebo podle dokumentace.
Když najdete kandidáta, znovu zapněte ostatní komponenty a potvrďte, že chyba vzniká pouze v konkrétní kombinaci. Vyzkoušejte nejnovější kompatibilní verze a čisté výchozí nastavení na kopii. Konflikt může způsobovat i mu-plugin, vlastní snippet, serverová cache či rozšíření prohlížeče; inventura musí zahrnovat více než obrazovku Plugins.
Najděte technický bod střetu
PHP log a call stack ukážou stejnou funkci, třídu, typovou chybu nebo pořadí hooků. V prohlížeči hledejte duplicitní knihovnu, globální proměnnou, chybný požadavek a pořadí načítání. U CSS porovnejte selektory a specificitu. U REST API zkontrolujte endpoint, oprávnění, nonce a tvar odpovědi. Název pluginu v posledním rámci nemusí být příčinou.
Vytvořte minimální příklad s přesnými verzemi a kroky. Citlivé údaje odstraňte, ale zachovejte chybovou zprávu a konfiguraci potřebnou k reprodukci. Před nahlášením zkontrolujte dokumentaci a známé problémy uvedené autory. Neupravujte přímo zdrojový kód cizího pluginu; aktualizace by zásah přepsala a ztížila podporu.
- Call stack nebo chybný síťový požadavek
- Přesná kombinace verzí
- Minimální reprodukce bez citlivých dat
- Žádné přímé úpravy cizího pluginu
Vyberte opravu a chraňte ji testem
Upřednostněte oficiální aktualizaci, podporované nastavení nebo opravu přes zdokumentovaný hook. Pokud je potřeba dočasný kompatibilní plugin, udržujte ho malý, verzovaný a označený odkazem na původní problém. Někdy je bezpečnější opuštěnou komponentu nahradit. Rozhodnutí zohledňuje kritičnost dat, licenci, podporu a budoucí údržbu.
Po opravě otestujte původní scénář i související funkce, například editor, formulář, cache a mobil. Nasazení proveďte se zálohou a možností návratu, poté sledujte logy. Přidejte konflikt do matice kompatibility nebo do automatického testu, aby se při další aktualizaci nevrátil. Dočasné řešení odstraňte po oficiální opravě.
Časté dotazy
Mohu hledat konflikt vypínáním pluginů na živém webu?
Na kritickém webu není bezpečné náhodně vypínat platby, formuláře či cache. Vytvořte shodný staging a testujte tam. Zásah v produkci provádějte jen cílený, s plánem a po vyhodnocení dopadu.
Jak zjistím, který ze dvou pluginů je viníkem?
Ověřte, že každý funguje samostatně a chyba vzniká při společné aktivaci v konkrétním scénáři. Technicky najděte bod střetu v logu nebo požadavku. Oprava může náležet jednomu i oběma podle toho, který kontrakt je porušen.
Je bezpečné zůstat u staré verze pluginu?
Pouze jako krátkodobý řízený návrat po posouzení bezpečnostního rizika a kompatibility. Zaznamenejte důvod, blokujte automatickou aktualizaci vědomě a připravte termín oficiální opravy nebo náhrady.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
