WordPress

WordPress je jednou z hlavních platforem, které používám pro tvorbu obsahově orientovaných webů, vlastních webových systémů a e-commerce projektů.

Používám jej daleko za hranicemi běžného publikování stránek.

Díky vlastním typům příspěvků, taxonomiím, Advanced Custom Fields, Bricks Builderu, WooCommerce, PHP a WordPress REST API dokážu WordPress proměnit ve strukturovanou aplikační platformu s vlastním datovým modelem obsahu, znovupoužitelnými šablonami a integracemi s externími systémy.

WordPress pro mě není jen nástroj pro tvorbu webů.

Je to vyspělá platforma pro správu obsahu s rozsáhlými možnostmi rozšíření, která dokáže obsloužit vše od relativně jednoduchého firemního webu až po výrazně strukturovanější aplikaci.

Jak WordPress používám

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

• obsahově orientované weby,

• portfoliové weby,

• vlastní obsahové systémy,

• strukturované katalogy,

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

• vlastní taxonomie,

• dynamické šablony,

• e-commerce,

• integrace řízené přes API,

• vícejazyčné weby,

• publikování orientované na SEO,

• vlastní funkcionalitu v PHP,

• prohlížečové aplikace vložené do webů.

Architektura závisí na konkrétním projektu.

Nesnažím se každý WordPress web zatížit maximálním možným počtem pluginů nebo vlastních systémů.

Cílem je vytvořit co nejjednodušší architekturu, která zůstane dlouhodobě udržitelná i s dalším vývojem projektu.

WordPress jako CMS

WordPress ve svém základu poskytuje systém pro správu obsahu.

Redaktoři mohou spravovat:

• stránky,

• příspěvky,

• média,

• uživatele,

• kategorie,

• metadata.

U jednoduchých webů to může samo o sobě pokrýt většinu potřeb.

U strukturovanějších projektů rozšiřuji obsahový model, místo abych se snažil vše vměstnat do obecných stránek.

WordPress jako aplikační platforma

WordPress může fungovat také jako backend systému orientovaného více aplikačně.

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

WordPress
↓
Vlastní typy příspěvků + taxonomie
↓
ACF / metadata
↓
Aplikační logika v PHP
↓
Bricks / REST API
↓
Web nebo externí klient

Díky tomu může jedna platforma zajišťovat:

• administraci,

• ukládání obsahu,

• autentizaci,

• strukturovaná data,

• API,

• vykreslování.

Právě tato kombinace je jedním z hlavních důvodů, proč WordPress používám.

Vlastní typy příspěvků

Vlastní typy příspěvků patří mezi nejdůležitější součásti mého workflow ve WordPressu.

Místo toho, abych každý druh informací reprezentoval jako obecnou stránku, definuji typy obsahu, které odpovídají skutečným entitám.

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

• technologie,

• projekty,

• aplikace,

• produkty,

• vozidla,

• lokality,

• dokumentaci.

Každý typ obsahu může mít vlastní:

• pole,

• šablony,

• taxonomie,

• vztahy,

• archiv.

Výsledkem je výrazně kvalitnější informační architektura.

Vlastní taxonomie

Vlastní taxonomie používám tam, kde obsah potřebuje smysluplné třídění.

Patří mezi ně například:

• kategorie technologií,

• typy obsahu,

• regiony,

• stavy,

• klasifikace produktů.

Taxonomie vytvářejí strukturované vztahy namísto ručně zadávaných štítků.

Následně mohou řídit:

• navigaci,

• filtrování,

• archivy,

• související obsah,

• API dotazy.

Advanced Custom Fields

Advanced Custom Fields je jedna z technologií, které s WordPressem často kombinuji.

ACF mi umožňuje vytvářet strukturovaná editační pole pro data, jako jsou:

• URL adresy,

• specifikace,

• obrázky,

• stavy,

• vztahy,

• opakovatelná pole,

• konfigurace.

Tím se odděluje obsah od rozvržení.

Redaktor upravuje významová data.

Šablona rozhoduje o tom, jak se tato data zobrazí.

Strukturovaný obsah

Pokud mají informace předvídatelnou strukturu, dávám přednost strukturovanému obsahu před ručně sestavovaným obsahem v page builderu.

Například záznam technologie může obsahovat:

Název
Kategorie
Typ technologie
Popis
Související technologie

Místo samostatného navrhování každé stránky technologie mohu vytvořit jeden strukturovaný obsahový model a jednu znovupoužitelnou šablonu.

