WordPress is one of the main platforms I use for building content-driven websites, custom web systems and e-commerce projects.

I use it far beyond conventional page publishing.

With custom post types, taxonomies, Advanced Custom Fields, Bricks Builder, WooCommerce, PHP and the WordPress REST API, I can turn WordPress into a structured application platform with a custom content model, reusable templates and integrations with external systems.

For me, WordPress is not simply a website builder.

It is a mature content-management platform with a large extensibility layer that can support anything from a relatively simple company website to a much more structured application.

How I use WordPress

I use WordPress for tasks such as:

The architecture depends on the project.

I do not try to make every WordPress website use the maximum possible number of plugins or custom systems.

The objective is to build the simplest architecture that can remain maintainable as the project evolves.

WordPress as a CMS

At its core, WordPress provides a content-management system.

Editors can manage:

For simple websites, this may already provide most of what is needed.

For more structured projects, I extend the content model instead of forcing everything into generic pages.

WordPress as an Application Platform

WordPress can also act as the backend of a more application-oriented system.

A typical architecture may look like:

WordPress
↓
Custom Post Types + Taxonomies
↓
ACF / Metadata
↓
PHP Application Logic
↓
Bricks / REST API
↓
Website or External Client

This allows the same platform to provide:

That combination is one of the main reasons I use WordPress.

Custom Post Types

Custom post types are one of the most important parts of my WordPress workflow.

Instead of representing every kind of information as a generic page, I define content types that reflect real entities.

Examples may include:

Each content type can have its own:

This produces a much stronger information architecture.

Custom Taxonomies

I use custom taxonomies when content needs meaningful classification.

Examples include:

Taxonomies provide structured relationships rather than manually typed labels.

They can then drive:

Advanced Custom Fields

Advanced Custom Fields is one of the technologies I frequently combine with WordPress.

ACF allows me to create structured editorial fields for data such as:

This separates content from layout.

An editor changes meaningful data.

The template decides how that data appears.

Structured Content

I prefer structured content over manually assembled page-builder content when the information has a predictable shape.

For example, a technology entry may contain:

Title
Category
Technology Type
Description
Related Technologies

Rather than designing every technology page independently, I can create one structured content model and one reusable template.

This makes the system significantly easier to maintain.

Bricks Builder

I use Bricks Builder as a visual development and templating layer on top of WordPress.

Bricks allows me to build:

I do not treat the builder as the source of application logic.

WordPress holds the content.

ACF structures the data.

PHP provides server-side behavior.

Bricks renders the interface.

Dynamic Templates

Reusable templates are one of the most important advantages of a structured WordPress architecture.

For example:

Custom Post Type
↓
Structured Data
↓
Bricks Template
↓
Rendered Page

A new item can be created through the WordPress administration interface without rebuilding the page design.

Updating one template can update every item using it.

Query-Driven Interfaces

I use WordPress queries to build dynamic collections such as:

The interface is generated from the underlying data rather than from manually maintained lists.

This reduces duplication and makes larger websites much easier to manage.

PHP

PHP provides the server-side programming layer behind my WordPress work.

I use it for:

I prefer using the platform’s extension mechanisms rather than modifying WordPress core.

Hooks and Filters

WordPress provides an extensive hook system.

I use actions and filters to extend or modify behavior without editing the platform itself.

This can support functionality such as:

Keeping customizations in hooks makes updates much safer.

Custom Plugins

When functionality becomes substantial or business-critical, I prefer moving it into a dedicated custom plugin.

This keeps application logic independent from the visual theme.

For example:

Theme / Bricks
→ presentation

Custom Plugin
→ application logic

The website design can then change without removing the underlying functionality.

functions.php

For smaller site-specific functionality, functions.php may still be appropriate.

I use it when the logic is:

I avoid turning it into a huge unstructured collection of unrelated features.

Once functionality grows, a dedicated plugin provides a clearer boundary.

WordPress REST API

The WordPress REST API provides structured JSON access to WordPress data and is also used as a foundation for modern WordPress interfaces. It can expose posts, pages, taxonomies and custom content types to external applications.

I use it for workflows such as:

WordPress
↓
REST API
↓
JavaScript / Python / Android / External Service

This allows WordPress to act as a backend rather than only a page renderer.

Custom REST Endpoints

When the built-in REST API does not represent the required functionality, I create custom endpoints.

These can provide:

I define:

API endpoints should have clear contracts rather than exposing arbitrary internal state.

REST Support for Custom Content

Custom post types and taxonomies can be exposed through WordPress REST routes, including through the standard wp/v2 namespace when configured for REST support.

