PHP

PHP patří mezi serverové programovací jazyky, které používám pro vývoj webových aplikací, zejména při práci s WordPressem, WooCommerce, vlastními API a aplikační logikou běžící přímo na serveru.

PHP používám k rozšiřování existujících platforem, vytváření vlastní funkcionality, zpracování požadavků, práci s databázemi, validaci dat a integraci externích systémů.

PHP pro mě není pouze jazyk, na kterém stojí WordPress.

Je to serverová vrstva, která umožňuje proměnit obsahově orientovaný web ve skutečnou aplikaci.

Jak používám PHP

PHP používám například pro:

• vývoj ve WordPressu,

• vlastní funkcionalitu ve WordPressu,

• úpravy WooCommerce,

• vlastní typy příspěvků a taxonomie,

• integrace Advanced Custom Fields,

• endpointy WordPress REST API,

• zpracování formulářů,

• validaci dat,

• databázové operace,

• integrace externích API,

• automatizaci,

• serverovou business logiku.

Většina mé práce v PHP souvisí s praktickým chováním aplikací, nikoli s izolovanými skripty.

PHP a WordPress

WordPress je jedním z hlavních prostředí, ve kterých PHP používám.

PHP řídí velkou část funkcionality WordPressu, včetně:

• šablon,

• pluginů,

• hooků,

• filtrů,

• template souborů,

• REST endpointů,

• vlastních obsahových struktur.

PHP používám tehdy, když projekt potřebuje funkcionalitu, kterou nelze nebo není vhodné realizovat čistě přes vizuální rozhraní.

Typická WordPress architektura může vypadat například takto:

WordPress
↓
PHP logika
↓
Custom Post Types / ACF / WooCommerce
↓
Bricks Builder
↓
Vyrenderovaný web

Vizuální vrstva řeší prezentaci.

PHP řeší chování na straně serveru.

Vlastní funkcionalita ve WordPressu

PHP často používám k vytváření cílené vlastní funkcionality místo instalace dalšího pluginu kvůli každému menšímu požadavku.

Může jít například o:

• vlastní shortcody,

• filtry,

• hooky,

• chování administrace,

• vlastní dotazy,

• transformace dat,

• REST endpointy.

Pokud to snižuje množství závislostí a zlepšuje udržovatelnost, preferuji malé a srozumitelné vlastní implementace.

WordPress hooky

Hooky jsou základní součástí vývoje ve WordPressu.

Pomocí actions a filters rozšiřuji chování bez úprav samotného jádra WordPressu.

Vlastní logika tak může reagovat například na:

• aktualizace obsahu,

• akce uživatele,

• změny objednávek ve WooCommerce,

• vykreslování stránek.

Hooky umožňují rozšiřovat WordPress a přitom udržet vlastní kód oddělený od samotné platformy.

Filtry

Filtry umožňují upravit existující hodnoty předtím, než je WordPress použije nebo vypíše.

Používám je pro cílené změny chování, například:

• úpravu generovaných dat,

• změnu chování dotazů,

• úpravu výstupu obsahu,

• rozšíření funkcionality pluginů.

Callbacky filtrů udržuji úzce zaměřené.

Callback, který provádí mnoho nesouvisejících operací, se rychle stává obtížně laditelným.

Vyhýbání se úpravám jádra

Pro projektově specifickou funkcionalitu neupravuji přímo soubory jádra WordPressu ani WooCommerce.

Soubory jádra se při aktualizacích přepisují.

Místo toho používám:

• hooky,

• filtry,

• vlastní pluginy,

• funkce na úrovni šablony tam, kde je to vhodné.

Díky tomu je implementace výrazně odolnější vůči budoucím změnám.

Vlastní pluginy

Jakmile je funkcionalita rozsáhlejší, preferuji její přesunutí do vlastního pluginu.

Tím odděluji aplikační logiku od prezentace.

Například:

Šablona / Bricks
→ prezentace

Vlastní plugin
→ business logika

Pokud se později změní design webu, základní funkcionalita může zůstat nedotčená.

functions.php

Pro menší a jasně ohraničenou funkcionalitu specifickou pro konkrétní web může být functions.php vhodným řešením.