Díky tomu je systém výrazně snazší na údržbu.

Bricks Builder

Bricks Builder používám jako vizuální vývojovou a šablonovací vrstvu nad WordPressem.

Bricks mi umožňuje vytvářet:

• dynamické šablony,

• znovupoužitelné komponenty,

• rozvržení řízená dotazy,

• responzivní rozhraní.

Builder nepovažuji za zdroj aplikační logiky.

WordPress uchovává obsah.

ACF strukturuje data.

PHP zajišťuje chování na straně serveru.

Bricks vykresluje rozhraní.

Dynamické šablony

Znovupoužitelné šablony jsou jednou z největších výhod strukturované architektury WordPressu.

Například:

Vlastní typ příspěvku
↓
Strukturovaná data
↓
Šablona Bricks
↓
Vykreslená stránka

Novou položku lze vytvořit přes administraci WordPressu bez nutnosti znovu stavět design stránky.

Úpravou jediné šablony lze aktualizovat všechny položky, které ji používají.

Rozhraní řízená dotazy

WordPress dotazy používám k vytváření dynamických kolekcí, jako jsou:

• archivy,

• katalogy,

• související obsah,

• filtrované seznamy.

Rozhraní se generuje z podkladových dat namísto ručně udržovaných seznamů.

Tím se omezuje duplicita a správa větších webů je výrazně jednodušší.

PHP

PHP tvoří serverovou programovací vrstvu mé práce s WordPressem.

Používám jej pro:

• vlastní funkcionalitu,

• hooky,

• filtry,

• REST endpointy,

• zpracování dat,

• integrace,

• vlastní dotazy.

Dávám přednost rozšiřujícím mechanismům platformy před úpravami jádra WordPressu.

Hooky a filtry

WordPress poskytuje rozsáhlý systém hooků.

Akce a filtry používám k rozšiřování nebo úpravě chování bez zásahu do samotné platformy.

To může sloužit například pro:

• reakci na aktualizace obsahu,

• úpravu výstupu,

• rozšíření chování pluginů,

• vlastní zpracování.

Udržování vlastních úprav v hookách výrazně zvyšuje bezpečnost budoucích aktualizací.

Vlastní pluginy

Jakmile je funkcionalita rozsáhlejší nebo kritická pro fungování projektu, dávám přednost jejímu přesunu do samostatného vlastního pluginu.

Aplikační logika tak zůstává nezávislá na vizuálním motivu.

Například:

Šablona / Bricks
→ prezentace

Vlastní plugin
→ aplikační logika

Design webu se pak může změnit, aniž by se odstranila jeho základní funkcionalita.

functions.php

Pro menší funkcionalitu specifickou pro konkrétní web může být functions.php stále vhodnou volbou.

Používám jej tehdy, když je logika:

• omezená,

• srozumitelná,

• úzce spojená s daným webem.

Vyhýbám se tomu, aby se z něj stal obrovský nestrukturovaný soubor nesouvisejících funkcí.

Jakmile funkcionalita naroste, samostatný plugin vytváří jasnější hranici.

WordPress REST API

WordPress REST API poskytuje strukturovaný přístup k datům WordPressu ve formátu JSON a zároveň slouží jako základ moderních rozhraní WordPressu. Dokáže zpřístupnit příspěvky, stránky, taxonomie i vlastní typy obsahu externím aplikacím.

Používám jej například pro workflow typu:

WordPress
↓
REST API
↓
JavaScript / Python / Android / externí služba

Díky tomu může WordPress fungovat jako backend, nikoli pouze jako renderer stránek.

Vlastní REST endpointy

Pokud vestavěné REST API nepokrývá požadovanou funkcionalitu, vytvářím vlastní endpointy.

Ty mohou poskytovat:

• specializované dotazy,

• aplikační akce,

• rozhraní pro automatizaci,

• externí integrace.

Definuji:

• metody,

• argumenty,

• validaci,

• callbacky pro oprávnění,

• odpovědi.

API endpointy by měly mít jasně definované kontrakty a neměly by svévolně zpřístupňovat interní stav aplikace.

Podpora vlastního obsahu v REST API

Vlastní typy příspěvků a taxonomie lze zpřístupnit prostřednictvím REST rout WordPressu, včetně standardního wp/v2 jmenného prostoru, pokud jsou nakonfigurovány s podporou REST API.

To je užitečné, pokud strukturovaný obsah WordPressu potřebují využívat:

• prohlížečové aplikace,

• mobilní aplikace,

• automatizace,

• externí služby.

WooCommerce

WooCommerce používám tehdy, když WordPress projekt potřebuje transakční e-commerce funkcionalitu.

WooCommerce přidává koncepty, jako jsou:

• produkty,

• košíky,

• pokladna,

• objednávky,

• platby,

• zákaznické účty.

WooCommerce vnímám jako obchodní engine a WordPress jako širší obsahovou a aplikační platformu.

Architektura e-commerce

Projekt s WooCommerce může kombinovat:

WordPress
→ obsah

WooCommerce
→ obchodní funkce

ACF
→ doplňková strukturovaná data

Bricks
→ prezentace

PHP
→ vlastní business logika

Jasné oddělení těchto odpovědností výrazně usnadňuje údržbu obchodu.

Vícejazyčné weby

Vícejazyčné WordPress weby vytvářím pomocí strukturovaných překladových workflow.

Podle konkrétního projektu to může zahrnovat nástroje, jako je Polylang.

Zohledňuji:

• URL adresy specifické pro jednotlivé jazyky,

• přeložený obsah,

• metadata,

• navigaci,

• interní odkazy.

Architektura by měla umožnit soužití více jazyků bez zbytečné duplicity nebo rozbitých struktur URL.

SEO

WordPress poskytuje silný základ pro obsahově orientované SEO, kvalitní SEO však stále závisí na samotné implementaci.

Zohledňuji:

• informační architekturu,

• názvy stránek,

• metadata,

• interní prolinkování,

• sémantické HTML,

• výkon,

• strukturovaný obsah.

Nástroje, jako je Rank Math, mohou pomoci se správou metadat, ale SEO plugin nedokáže kompenzovat slabou architekturu obsahu.

Architektura URL

Stabilní URL adresy jsou důležité pro uživatele i vyhledávače.

Navrhuji:

• slugs,

• cesty vlastních typů příspěvků,

• cesty taxonomií,

• vícejazyčné URL adresy

s ohledem na dlouhodobou stabilitu.

Zbytečné změny struktury URL později způsobují problémy s přesměrováním a indexací.

Trvalé odkazy

WordPress nabízí konfigurovatelné struktury trvalých odkazů.

Používám srozumitelné URL adresy a vyhýbám se odhalování zbytečných implementačních detailů.

URL adresa by měla vyjadřovat, co daný zdroj představuje, nikoli jak jej WordPress interně ukládá.

Interní prolinkování

Strukturovaný obsah usnadňuje interní prolinkování.

Například:

Technologie
→ související projekt
→ související technologie
→ kategorie

To zlepšuje navigaci a pomáhá vyhledávacím systémům porozumět vztahům mezi obsahovými entitami.

Databáze WordPressu

WordPress používá relační databázi, která tvoří základ platformy.

Rozumím podkladovým konceptům, jako jsou:

• příspěvky,

• metadata příspěvků,

• uživatelé,

• termíny,

• nastavení.

Přesto dávám přednost WordPress API před přímou manipulací s databázovými tabulkami všude tam, kde platforma nabízí vhodnou abstrakci.

Metadata

Metadata WordPressu umožňují rozšiřovat entity bez nutnosti vytvářet zcela samostatný systém perzistence.

ACF tento model ve velké míře využívá.

Metadata používám tam, kde daná hodnota logicky náleží k příslušné entitě WordPressu.

U složitějších aplikačních dat zvažuji, zda není vhodnější samostatná tabulka nebo externí databázová architektura.

Databázové dotazy

Nevhodně navržené dotazy mohou výrazně ovlivnit výkon WordPressu.

Věnuji pozornost:

• opakovaným dotazům na metadata,

• náročným taxonomickým dotazům,

• velkým množinám výsledků,

• zbytečným vlastním dotazům.

I vizuálně jednoduchá stránka může být výpočetně náročná na vygenerování.

Optimalizace dotazů

Dávám přednost dotazování pouze na informace, které daná stránka skutečně potřebuje.

U rozsáhlých kolekcí obsahu zohledňuji:

• stránkování,

• limity výsledků,

• caching,

• efektivní struktury taxonomií.

Pokud k tomu není dobrý důvod, nenačítám všechny záznamy jen proto, abych je následně ručně filtroval v PHP.

Caching

Caching může výkon WordPressu výrazně zlepšit.

V závislosti na architektuře může zahrnovat:

• cache stránek,

• objektovou cache,