This is useful when structured WordPress content needs to be consumed by:

WooCommerce

I use WooCommerce when a WordPress project needs transactional e-commerce functionality.

WooCommerce adds concepts such as:

I treat WooCommerce as a commerce engine and WordPress as the wider content and application platform.

E-Commerce Architecture

A WooCommerce project may combine:

WordPress
→ content

WooCommerce
→ commerce

ACF
→ additional structured data

Bricks
→ presentation

PHP
→ custom business logic

Keeping these responsibilities clear makes the store much easier to maintain.

Multilingual Websites

I build multilingual WordPress websites using structured translation workflows.

Depending on the project, this may include tools such as Polylang.

I consider:

The architecture should allow languages to coexist without creating unnecessary duplication or broken URL structures.

SEO

WordPress provides a strong foundation for content-oriented SEO, but good SEO still depends on implementation.

I consider:

Tools such as Rank Math can help manage metadata, but an SEO plugin cannot compensate for weak content architecture.

URL Architecture

Stable URLs are important for both users and search engines.

I design:

with long-term stability in mind.

Changing URL structures unnecessarily creates redirect and indexing problems later.

Permalinks

WordPress provides configurable permalink structures.

I use human-readable URLs and avoid exposing unnecessary implementation details.

A URL should communicate what the resource represents rather than how WordPress stores it internally.

Internal Linking

Structured content makes internal linking easier.

For example:

Technology
→ related project
→ related technology
→ category

This improves navigation and helps search systems understand relationships between content entities.

WordPress Database

WordPress uses a relational database underneath the platform.

I understand the underlying concepts of:

However, I prefer using WordPress APIs instead of directly manipulating database tables whenever the platform already provides a suitable abstraction.

Metadata

WordPress metadata makes it possible to extend entities without creating an entirely separate persistence system.

ACF builds heavily on this model.

I use metadata where the value logically belongs to the WordPress entity.

For more complex application data, I consider whether a dedicated table or external database architecture would be more appropriate.

Database Queries

Poor queries can significantly affect WordPress performance.

I pay attention to:

A visually simple page can still be expensive to generate.

Query Optimization

I prefer querying only the information the page actually needs.

For large content collections, I consider:

I do not retrieve every record and then filter the result manually in PHP unless there is a good reason.

Caching

Caching can improve WordPress performance significantly.

Depending on the architecture, this may involve:

I choose the appropriate layer according to the type of content.

Dynamic or personalized data requires different caching behavior from public static content.

Performance

WordPress performance depends heavily on implementation.

I consider:

WordPress itself should not be used as an excuse for a slow website.

A controlled architecture can remain lightweight.

Plugin Discipline

The WordPress plugin ecosystem is one of the platform’s strengths, but uncontrolled plugin usage can create problems.

Every plugin adds:

I install plugins when they provide real value.

I prefer focused custom code where adding another dependency would create more complexity than it removes.

Theme Architecture

The theme should primarily control presentation.

I avoid placing business-critical application functionality into a theme if that functionality should survive a redesign.

This distinction makes future theme changes much safer.

Child Themes

Where a third-party theme architecture requires customization, a child theme can preserve changes independently from the parent theme.

For builder-based projects, the exact architecture may differ, but the same principle remains:

project-specific changes should not be written directly into files that will be replaced by updates.

HTML & CSS

WordPress ultimately produces HTML and CSS for the browser.

I still work directly with:

A CMS or visual builder does not replace frontend fundamentals.

JavaScript

I use JavaScript when WordPress pages require browser-side application behavior.

This can include:

I keep JavaScript focused on browser responsibilities and server-side logic in PHP.

Browser Applications

WordPress can also serve as the host environment around standalone browser applications.

A site may contain an application that uses:

WordPress provides:

The application itself can remain architecturally independent.

Forms

Forms need both usable frontend behavior and secure backend processing.

I consider:

Frontend validation improves UX.

Server-side validation protects the system.

Security

WordPress development requires defensive programming.

I consider:

WordPress’s current Common APIs documentation explicitly separates security concerns such as sanitization, validation, escaping, nonces and user roles/capabilities, which reflects the same layered approach I use in custom development.

Validation

External input should be checked before the application trusts it.

I validate:

The validation logic should reflect the actual meaning of the value.

Sanitization

After determining that an input is acceptable, I normalize it according to its data type.

WordPress provides specialized sanitization functions for different types of data.

I prefer the correct function for the context rather than applying one generic transformation to everything.

Output Escaping

Stored data is not automatically safe to output.

I escape data according to the destination context.

This may include:

Escaping at the output boundary helps prevent injection vulnerabilities.