Používám ho opatrně pro kód, který skutečně patří do aktivní prezentační vrstvy webu.

Jakmile logika roste, preferuji přesunutí znovupoužitelné nebo business-kritické funkcionality do samostatného pluginu.

Tím se zabrání tomu, aby se soubor šablony změnil v rozsáhlou kolekci nesouvisejících funkcí.

PHP a Bricks Builder

PHP používám společně s Bricks Builderem v situacích, kdy vizuálně vytvořené WordPress rozhraní potřebuje další logiku na straně serveru.

Může jít například o:

• vlastní dynamická data,

• dotazy,

• podmíněné chování,

• shortcody,

• REST komunikaci.

Bricks řeší uživatelské rozhraní.

PHP řeší chování, které patří na server.

PHP a Advanced Custom Fields

ACF poskytuje strukturovaná data uvnitř WordPressu.

PHP mi umožňuje tato data programově zpracovávat.

PHP může například:

• číst vlastní pole,

• validovat je,

• transformovat hodnoty,

• vytvářet vztahy,

• generovat odvozený výstup.

To je užitečné tam, kde strukturovaný obsah potřebuje víc než pouze jednoduché vykreslení šablonou.

Vlastní typy příspěvků

PHP používám k definování vlastních typů příspěvků tehdy, když má WordPress reprezentovat skutečné entity, nikoli pouze stránky a blogové příspěvky.

Příkladem mohou být:

• technologie,

• projekty,

• aplikace,

• produkty,

• lokality,

• dokumentace.

Vlastní typ příspěvku dává obsahu jasně definovanou strukturu a životní cyklus.

Díky tomu je WordPress mnohem použitelnější jako aplikační platforma.

Vlastní taxonomie

Taxonomie poskytují strukturovanou klasifikaci.

PHP používám k vytváření vlastních taxonomií v případech, kdy obsah potřebuje vztahy, jako jsou:

• kategorie,

• typy,

• technologie,

• stavy,

• regiony.

Vzniká tak skutečná informační architektura namísto spoléhání na ručně zadávané štítky.

WooCommerce

WooCommerce je další důležitou oblastí, ve které PHP používám.

Vlastní funkcionalita může zahrnovat:

• produkty,

• chování košíku,

• checkout,

• zpracování objednávek,

• vlastní metadata,

• automatizaci.

Používám WooCommerce API, hooky a doménové objekty místo vytváření zbytečných předpokladů o interním způsobu ukládání dat.

E-commerce logika musí zůstat kompatibilní s vývojem architektury platformy.

Zpracování objednávek

Události v životním cyklu objednávky často vyžadují vlastní chování.

Například:

Vytvoření objednávky
↓
Potvrzení platby
↓
Vlastní zpracování
↓
Vyřízení objednávky

Automatizaci vážu na smysluplné stavy objednávky, nikoli na návštěvu konkrétní stránky ve frontendu.

Samotná objednávka by měla zůstat autoritativním transakčním objektem.

WordPress REST API

PHP používám k vytváření a rozšiřování endpointů WordPress REST API.

Vlastní endpoint může:

• vracet strukturovaná data,

• přijímat vstup z aplikace,

• spouštět řízené operace,

• integrovat externí služby.

Typický tok může vypadat například takto:

Externí klient
↓
REST API
↓
PHP
↓
WordPress / databáze

WordPress díky tomu může fungovat jako backend pro další aplikace.

Návrh API

Při vytváření vlastních endpointů k nim přistupuji jako ke kontraktům.

Definuji:

• metody,

• přijímané parametry,

• validaci,

• oprávnění,

• struktury odpovědí,

• chování při chybách.

API by nemělo odhalovat libovolné detaily interní implementace.

Klient by měl dostávat stabilní a předvídatelné rozhraní.

Validace vstupu

Veškerý externí vstup považuji za nedůvěryhodný.

Hodnoty před použitím validuji.

To může zahrnovat kontrolu:

• očekávaného typu,

• povolených hodnot,

• povinných polí,

• rozsahů,

• identifikátorů,

• délek.

Validace odpovídá na otázku, zda je hodnota přijatelná.