• transient cache,

• cache prohlížeče.

Vhodnou vrstvu volím podle typu obsahu.

Dynamická nebo personalizovaná data vyžadují jinou strategii cachování než veřejný statický obsah.

Výkon

Výkon WordPressu do značné míry závisí na způsobu implementace.

Zohledňuji:

• počet pluginů,

• databázové dotazy,

• generované HTML,

• obrázky,

• JavaScript,

• CSS,

• externí služby.

Samotný WordPress by neměl sloužit jako výmluva pro pomalý web.

Dobře řízená architektura může zůstat lehká a efektivní.

Disciplína při používání pluginů

Ekosystém pluginů je jednou ze silných stránek WordPressu, nekontrolované používání pluginů však může způsobovat problémy.

Každý plugin přidává:

• kód,

• závislosti,

• požadavky na aktualizace,

• potenciální bezpečnostní rizika,

• možnou databázovou režii.

Pluginy instaluji tehdy, když přinášejí skutečnou hodnotu.

Tam, kde by další závislost přinesla více složitosti než užitku, dávám přednost cílenému vlastnímu kódu.

Architektura šablony

Šablona by měla primárně řídit prezentaci.

Vyhýbám se umisťování business-kritické aplikační funkcionality do šablony, pokud má tato funkcionalita přežít budoucí redesign.

Toto rozdělení výrazně zvyšuje bezpečnost budoucích změn šablony.

Child themes

Pokud architektura šablony třetí strany vyžaduje úpravy, child theme umožňuje zachovat změny nezávisle na parent theme.

U projektů založených na builderu se může konkrétní architektura lišit, princip však zůstává stejný:

změny specifické pro projekt by neměly být zapisovány přímo do souborů, které budou při aktualizaci nahrazeny.

HTML & CSS

WordPress ve výsledku generuje HTML a CSS pro prohlížeč.

Stále přímo pracuji s:

• sémantickým HTML,

• responzivními rozvrženími,

• Flexboxem,

• Gridem,

• CSS proměnnými,

• přístupností.

CMS ani vizuální builder nenahrazují základy frontendu.

JavaScript

JavaScript používám tehdy, když stránky ve WordPressu potřebují aplikační chování na straně prohlížeče.

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

• vlastní interakce,

• požadavky na REST API,

• filtrování,

• vložené nástroje.

JavaScript udržuji zaměřený na odpovědnosti prohlížeče a serverovou logiku ponechávám v PHP.

Prohlížečové aplikace

WordPress může sloužit také jako hostitelské prostředí pro samostatné prohlížečové aplikace.

Web může obsahovat aplikaci využívající:

• File API,

• Canvas,

• Web Workers,

• WebAssembly,

• lokální zpracování.

WordPress zajišťuje:

• okolní web,

• obsah,

• navigaci,

• distribuci.

Samotná aplikace přitom může zůstat architektonicky nezávislá.

Formuláře

Formuláře potřebují jak použitelné chování na frontendu, tak bezpečné zpracování na backendu.

Zohledňuji:

• popisky,

• validaci,

• ochranu proti spamu,

• sanitizaci,

• zpětnou vazbu při chybách.

Validace na frontendu zlepšuje uživatelský zážitek.

Validace na serveru chrání systém.

Bezpečnost

Vývoj pro WordPress vyžaduje defenzivní programování.

Zohledňuji:

• validaci,

• sanitizaci,

• escapování výstupu,

• oprávnění,

• nonces,

• REST oprávnění,

• bezpečné přihlašovací údaje,

• aktualizace.

Současná dokumentace Common APIs ve WordPressu výslovně odděluje bezpečnostní oblasti, jako jsou sanitizace, validace, escapování, nonces a uživatelské role/oprávnění, což odpovídá stejnému vrstvenému přístupu, který používám při vlastním vývoji.

Validace

Externí vstupy je potřeba ověřit dříve, než jim aplikace začne důvěřovat.

Validuji:

• pole formulářů,

• REST parametry,

• vlastní nastavení,

• importovaná data.

Logika validace by měla odpovídat skutečnému významu dané hodnoty.

Sanitizace

Jakmile ověřím, že je vstup přijatelný, normalizuji jej podle jeho datového typu.

WordPress poskytuje specializované sanitizační funkce pro různé typy dat.

Dávám přednost funkci odpovídající konkrétnímu kontextu před jednou univerzální transformací aplikovanou na všechno.

Escapování výstupu

