Jak se starat o WP a nezmagořit

Když jsem před lety vymýšlel koncepci WP-admin.cz, stanovil jsem si některé principy, podle kterých by měl tým k práci přistupovat. Snažil jsem se, aby se z nich staly společné hodnoty.

I když to nemusí každému sedět, pořád si myslím, že jsou dobré a platné pro všechny adminy či webmastery. Tak je tady dnes zmíním.

Komfortní zóna pracovní kopie

V principu nechci být vystavován stresu nebo tlaku a tak chápu, že každý admin se tomu rád vyhne. Než by se pouštěl do rizikové aktualizace, tak ji ignoruje nebo prohlásí za good enough. Nebo má jiný důvod, proč neaktualizovat.

To nemohu přijmout, protože si myslím, že to naráží na principy celé webmasterské práce, kterou se snažíme poctivě dělat. Obrázek níže je dnešní a je to vcelku velká a zavedená firma. Používá WordPress 4.7.26, protože správce IT neví(?), že se má aktualizovat. Děsí mě ta pravěká jQuery.

Výpis aplikací Wappalyzer
Na současném webu běží WordPress 4.7.26, který vytváří technický dluh

Pracovní kopie webu (podomácku devel) má být co nejvíce podobná produkční verzi, ale není třeba mít stejný uživatelský obsah – důležité je mít stejný technický základ. A tady zkoušet aktualizace, testovat výsledek nebo vyvíjet novinky.

Když se při updatu něco potentuje, nemusíte obnovovat zálohy. Uděláte si nový devel, resp. můžete v klidu zvyšovat svou odbornost tím, že najdete a opravíte příčinu. Je to sice pracnější a delší cesta, ale pak vás nezaskočí budoucí problémy.

Přínos: Nejste překvapeni něčím, co bylo patrné předem.

Koleje ověřených postupů

Z předchozího vyplývá základní postup – nejprve zkoušet na develu, pak to provádět na ostrém. Jednoduchá logika, která zachraňuje.. no životy ne, ale psychiku a nervy. Náš postup je

  • sledovat vývoj a u kritických pluginů changelog nebo jejich newslettery,
  • update develu, ideálně automaticky,
  • technická a vizuální kontrola (ideální by bylo automatizované testování, ale je to velmi nákladné, tak testujeme „osvědčená“ místa),
  • domluvit servisní okno se zákazníkem (tedy dobu, kdy drobná odstávka vadí nejméně),
  • teprve potom vyběrový a krokový update ostrého, tj. od bezproblémových pluginů k těm problémovým.

Jen velmi zřídka se stane, že se v takovém postupu něco nepovede. Pokud k tomu dojde, snažíme se o opravu, případně vrácení původní verze pluginu, pokud to lze a máme ji k dispozici. Jsou to výjimky, proto nemusíme nic vracet ze záloh nebo celý systém vracet pomocí některého z pluginů pro staging. Stává se to velmi zřídka.

Obtížně se předem testují platební brány nebo jiné ostré procesy. A také pluginy dodavatelů, kteří nejsou ochotní dát k dispozici vývojářskou licenci a začali blokovat použití pluginu bez aktivní licence na jiném webu.

Přínos: Postupy vás nesou procesem, nezmatkujete a máte postup zejména pro situaci, kdy se něco nepodaří.

Neživit technický dluh

Technický dluh je moje fráze roku 2023, mám ji rád. 🙂 Není to jen stará verze WordPressu. Řadím tam celý sloupec vzájemně závislých aplikací nebo vrstev. Pokud máte něco z následujících, pak si vytváříte nebo už máte technický dluh:

  • staré PHP (aktuálně cokoliv starší než 8.2),
  • starý WordPress a tedy staré jeho součástí jako jQuery (viz první obrázek),
  • (vámi) neaktualizované nebo (autorem) opuštěné pluginy jako České služby,
  • duplicitní pluginy nebo vícečetné instalace stejného pluginu (=chyba),
  • nefunkční javaskripty, které plní konzoli chybami (neexistují, expiroval jejich přístup, jsou špatně volané),
  • zastaralé knihovny uvnitř šablony, což vůbec nemusí být vidět:
    • Bootstrap třeba verze 3 nebo 4 (aktuální je 5.3),
    • jQuery TimePicker a další podobné komponenty z jQuery UI,
    • Font Awesome z doby, kdy šablona vznikla,
    • slider, který je součástí šablony (sublicence)
  • technologicky nebo koncepčně staré pluginy: Klasický editor, Klasické widgety, různé další hebla pro zachování zpětné kompatibility a „starých dobrých časů“.

Snažme se toho zbavit a mít systémy moderní a aktuální. Někdy je třeba popřemýšlet, naprogramovat nebo něco úplně změnit. Ale to beru jako hlavní smysl naší práce.

Příklad: Registr ekonomických subjeků ARES změnil ke konci roku 2023 API a je to typický příklad (jejich) technického dluhu, který se přenášel i do našich aplikací.

Přínos: Technický dluh je drahý. Čím dřív ho odstraníte a vysvětlíte to majiteli webu, tím to bude méně drahé (nikoliv nutně levnější). Web je hladová bestie, kterou není radno podceňovat, pokud ji člověk nemá na strašení návštěvníků.

Tak co, máte nějakou takovou potvoru? 😃

Napsat komentář

Newsletter Rádce pro správce

Každou druhou středu rozesíláme část svého know-how, které jsme pracně získali během posledních let. Zadarmo každému, kdo má zájem stát se zkušeným správcem WordPressu. Není určený našim zákazníkům, nýbrž našim kolegům v oboru. Vracíme tak komunitě to, co jsme získali od jiných. Podívejte se do jeho archivu.