Měla by proběhnout dříve, než se hodnota dostane k důležité aplikační logice.

Sanitizace

Sanitizace je samostatný problém odlišný od validace.

Vstup normalizuji podle jeho zamýšleného datového typu.

Příkladem mohou být:

• prostý text,

• e-mailové adresy,

• URL,

• celá čísla.

Nepoužívám jeden univerzální přístup k sanitizaci pro všechny typy vstupů.

S daty je potřeba pracovat podle jejich významu.

Escapování výstupu

Data, která lze bezpečně uložit, nejsou automaticky bezpečná pro vykreslení.

Při výstupu do HTML je escapuju podle kontextu.

Může jít například o:

• HTML text,

• atributy,

• URL.

Escapování patří na hranici výstupu.

Pomáhá tím předcházet zranitelnostem typu injection.

Prevence SQL injection

Když PHP komunikuje s databází, nespojuji nedůvěryhodný vstup přímo do SQL dotazu.

Používám:

• parametrizované dotazy,

• databázovou přípravu dotazů ve WordPressu,

• zavedená databázová API.

Struktura dotazu a externí data by měla zůstat oddělená.

Přístup k databázi ve WordPressu

Pro databázovou práci specifickou pro WordPress používám tam, kde je to vhodné, databázovou abstrakci platformy.

Vyhýbám se přímým databázovým dotazům v případech, kdy požadované chování už poskytuje vyšší WordPress API.

Vyšší API obvykle poskytují lepší kompatibilitu s:

• cache,

• hooky,

• budoucími změnami platformy.

Raw SQL používám tehdy, když řeší skutečný problém, ne jako výchozí řešení každé operace.

SQL

Dobrá znalost SQL zůstává důležitá i při backendovém vývoji v PHP.

SQL používám pro:

• filtrování,

• joiny,

• agregace,

• reporting,

• vlastní databázové operace.

I při použití ORM nebo API platformy výrazně usnadňuje ladění výkonu znalost toho, jak se podkladový dotaz skutečně chová.

Databázové transakce

U vícekrokových operací, kde by částečné dokončení bylo nebezpečné, zvažuji transakce tam, kde je podporuje použitá databáze a architektura.

Například:

Vytvoření záznamu
↓
Aktualizace souvisejícího stavu
↓
Zápis auditních dat
↓
Commit

Pokud jeden krok selže, operace by neměla nutně zanechat částečně dokončená data.

REST API

PHP může fungovat jako API server i jako API klient.

Používám ho k integraci externích služeb, jako jsou:

• platební poskytovatelé,

• datové zdroje,

• automatizační platformy,

• AI API.

Externí integrace z principu považuji za nespolehlivé.

Mohou:

• překročit časový limit,

• vrátit chybu,

• vrátit neplatná data,

• stát se nedostupnými.

Aplikace musí umět tyto situace zpracovat.

HTTP požadavky

Když PHP komunikuje s externími službami, zohledňuji:

• práci s timeouty,

• autentizaci,

• validaci odpovědí,

• opakované pokusy tam, kde dávají smysl,

• logování.

Nepředpokládám, že úspěšné TCP spojení automaticky znamená, že odpověď obsahuje platná aplikační data.

JSON

JSON je běžným formátem v PHP integracích.

PHP používám k:

• kódování strukturovaných odpovědí,

• dekódování vstupu z API,

• transformaci dat.

Dekódované struktury před použitím validuji.

Syntakticky platný JSON dokument může stále obsahovat neplatná aplikační data.

Autentizace

Serverové PHP aplikace často potřebují určit, kdo smí konkrétní operaci provést.

Ve WordPressu pracuji například s koncepty:

• přihlášených uživatelů,

• rolí,

• oprávnění (capabilities),

• nonces,

• API přístupových údajů.

Autentizace určuje, kdo uživatel nebo klient je.

Autorizace určuje, co smí dělat.

Tyto dva koncepty od sebe odděluji.

Autorizace

Přihlášený uživatel nemá automaticky oprávnění provádět každou operaci.

Před citlivými akcemi používám kontrolu capabilities a aplikačně specifická pravidla.

