WordPress plugin na míru se vyplatí tehdy, když má řešit konkrétní, opakující se práci, kterou dostupné řešení nepokrývá rozumným způsobem. Třeba předávání poptávek do interního systému, schvalování požadavků nebo import dat podle vlastních pravidel. Samotný počet nainstalovaných pluginů bych jako důvod pro nový vývoj nebral.
Při rozhodování doporučuji porovnat tři možnosti: nastavit hotový plugin, rozšířit ho o chybějící funkci, nebo vytvořit vlastní řešení. Každá z nich má své místo.
Kdy bych zůstal u hotového pluginu
Pokud potřebujete běžný kontaktní formulář a vybraný plugin umí všechna požadovaná pole, odeslání i ukládání zpráv, začal bych jeho nastavením. Psát stejnou funkci znovu jen proto, aby byla „na míru“, nepovažuji za dobré zadání.
U konkrétního řešení bych si předem ověřil:
- Zda potřebná funkce existuje přímo v pluginu, nebo vyžaduje další placené rozšíření.
- Jak se data ukládají a jak je lze získat při změně řešení.
- Zda dokumentace odpovídá tomu, co potřebujete, a jak probíhá podpora.
- Co bude každý den dělat člověk v administraci a kolik ručních kroků mu zůstane.
Pokud plugin vašemu postupu vyhovuje a jeho podmínky vám dávají smysl, vlastní vývoj nemusí nic podstatného přinést.
Někdy stačí rozšířit to, co už funguje
Mezi hotovým pluginem a kompletním vývojem existuje užitečná prostřední cesta. Formulář například dál zajišťuje zavedený nástroj a malý vlastní plugin řeší pouze předání dat do firemního systému.
WordPress k propojování a úpravám chování používá takzvané hooks: předem určená místa, na která se může další kód napojit. Rozlišuje akce a filtry; jejich princip popisuje oficiální dokumentace WordPressu. U konkrétního pluginu je potřeba ověřit, zda potřebné napojení skutečně nabízí a jaké údaje poskytuje.
Doporučuji oddělit vlastní rozšíření od souborů původního pluginu a popsat, na čem závisí. Při budoucí úpravě pak bude jasné, která část patří vašemu webu a která dodavateli hotového řešení.
Kdy vlastní plugin dává smysl
O vlastním vývoji bych uvažoval ve chvíli, kdy umíte přesně popsat pravidlo, které má web dodržovat, a současné řešení vás nutí pravidelně ho obcházet. Například přijatý požadavek musí projít schválením, podle vybrané služby se má předat jinému týmu nebo se mají importovaná data kontrolovat proti vašemu katalogu.
Dobrým podkladem je i seznam opakovaných ručních úkonů: co kopírujete mezi systémy, co kontrolujete v tabulce a kde musíte po každém odeslání zasáhnout. Ne každý takový úkon je nutné automatizovat. Pomůže ale určit, která část vám skutečně překáží.
Plugin je samostatné rozšíření funkcí WordPressu. Může být malý i rozsáhlý; vlastní plugin nemusí znamenat přestavbu celého webu. Základní princip shrnuje WordPress Plugin Handbook.
Příklad: poptávka, která nekončí v e-mailu
Představte si modelovou situaci: firma přijímá přes web servisní požadavky. Zákazník uvede typ zařízení, pobočku a popis problému. Pracovník pak údaje přepisuje do interního systému a vybírá odpovědný tým. Jde o ilustrační příklad, ne o popis konkrétní zakázky.
Zadání vlastního rozšíření by mohlo znít takto: po odeslání formuláře vytvořit požadavek v interním systému, podle pobočky přiřadit tým a do administrace webu uložit výsledek předání.
Tím ale zadání nekončí. Před vývojem bych chtěl znát odpovědi i na tyto otázky:
- Co se má stát, když interní systém právě neodpovídá?
- Jak obsluha pozná, že se požadavek nepředal?
- Jak se zabrání dvojímu založení při opakovaném odeslání?
- Kdo může chybné předání zkontrolovat a zopakovat?
Právě takové situace doporučuji zahrnout do zadání i testování. Samotné úspěšné odeslání jednoho formuláře ještě neověří celý pracovní postup.
Co od vývoje na míru neočekávat automaticky
Označení „na míru“ bych nebral jako záruku rychlosti, bezpečnosti ani bezúdržbového provozu. Vyžádal bych si popis testování, potřebných oprávnění a následné péče. Vlastní kód potřebuje promyšlený návrh stejně jako hotový produkt.
Pokud vás trápí pomalý web, začal bych měřením konkrétních stránek a hledáním příčiny. Rozhodnutí nahradit plugin bych dělal až podle výsledku, ne podle počtu položek v administraci.
Součástí návrhu má být také způsob rozšiřování WordPressu. Jeho dokumentace výslovně doporučuje neměnit soubory jádra, protože je aktualizace přepisují; doplňkové funkce mají řešit pluginy. Viz úvod do vývoje pluginů.
Co si domluvit před vývojem a při předání
U nabídky na vlastní plugin doporučuji posuzovat nejen popis hlavní funkce, ale i to, co dostanete při předání a kdo se bude řešení věnovat dál:
- Rozsah: co plugin provede, co už do zadání nepatří a podle čeho se ověří dokončení.
- Závislosti: které další pluginy a externí služby potřebuje a kdo zajišťuje přístupy.
- Testování: běžný průchod i dohodnuté chybové situace na testovací kopii webu.
- Předání: instalační balíček, zdrojový kód, návod k nastavení a popis důležitých vazeb.
- Další provoz: kdo ověřuje kompatibilitu po aktualizacích a jak se řeší nové požadavky.
U propojení s externí službou bych navíc oddělil práci na vašem webu od případných změn na straně této služby. Její dostupnost a možnosti je potřeba ověřit před slíbením konkrétní funkce.
Pošlete postup, který vám dnes zdržuje práci
Pro první posouzení nepotřebujete hotovou technickou specifikaci. Stačí odkaz na web, popis současného postupu a výsledek, kterého chcete dosáhnout. Pokud používáte konkrétní plugin nebo potřebujete napojit další systém, připojte jeho název a odkaz na dokumentaci.
Věnuji se vývoji WordPress pluginů a integrací na míru. Popište mi, co dnes řešíte ručně, a projdeme, zda stačí nastavení, menší rozšíření, nebo vlastní funkce.