Capabilities

I use WordPress capabilities for authorization.

A user being logged in does not automatically mean they should be able to:

The server should check the actual permission required.

Nonces

Nonces provide protection for relevant authenticated actions.

I use them alongside authorization checks.

They do not replace capability checks.

REST Permissions

Custom REST endpoints need explicit permission logic.

A route being difficult to discover does not make it private.

Authorization must happen on the server.

Updates

WordPress projects depend on:

I keep these components updated while recognizing that production updates still need to be tested.

A technically available update does not automatically mean it should be installed blindly on a critical production website.

Staging

For larger or business-critical websites, a staging environment allows changes to be tested before production.

This is particularly useful for:

Testing reduces unnecessary production risk.

Backups

Backups are part of the operational architecture.

A WordPress backup may need to include:

A backup is only useful if restoration is possible.

Hosting

The hosting environment affects WordPress behavior significantly.

I consider areas such as:

Good application code cannot completely compensate for inadequate infrastructure.

Production Reliability

A production website should remain stable even when:

I try to isolate failures so one integration does not unnecessarily take down the entire website.

Logging

Useful logs help diagnose server-side problems.

I use them for issues such as:

I avoid exposing detailed technical errors directly to public visitors.

Debugging

When a WordPress problem occurs, I inspect the relevant layer.

That may include:

WordPress is a complete stack.

A visual problem may originate in CSS, PHP, a query or a third-party extension.

I prefer finding the actual cause instead of adding arbitrary fixes.

WP-CLI

Command-line tooling can make WordPress administration and automation more efficient.

For appropriate workflows, WP-CLI can support tasks involving:

Command-line access is particularly useful for repeatable operations and server environments.

Git

I keep important custom WordPress code under Git version control.

This includes:

Version control makes changes:

I do not treat the production WordPress editor as a source-control system.

Development and Production

I distinguish between development and production behavior.

Development may include:

Production should provide:

Environment-specific differences should be intentional.

Deployment

A WordPress deployment may involve more than copying files.

A change can affect:

I consider these dependencies when planning production updates.

Editor Experience

A successful WordPress implementation should also be usable by the people maintaining its content.

I prefer giving editors:

They should not need to understand the underlying page architecture to update routine content.

Preventing Accidental Layout Damage

One advantage of structured templates and ACF-driven content is that editors do not need to redesign pages.

They edit data.

The template remains controlled.

This significantly reduces the chance of inconsistent layouts across a large website.

Reusability

I prefer reusable structures over duplicated pages.

For example:

One custom post type
+
One template
+
Many content entries

is generally much easier to maintain than:

Many independent manually built pages

This principle becomes increasingly important as websites grow.

Maintainability

A WordPress project should remain understandable after the initial development is complete.

I keep responsibilities clear:

WordPress
→ content management

ACF
→ structured data

Bricks
→ presentation

PHP
→ custom server logic

REST API
→ integration

This separation makes future changes safer.

Avoiding Overengineering

Not every WordPress site needs:

A small website may only need:

I introduce complexity when the project actually benefits from it.

A good architecture is not the largest architecture.

It is the simplest one that can support the requirements reliably.

WordPress and AI Automation

WordPress can also participate in AI-assisted workflows.

For example:

WordPress Content
↓
REST API
↓
AI Processing
↓
Validation
↓
WordPress Update

This can support tasks such as:

I keep AI-generated data behind validation before allowing it to modify important production content.

WordPress and External Systems

WordPress does not need to exist as an isolated system.

Through REST APIs and other integrations it can communicate with:

This allows WordPress to remain the editorial platform while specialized software handles other responsibilities.

WordPress in My Technology Stack

I commonly use WordPress alongside technologies such as:

WordPress provides the content-management and application foundation connecting these technologies.

Why I Use WordPress

I use WordPress because it provides a strong combination of mature content management, extensibility and a large ecosystem while still allowing deep custom development.

I can use it for a straightforward website.

I can also extend it with:

The important part is knowing when to use each layer.

I do not treat WordPress as a substitute for software engineering.

I use software-engineering principles to control WordPress.

That distinction is what allows the platform to remain useful even when a project grows well beyond a conventional website.

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:

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:

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:

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:

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

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:

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

Následně mohou řídit:

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:

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:

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:

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:

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:

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:

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:

Definuji:

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:

WooCommerce

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

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

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:

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:

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:

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ř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:

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:

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:

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:

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á:

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:

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:

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í:

WordPress zajišťuje:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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í:

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:

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í:

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:

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

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:

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

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:

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:

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:

Menšímu webu mohou stačit:

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:

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:

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:

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:

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.