To je obzvlášť důležité pro:

• administrativní endpointy,

• úpravy obsahu,

• uživatelská data,

• e-commerce operace.

Autorizace patří na server.

Nonces

Ve WordPressu poskytují nonces ochranu proti nechtěným cross-site požadavkům v relevantních autentizovaných workflow.

Používám je tam, kde s nimi platforma počítá.

Nonce nenahrazuje kontrolu oprávnění.

Důležitá je legitimita požadavku i samotná autorizace.

Tajné údaje

API klíče, hesla a soukromé přístupové údaje by neměly být vložené do veřejného frontendového kódu.

PHP je v tomto ohledu užitečné, protože citlivá integrační logika může zůstat na serveru.

Například:

Prohlížeč
↓
Můj server
↓
Externí API

Prohlížeč nepotřebuje přímý přístup k tajnému přístupovému údaji.

Konfigurace prostředí

Tam, kde je to vhodné, odděluji konfiguraci od aplikační logiky.

Hodnoty, jako jsou:

• API přístupové údaje,

• endpointy specifické pro konkrétní prostředí,

• debugovací nastavení,

by neměly být roztroušené po zdrojovém kódu.

Díky tomu je nasazení bezpečnější a konfigurace se snáze spravuje.

Zpracování chyb

Selhání na straně serveru vyžadují řízené zpracování.

Mezi možné problémy patří:

• neplatný vstup,

• chybějící data,

• databázové chyby,

• selhání externích API,

• chyby oprávnění.

Vyhýbám se zobrazování syrových technických chyb přímo uživatelům.

Aplikace může vrátit užitečnou uživatelskou hlášku a současně zachovat dostatek technických informací pro diagnostiku.

Logování

Logování je důležité pro ladění backendu.

Logy používám k pochopení událostí, jako jsou:

• neúspěšná volání API,

• neočekávané hodnoty v požadavku,

• selhání integrací,

• chyby zpracování.

Vyhýbám se logování tajných údajů nebo zbytečných osobních informací.

Užitečný log by měl vysvětlit selhání, aniž by současně vytvářel další bezpečnostní problém.

Defenzivní programování

PHP píšu s předpokladem, že se dříve či později objeví neočekávané stavy.

Například:

• pole může chybět,

• externí API může být offline,

• plugin může vrátit neočekávaný výsledek,

• uživatel může odeslat neplatná data.

Předpoklady kontroluji na hranicích systému místo toho, abych nechal chyby nepředvídatelně propagovat dál.

Null a chybějící hodnoty

Externí nebo volitelná data často obsahují chybějící hodnoty.

Rozlišuji mezi:

• povinnými daty,

• volitelnými daty,

• neplatnými daty.

Preferuji explicitní zpracování namísto spoléhání na to, že neočekávaný stav později odhalí notice nebo warning.

Typové deklarace

Moderní PHP podporuje typové deklarace pro:

• parametry,

• návratové hodnoty,

• vlastnosti.

Tam, kde to dává smysl, je používám ke zpřehlednění kontraktů funkcí.

Například:

function calculateTotal(float $price, int $quantity): float
{
    return $price * $quantity;
}

Typy zlepšují čitelnost a pomáhají odhalit nesprávné použití dříve.

Strict types

V codebasech, kde to odpovídá architektuře, může striktní typování zvýšit předvídatelnost chování.

Důležitá je především konzistence.

Částečně typovaný projekt s nejasnými konvencemi může být matoucí více než jasně definovaný styl.

Třídy

Třídy používám tam, kde k sobě přirozeně patří chování a stav nebo kde komponenta potřebuje jasnou znovupoužitelnou hranici.

Příkladem mohou být:

• integrace služeb,

• repozitáře,

• business logika,

• vlastní WordPress komponenty.

Nevytvářím třídy jen proto, že objektově orientovaný kód působí sofistikovaněji.

Struktura by měla řešit skutečný problém s udržovatelností.

Rozhraní

Rozhraní jsou užitečná tam, kde má více implementací dodržovat stejný kontrakt.

Mohou zlepšit:

• testovatelnost,

• zaměnitelnost implementací,

• oddělení odpovědností.