Uložená data nejsou automaticky bezpečná pro výstup.

Data escapuju podle kontextu, do kterého budou vložena.

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

• HTML text,

• atributy,

• URL adresy.

Escapování na hranici výstupu pomáhá předcházet zranitelnostem typu injection.

Oprávnění

Pro autorizaci používám systém oprávnění WordPressu.

Samotné přihlášení uživatele automaticky neznamená, že by měl mít možnost:

• upravovat obsah,

• přistupovat k administračním datům,

• spouštět citlivé akce.

Server by měl vždy ověřit konkrétní požadované oprávnění.

Nonces

Nonces poskytují ochranu pro relevantní autentizované akce.

Používám je společně s kontrolou autorizace.

Nenahrazují kontrolu oprávnění.

REST oprávnění

Vlastní REST endpointy potřebují explicitní logiku oprávnění.

To, že je určitou routu obtížné objevit, z ní nedělá soukromý endpoint.

Autorizace musí probíhat na serveru.

Aktualizace

WordPress projekty závisí na:

• jádru WordPressu,

• pluginech,

• šablonách,

• PHP,

• hostingové infrastruktuře.

Tyto komponenty udržuji aktuální, zároveň však počítám s tím, že produkční aktualizace je stále potřeba otestovat.

To, že je aktualizace technicky dostupná, ještě neznamená, že by měla být bezhlavě nainstalována na kritický produkční web.

Staging

U větších nebo business-kritických webů umožňuje stagingové prostředí otestovat změny před nasazením do produkce.

To je zvlášť užitečné pro:

• aktualizace jádra WordPressu,

• aktualizace pluginů,

• změny ve WooCommerce,

• vlastní PHP,

• redesigny.

Testování snižuje zbytečná produkční rizika.

Zálohy

Zálohy jsou součástí provozní architektury.

Záloha WordPressu může potřebovat zahrnovat:

• databázi,

• nahraná média,

• vlastní kód,

• konfiguraci.

Záloha má smysl pouze tehdy, pokud je možné ji obnovit.

Hosting

Hostingové prostředí má na chování WordPressu výrazný vliv.

Zohledňuji oblasti, jako jsou:

• verze PHP,

• výkon databáze,

• paměťové limity,

• caching,

• úložiště,

• HTTPS.

Ani kvalitní aplikační kód nedokáže zcela kompenzovat nedostatečnou infrastrukturu.

Spolehlivost v produkci

Produkční web by měl zůstat stabilní i v situacích, kdy:

• selže externí API,

• uživatel odešle neplatná data,

• volitelná služba není dostupná.

Snažím se selhání izolovat tak, aby problém jedné integrace zbytečně neshodil celý web.

Logování

Užitečné logy pomáhají diagnostikovat problémy na straně serveru.

Používám je například při řešení:

• PHP chyb,

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

• problémů se zpracováním na pozadí.

Vyhýbám se zobrazování detailních technických chyb přímo veřejným návštěvníkům.

Debugování

Když se ve WordPressu objeví problém, prověřuji odpovídající vrstvu.

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

• PHP logy,

• databázové dotazy,

• konzoli prohlížeče,

• síťové požadavky,

• vygenerované HTML.

WordPress tvoří kompletní technologický stack.

Vizuální problém může mít původ v CSS, PHP, databázovém dotazu nebo rozšíření třetí strany.

Dávám přednost nalezení skutečné příčiny před přidáváním nahodilých oprav.

WP-CLI

Nástroje příkazové řádky mohou zefektivnit správu i automatizaci WordPressu.

Ve vhodných workflow může WP-CLI pomáhat s úlohami, které zahrnují:

• konfiguraci,

• pluginy,

• uživatele,

• databázové operace,

• skriptovanou údržbu.

Přístup z příkazové řádky je zvlášť užitečný pro opakovatelné operace a serverová prostředí.

Git

Důležitý vlastní kód pro WordPress uchovávám ve verzovacím systému Git.

Patří sem:

• PHP,

• JavaScript,

• CSS,

• vlastní pluginy,

• konfigurace projektu.

Verzování dělá změny:

• dohledatelné,

• vratné,

• snáze kontrolovatelné.

Produkční editor WordPressu nepovažuji za systém správy verzí.

Vývoj a produkce

Rozlišuji mezi chováním ve vývojovém a produkčním prostředí.

Vývojové prostředí může zahrnovat:

• podrobné logování,

• testovací data,

• debugovací nástroje.