Aplikační logika například může záviset na rozhraní služby místo na jedné konkrétní implementaci externího poskytovatele.

Správa závislostí

U větších PHP projektů je správa závislostí důležitá.

Preferuji explicitně definované a kontrolované závislosti.

Každá knihovna přináší:

• další kód,

• požadavky na aktualizace,

• další bezpečnostní plochu,

• potenciální problémy s kompatibilitou.

Závislosti přidávám tehdy, když přinášejí skutečnou hodnotu.

Composer

Mimo čistě WordPress prostředí nebo souběžně s ním poskytuje Composer standardní mechanismus pro správu PHP závislostí a autoloading.

Správu závislostí používám tak, aby knihovny třetích stran byly verzované a reprodukovatelné.

Pokud existuje správný workflow správce balíčků, vyhýbám se ručnímu kopírování náhodných souborů knihoven do projektu.

Namespaces

Namespaces pomáhají organizovat větší PHP projekty a předcházet kolizím názvů.

Používám je tam, kde to velikost a struktura projektu odůvodňují.

Obzvlášť užitečné jsou u vlastních pluginů nebo samostatného backendového kódu s více komponentami.

Autoloading

U větších objektově orientovaných projektů udržuje autoloading správu souborů přehlednější.

Třídy lze načítat podle definovaných konvencí namísto velkého množství ručních volání require.

To zlepšuje organizaci projektu a usnadňuje orientaci v závislostech.

Oddělení odpovědností

Preferuji oddělování oblastí, jako jsou:

Zpracování požadavku
↓
Validace
↓
Business logika
↓
Perzistence / externí služby
↓
Odpověď

Smíchání všech těchto odpovědností do jediné funkce komplikuje budoucí změny.

Přesný počet vrstev závisí na velikosti projektu.

Do jednoduchého kódu nepřidávám zbytečnou architekturu.

Business logika

Business pravidla by neměla být skrytá uvnitř prezentačních šablon.

Pokud například aplikace potřebuje rozhodnout, zda je určitá akce povolená, mělo by toto pravidlo žít ve znovupoužitelné serverové komponentě.

Stejnou logiku pak lze použít z:

• webové stránky,

• REST endpointu,

• automatizace.

Šablony

PHP šablony by se měly soustředit především na prezentaci.

Snažím se nevkládat složité databázové dotazy a aplikační logiku přímo do šablon.

Pokud zůstanou prezentační soubory jednoduché, celý systém je výrazně srozumitelnější.

Server-side rendering

PHP se přirozeně hodí pro server-side rendering.

Server může vytvořit kompletní HTML ještě předtím, než se odpověď dostane do prohlížeče.

To je stále užitečné například pro:

• obsahové weby,

• SEO,

• rychlé počáteční vykreslení,

• progressive enhancement.

Ne každý projekt potřebuje rozsáhlou klientskou JavaScript aplikaci.

PHP a JavaScript

PHP a JavaScript mají v mnoha mých webových projektech odlišné odpovědnosti.

Typické rozdělení je:

PHP
→ serverová data a business logika

JavaScript
→ interakce v prohlížeči

Obě vrstvy mohou komunikovat prostřednictvím REST API nebo vyrenderované konfigurace.

Citlivou serverovou logiku nepřesouvám do JavaScriptu jen proto, že rozhraní JavaScript používá.

AJAX a asynchronní rozhraní

Některá WordPress rozhraní potřebují asynchronní aktualizace bez načtení celé stránky.

Serverové PHP mohu kombinovat s JavaScriptem v prohlížeči například pro:

• filtrování,

• formuláře,

• dashboardy,

• nástroje ve stylu aplikace.

U novějších strukturovaných integrací obecně preferuji jasně definované REST endpointy před ad-hoc request handlery tam, kde se tento přístup hodí.

Výkon

Výkon PHP závisí na více faktorech než pouze na samotném jazyku.

Věnuji pozornost například:

• databázovým dotazům,

• opakované práci,

• externím požadavkům,

• cache,

• chování pluginů.

Pomalá WordPress stránka je často důsledkem architektury nebo chování databáze, nikoli jednoho konkrétního PHP výrazu.

Výkon dotazů

Vyhýbám se zbytečně opakovaným dotazům.

Například kód, který ve velké smyčce opakovaně načítá stejná metadata, může být velmi nákladný.

Preferuji:

• efektivní dotazy,

• kontrolované smyčky,

• existující cache API WordPressu,

• přednačítání tam, kde je vhodné.

Skutečná úzká hrdla měřím, místo abych optimalizoval naslepo.

Caching

Cache může být užitečná pro data, jejichž výpočet je nákladný a která se mění jen zřídka.

Podle projektu může jít například o:

• transient cache,

• object cache,

• full-page cache.

Správná vrstva cache závisí na typu dat.

Personalizovaný nebo transakční stav neukládám do cache bez jasného pochopení důsledků.

Paměť

Serverové požadavky mají konečné prostředky.

Vyhýbám se zbytečnému načítání obrovských datasetů do paměti, pokud lze data:

• stránkovat,

• streamovat,

• zpracovávat po dávkách.

To je obzvlášť důležité u importů, exportů a automatizačních úloh.

Dávkové zpracování

U rozsáhlých zpracovatelských úloh preferuji řízené dávky místo pokusu provést vše v jediném HTTP požadavku.

Například:

Načtení dávky
↓
Zpracování
↓
Uložení výsledku
↓
Pokračování

Tím se snižuje riziko:

• vyčerpání paměti,

• timeoutů,

• částečně dokončené práce.

Dlouhotrvající úlohy

Běžný webový požadavek není vždy správným prostředím pro dlouhotrvající zpracování.

U úloh, jako jsou:

• rozsáhlé importy,

• zpracování médií,

• automatizace,

podle architektury zvažuji běh na pozadí, fronty, cron nebo externí worker procesy.

Uživatel by neměl muset držet jeden požadavek v prohlížeči otevřený několik minut, pokud daná úloha patří jinam.

WordPress Cron

Pro plánované WordPress úlohy mohu použít WP-Cron tam, kde jeho model spouštění odpovídá požadavkům.

Počítám s tím, že WP-Cron je spouštěný aktivitou webu a nefunguje úplně stejně jako systémový cron daemon.

Pro časově citlivé úlohy může být vhodnější plánování na úrovni serveru.

Práce se soubory

Když PHP zpracovává nahrané soubory, nekontroluji pouze jejich název.

Zohledňuji:

• očekávaný typ,

• velikost,

• umístění úložiště,

• oprávnění,

• zda má být soubor veřejně dostupný.

Nahrávání souborů je bezpečnostní hranicí systému.

Soubory nelze považovat za důvěryhodné jen proto, že přišly přes formulář.

Bezpečnost

Bezpečnost je součástí implementace v PHP, ne položkou, kterou lze odškrtnout až na konci.

Zohledňuji například:

• validaci,

• sanitizaci,

• escapování,

• prevenci SQL injection,

• autorizaci,

• ochranu proti CSRF,

• práci s přístupovými údaji,

• bezpečnost nahrávání souborů.

Mnoho webových zranitelností vzniká ve chvíli, kdy data překročí hranici důvěry bez odpovídajícího zpracování.

Princip nejmenších oprávnění

Komponenty aplikace by měly mít pouze ta oprávnění, která skutečně potřebují.

To platí pro:

• uživatele WordPressu,

• databázové uživatele,

• API přístupové údaje,

• oprávnění souborového systému.

Omezení zbytečných oprávnění snižuje dopad případných selhání.

HTTPS

Citlivá komunikace se serverem by měla probíhat přes HTTPS.

To je důležité zejména pro:

• autentizaci,

• API přístupové údaje,

• e-commerce,

• uživatelská data.

Bezpečnost na úrovni aplikace nenahrazuje zabezpečení transportní vrstvy.

Verze PHP

Preferuji vývoj proti udržovaným verzím PHP podporovaným cílovou platformou.

Moderní PHP přináší zlepšení v oblastech:

• typové bezpečnosti,

• výkonu,

• návrhu jazyka.

Pokud prostředí umožňuje modernizaci, vyhýbám se zbytečné závislosti na zastaralém chování.