Produkční prostředí by mělo poskytovat:

• řízené zpracování chyb,

• optimalizované assety,

• bezpečnou konfiguraci.

Rozdíly mezi jednotlivými prostředími by měly být záměrné.

Nasazení

Nasazení WordPressu může zahrnovat více než jen zkopírování souborů.

Změna může ovlivnit:

• kód,

• obsah databáze,

• konfiguraci pluginů,

• cache.

Při plánování produkčních aktualizací s těmito závislostmi počítám.

Uživatelský komfort redaktorů

Úspěšná implementace WordPressu by měla být použitelná také pro lidi, kteří spravují její obsah.

Redaktorům raději poskytuji:

• jasně definovaná obsahová pole,

• smysluplné popisky,

• předvídatelné workflow.

Pro běžnou aktualizaci obsahu by neměli potřebovat rozumět vnitřní architektuře stránky.

Prevence nechtěného poškození layoutu

Jednou z výhod strukturovaných šablon a obsahu řízeného přes ACF je, že redaktoři nemusí stránky znovu navrhovat.

Upravují data.

Šablona zůstává pod kontrolou.

Tím se výrazně snižuje riziko nekonzistentních rozvržení napříč rozsáhlejším webem.

Znovupoužitelnost

Dávám přednost znovupoužitelným strukturám před duplikovanými stránkami.

Například:

Jeden vlastní typ příspěvku
+
Jedna šablona
+
Mnoho obsahových záznamů

se obecně udržuje mnohem snáze než:

Mnoho samostatných ručně sestavených stránek

Tento princip je s růstem webu stále důležitější.

Udržovatelnost

WordPress projekt by měl zůstat srozumitelný i po dokončení původního vývoje.

Jednotlivé odpovědnosti držím jasně oddělené:

WordPress
→ správa obsahu

ACF
→ strukturovaná data

Bricks
→ prezentace

PHP
→ vlastní serverová logika

REST API
→ integrace

Toto oddělení zvyšuje bezpečnost budoucích změn.

Prevence zbytečného overengineeringu

Ne každý WordPress web potřebuje:

• vlastní pluginy,

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

• složitou API architekturu.

Menšímu webu mohou stačit:

• stránky,

• čistá šablona,

• základní konfigurace.

Složitost přidávám pouze tehdy, když z ní projekt skutečně těží.

Dobrá architektura není ta největší.

Je to nejjednodušší architektura, která dokáže spolehlivě splnit požadavky.

WordPress a AI automatizace

WordPress může být součástí také workflow využívajících AI.

Například:

Obsah WordPressu
↓
REST API
↓
AI zpracování
↓
Validace
↓
Aktualizace WordPressu

To může podporovat úlohy, jako jsou:

• zpracování metadat,

• transformace strukturovaného obsahu,

• klasifikace,

• vícejazyčná workflow.

Data generovaná AI nechávám před změnou důležitého produkčního obsahu projít validací.

WordPress a externí systémy

WordPress nemusí existovat jako izolovaný systém.

Prostřednictvím REST API a dalších integrací může komunikovat s:

• Python službami,

• mobilními aplikacemi,

• externími webovými aplikacemi,

• automatizačními systémy.

Díky tomu může WordPress zůstat redakční platformou, zatímco specializovaný software řeší jiné odpovědnosti.

WordPress v mém technologickém stacku

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

• PHP,

• Bricks Builder,

• Advanced Custom Fields,

• WooCommerce,

• WordPress REST API,

• HTML a CSS,

• JavaScript,

• SQL,

• REST API,

• JSON,

• Git.

WordPress poskytuje základ pro správu obsahu i aplikační vrstvu, která tyto technologie propojuje.

Proč používám WordPress

WordPress používám proto, že spojuje vyspělou správu obsahu, vysokou rozšiřitelnost a rozsáhlý ekosystém, přičemž stále umožňuje hluboký vlastní vývoj.

Mohu jej použít pro přímočarý web.

Stejně tak jej mohu rozšířit o:

• vlastní obsahové modely,

• API,

• vlastní PHP,

• e-commerce,

• externí aplikace.

Důležité je vědět, kdy kterou vrstvu použít.

WordPress nepovažuji za náhradu softwarového inženýrství.

Naopak používám principy softwarového inženýrství k tomu, abych měl WordPress pod kontrolou.

Právě tento rozdíl umožňuje, aby platforma zůstala užitečná i ve chvíli, kdy projekt výrazně přeroste rámec běžného webu.