Zpětná kompatibilita

WordPress prostředí mohou obsahovat velmi různorodé kombinace:

• verzí PHP,

• pluginů,

• hostingových konfigurací.

Při vývoji znovupoužitelného kódu zohledňuji skutečný cílový rozsah kompatibility.

Použití jazykové funkce, kterou cílový server nedokáže spustit, není úspěšná modernizace.

Testování

Důležitou PHP logiku tam, kde je to praktické, testuji nezávisle.

To je užitečné zejména pro:

• validaci,

• transformaci dat,

• integrace API,

• business pravidla.

Testuji také kompletní integraci, protože chování WordPressu často závisí na hookách a runtime kontextu.

Ladění

Když PHP funkcionalita selže, vycházím z důkazů místo náhodných změn.

Kontroluji například:

• PHP logy,

• debug výstup WordPressu,

• HTTP odpovědi,

• chování databáze,

• parametry požadavku.

Nejprve identifikuji vrstvu, ve které problém vznikl, a teprve poté měním kód.

Zobrazování chyb v produkci

Vývojová prostředí mohou zobrazovat detailní chyby.

Produkční prostředí by obecně neměla veřejným uživatelům odhalovat stack trace ani interní cesty.

Podrobné diagnostické informace uchovávám v logách, zatímco uživateli vracím kontrolované chybové hlášení.

Git

Vlastní PHP kód udržuji pod správou verzí pomocí Gitu.

Díky tomu jsou změny:

• dohledatelné,

• kontrolovatelné,

• vratné.

Správa verzí je obzvlášť důležitá při úpravách produkční WordPress funkcionality.

Živý WordPress editor nepovažuji za jedinou kopii důležité aplikační logiky.

Nasazení

Nasazení PHP změn zahrnuje víc než nahrání jednoho upraveného souboru.

Release může ovlivnit:

• aplikační kód,

• databázovou strukturu,

• konfiguraci,

• závislosti.

Preferuji reprodukovatelné procesy nasazení, při kterých je před většími změnami chráněn důležitý produkční stav.

Udržovatelnost

Čitelné PHP má větší hodnotu než „chytré“ PHP.

Preferuji:

• srozumitelné názvy,

• krátké a úzce zaměřené funkce,

• explicitní validaci,

• předvídatelné návratové hodnoty,

• zdokumentované hranice.

Budoucí vývojář by měl být schopný pochopit, proč daný kód existuje a z jakých předpokladů vychází.

Vyhýbání se zbytečně složité architektuře

Ne každá úprava WordPressu potřebuje rozsáhlou objektově orientovanou architekturu.

Někdy je správným řešením malá funkce a jeden hook.

U větší funkcionality naopak začíná dávat smysl větší struktura.

Architekturu škáluji podle složitosti problému.

Cílem je udržovatelnost, ne architektonický formalismus.

PHP v mém technologickém stacku

PHP běžně používám společně s technologiemi, jako jsou:

• WordPress,

• WooCommerce,

• Bricks Builder,

• Advanced Custom Fields,

• WordPress REST API,

• SQL,

• MySQL kompatibilní databáze WordPressu,

• HTML a CSS,

• JavaScript,

• REST API,

• JSON,

• Git.

PHP tvoří serverovou aplikační vrstvu, která tyto technologie propojuje.

Proč používám PHP

PHP používám proto, že poskytuje přímý přístup k jednomu z největších ekosystémů ve webovém vývoji a zároveň zůstává praktickým jazykem pro vlastní aplikační logiku na straně serveru.

Umožňuje mi rozšiřovat WordPress a WooCommerce, aniž bych se musel vzdávat jejich existující infrastruktury pro obsah, administraci a e-commerce.

Jeho hodnota nespočívá jen v tom, že dokáže vyrenderovat webovou stránku.

PHP může vynucovat oprávnění, zpracovávat data, zpřístupňovat API, integrovat externí systémy a implementovat business pravidla, která stojí za danou stránkou.

Právě tak PHP používám: jako serverovou inženýrskou vrstvu, která z webu postaveného na WordPressu vytváří spolehlivou a udržovatelnou aplikaci.