PHP is one of the server-side programming languages I use for web development, particularly when working with WordPress, WooCommerce, custom APIs and application logic running directly on the server.

I use PHP to extend existing platforms, create custom functionality, process requests, work with databases, validate data and integrate external systems.

For me, PHP is not simply the language behind WordPress.

It is the server-side layer that allows a content-driven website to become a real application.

How I use PHP

I use PHP for tasks such as:

Most of my PHP work is connected to practical application behavior rather than isolated scripts.

PHP and WordPress

WordPress is one of the main environments where I use PHP.

PHP controls much of WordPress functionality, including:

I use PHP when a project needs functionality that cannot or should not be implemented purely through the visual interface.

A typical WordPress architecture may look like:

WordPress
↓
PHP logic
↓
Custom Post Types / ACF / WooCommerce
↓
Bricks Builder
↓
Rendered Website

The visual layer handles presentation.

PHP handles server-side behavior.

Custom WordPress Functionality

I often use PHP to create focused custom functionality instead of installing another plugin for every small requirement.

This can include:

I prefer small, understandable custom implementations when they reduce dependency count and are easier to maintain.

WordPress Hooks

Hooks are central to WordPress development.

I use actions and filters to extend behavior without modifying WordPress core.

This allows custom logic to react to events such as:

Hooks make it possible to extend WordPress while keeping custom code separate from the platform itself.

Filters

Filters allow existing values to be modified before WordPress uses or outputs them.

I use them for targeted behavior changes such as:

I keep filter callbacks focused.

A callback that performs many unrelated operations quickly becomes difficult to debug.

Avoiding Core Modifications

I do not modify WordPress or WooCommerce core files for project-specific functionality.

Core files are replaced during updates.

Instead, I use:

This makes the implementation much more durable.

Custom Plugins

When functionality becomes substantial, I prefer putting it into a custom plugin.

This separates application logic from presentation.

For example:

Theme / Bricks
→ presentation

Custom Plugin
→ business logic

If the website design changes later, the underlying functionality can remain intact.

functions.php

For smaller, tightly scoped website-specific functionality, functions.php can be appropriate.

I use it carefully for code that genuinely belongs to the active site presentation layer.

As logic grows, I prefer moving reusable or business-critical functionality into a dedicated plugin.

This prevents the theme file from becoming a large collection of unrelated features.

PHP and Bricks Builder

I use PHP together with Bricks Builder when a visually built WordPress interface requires additional server-side logic.

This may involve:

Bricks handles the interface.

PHP handles behavior that belongs on the server.

PHP and Advanced Custom Fields

ACF provides structured data inside WordPress.

PHP allows me to process that data programmatically.

For example, PHP can:

This is useful when structured content needs more than simple template rendering.

Custom Post Types

I use PHP to define custom post types when WordPress needs to represent actual entities rather than only pages and blog posts.

Examples might include:

A custom post type gives the content a defined structure and lifecycle.

This makes WordPress much more useful as an application platform.

Custom Taxonomies

Taxonomies provide structured classification.

I use PHP to create custom taxonomies when content needs relationships such as:

This creates a proper information architecture rather than relying on manually typed labels.

WooCommerce

WooCommerce is another major area where I use PHP.

Custom functionality may involve:

I use WooCommerce APIs, hooks and domain objects rather than making unnecessary assumptions about internal storage.

Commerce logic needs to remain compatible with the platform’s evolving architecture.

Order Processing

Order lifecycle events often need custom behavior.

For example:

Order Created
↓
Payment Confirmed
↓
Custom Processing
↓
Fulfilment

I connect automation to meaningful order states rather than frontend page visits.

The order itself should remain the authoritative transactional object.

WordPress REST API

I use PHP to create and extend WordPress REST API endpoints.

A custom endpoint may:

A typical flow may look like:

External Client
↓
REST API
↓
PHP
↓
WordPress / Database

This allows WordPress to operate as a backend for other applications.

API Design

When I create custom endpoints, I treat them as contracts.

I define:

An API should not expose arbitrary internal implementation details.

The client should receive a stable and predictable interface.

Input Validation

All external input is untrusted.

I validate values before using them.

This may include checking:

Validation answers whether a value is acceptable.

This should happen before the value reaches important application logic.

Sanitization

Sanitization is a separate concern from validation.

I normalize input according to its intended type.

Examples include:

I do not use one generic sanitization approach for every kind of input.

Data should be handled according to its meaning.

Output Escaping

Data that is safe to store is not automatically safe to render.

When output enters HTML, I escape it according to context.

That may include:

Escaping belongs at the output boundary.

This helps prevent injection vulnerabilities.

SQL Injection Prevention

When PHP interacts with a database, I do not concatenate untrusted input directly into SQL.

I use:

The query structure and external data should remain separate.

WordPress Database Access

For WordPress-specific database work, I use the platform’s database abstraction where appropriate.

I avoid direct database queries when a higher-level WordPress API already provides the required behavior.

Higher-level APIs usually provide better compatibility with:

Raw SQL is useful when it solves a real problem, not as the default for every operation.

SQL

Understanding SQL remains important for PHP backend work.

I use it for:

Even when an ORM or platform API is involved, knowing how the underlying query behaves makes performance debugging much easier.

Database Transactions

For multi-step operations where partial completion would be dangerous, I consider transactions where the underlying database and architecture support them.

For example:

Create record
↓
Update related state
↓
Write audit data
↓
Commit

If one step fails, the operation should not necessarily leave half-completed data behind.

REST APIs

PHP can act both as an API server and an API client.

I use it to integrate external services such as:

External integrations are treated as unreliable by design.

They can:

The application needs to handle those cases.

HTTP Requests

When PHP communicates with external services, I consider:

I avoid assuming that a successful TCP connection automatically means the response contains valid application data.

JSON

JSON is a common format in PHP integrations.

I use PHP to:

I validate decoded structures before trusting them.

A syntactically valid JSON document can still contain invalid application data.

Authentication

Server-side PHP applications often need to determine who is allowed to perform an operation.

In WordPress, I work with concepts such as:

Authentication answers who the user or client is.

Authorization answers what they are allowed to do.

I keep those concepts separate.

Authorization

A logged-in user is not automatically allowed to perform every operation.

I use capability checks and application-specific rules before sensitive actions.

This is especially important for:

Authorization belongs on the server.

Nonces

In WordPress, nonces provide protection against unwanted cross-site requests in relevant authenticated workflows.

I use them where the platform expects them.

A nonce is not a replacement for permission checks.

Both request legitimacy and authorization matter.

Secrets

API keys, passwords and private credentials should not be embedded into public frontend code.

PHP is useful because sensitive integration logic can remain on the server.

For example:

Browser
↓
My Server
↓
External API

The browser does not need direct access to the secret credential.

Environment Configuration

I separate configuration from application logic where appropriate.

Values such as:

should not be scattered through source code.

This makes deployment safer and configuration easier to manage.

Error Handling

Server-side failures need deliberate handling.

Possible problems include:

I avoid exposing raw technical errors directly to users.

The application can provide a useful user-facing message while retaining enough technical information for diagnostics.

Logging

Logging is important for backend debugging.

I use logs to understand events such as:

I avoid logging secrets or unnecessary personal information.

A useful log should explain a failure without creating another security problem.

Defensive Programming

I write PHP with the assumption that unexpected states will eventually occur.

For example:

I check assumptions at boundaries instead of allowing errors to propagate unpredictably.

Null and Missing Values

External or optional data frequently contains missing values.

I distinguish between:

I prefer explicit handling over relying on notices or warnings to reveal unexpected state later.

Type Declarations

Modern PHP supports type declarations for:

Where useful, I use them to make function contracts clearer.

For example:

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

Types improve readability and help catch incorrect usage earlier.

Strict Types

For codebases where it fits the architecture, strict typing can make behavior more predictable.

The important point is consistency.

A partially typed codebase with unclear conventions can be more confusing than a clearly defined style.

Classes

I use classes when behavior and state belong together or when a component needs a clear reusable boundary.

Examples may include:

I avoid creating classes purely because object-oriented code appears more sophisticated.

The structure should solve a real maintainability problem.

Interfaces

Interfaces are useful when multiple implementations should obey the same contract.

They can improve:

For example, application logic can depend on a service interface rather than one specific external provider implementation.

Dependency Management

For larger PHP projects, dependency management matters.

I prefer explicit and controlled dependencies.

Each library introduces:

I add dependencies when they provide real value.

Composer

Outside or alongside WordPress-specific environments, Composer provides a standard mechanism for PHP dependencies and autoloading.

I use dependency management to keep third-party libraries versioned and reproducible.

I avoid manually copying random library files into a project when a proper package-management workflow is available.

Namespaces

Namespaces help organize larger PHP codebases and avoid naming collisions.

I use them where the size and structure of the project justify it.

This becomes particularly useful for custom plugins or standalone backend code containing multiple components.

Autoloading

For larger object-oriented codebases, autoloading keeps file management cleaner.

Classes can be loaded according to defined conventions rather than through large sets of manual require calls.

This improves project organization and makes dependencies easier to follow.

Separation of Concerns

I prefer separating responsibilities such as:

Request Handling
↓
Validation
↓
Business Logic
↓
Persistence / External Services
↓
Response

Mixing all of these responsibilities into one function makes future changes difficult.

The exact number of layers depends on the size of the project.

I avoid adding unnecessary architecture to simple code.

Business Logic

Business rules should not be buried inside presentation templates.

For example, if an application needs to determine whether an action is allowed, that rule should live in a reusable server-side component.

This allows the same logic to be used from:

Templates

PHP templates should primarily focus on presentation.

I try to avoid placing complex database queries and application logic directly into templates.

When presentation files remain simple, the overall system becomes easier to understand.

Server-Side Rendering

PHP is naturally suited to server-side rendering.

The server can produce complete HTML before the response reaches the browser.

This remains useful for:

Not every project requires a heavy client-side JavaScript application.

PHP and JavaScript

PHP and JavaScript have different responsibilities in many of my web projects.

A typical division is:

PHP
→ server-side data and business logic

JavaScript
→ browser interaction

The two can communicate through REST APIs or rendered configuration.

I do not move sensitive server-side logic into JavaScript simply because the interface uses JavaScript.

AJAX and Asynchronous Interfaces

Some WordPress interfaces need asynchronous updates without reloading the whole page.

I can use server-side PHP together with browser JavaScript for:

For newer structured integrations, I generally prefer clear REST-style endpoints rather than ad-hoc request handlers when that architecture fits.

Performance

PHP performance depends on more than the language itself.

I pay attention to:

A slow WordPress page is often caused by architecture or database behavior rather than a single PHP expression.

Query Performance

I avoid unnecessary repeated queries.

For example, code that loads the same metadata repeatedly inside a large loop can become expensive.

I prefer:

I measure actual bottlenecks rather than optimizing blindly.

Caching

Caching can be useful for data that is expensive to calculate and changes infrequently.

Depending on the project, this can include:

The correct caching layer depends on the data.

I do not cache personalized or transactional state without understanding the consequences.

Memory

Server requests have finite resources.

I avoid unnecessarily loading huge datasets into memory when data can be:

This is particularly important for imports, exports and automation tasks.

Batch Processing

For large processing jobs, I prefer controlled batches instead of attempting everything in one HTTP request.

For example:

Load batch
↓
Process
↓
Persist result
↓
Continue

This reduces the risk of:

Long-Running Work

A normal web request is not always the correct environment for long-running processing.

For tasks such as:

I consider background execution, queues, cron or external worker processes depending on the architecture.

The user should not need to keep one browser request open for minutes if the task belongs elsewhere.

WordPress Cron

For scheduled WordPress tasks, I can use WP-Cron when its execution model is appropriate.

I understand that WP-Cron is triggered by site activity rather than functioning exactly like a system cron daemon.

For timing-sensitive workloads, server-level scheduling may be more appropriate.

File Handling

When PHP handles uploaded files, I validate more than the filename.

I consider:

Uploads are a security boundary.

They should not be trusted simply because they came through a form.

Security

Security is part of PHP implementation, not a final checkbox.

I consider:

Many web vulnerabilities occur when data crosses from one trust boundary to another without proper handling.

Principle of Least Privilege

Application components should receive only the permissions they require.

This applies to:

Reducing unnecessary privileges limits the impact of failures.

HTTPS

Sensitive server interactions should take place over HTTPS.

This is particularly important for:

Application-level security does not replace transport security.

PHP Versions

I prefer developing against maintained PHP versions supported by the target platform.

Modern PHP provides improvements in:

I avoid unnecessary dependence on obsolete behavior where the deployment environment allows modernization.

Backward Compatibility

WordPress environments can contain a wide variety of:

When developing reusable code, I consider the actual compatibility target.

Using a language feature that the deployment server cannot execute is not a successful modernization.

Testing

I test important PHP logic independently where practical.

This is particularly useful for:

I also test the complete integration because WordPress behavior often depends on hooks and runtime context.

Debugging

When PHP functionality fails, I use evidence rather than random changes.

I inspect:

I identify which layer failed before changing code.

Production Error Display

Development environments can display detailed errors.

Production environments generally should not expose stack traces and internal paths to public users.

I keep detailed diagnostics in logs while returning controlled user-facing errors.

Git

I keep custom PHP code under Git version control.

This makes changes:

Version control is particularly important when modifying production WordPress functionality.

I avoid treating the live WordPress editor as the only copy of important application logic.

Deployment

PHP deployment needs to consider more than uploading one changed file.

A release may affect:

I prefer reproducible deployment processes where important production state is protected before major changes.

Maintainability

Readable PHP is more valuable than clever PHP.

I prefer:

A future developer should be able to understand why the code exists and what assumptions it makes.

Avoiding Overengineering

Not every WordPress customization needs a large object-oriented architecture.

Sometimes a small function and one hook are the correct solution.

For larger functionality, more structure becomes useful.

I scale the architecture according to the complexity of the problem.

The goal is maintainability, not architectural ceremony.

PHP in My Technology Stack

I commonly use PHP alongside technologies such as:

PHP provides the server-side application layer that connects these technologies.

Why I Use PHP

I use PHP because it provides direct access to one of the largest ecosystems in web development while remaining practical for custom server-side application logic.

It allows me to extend WordPress and WooCommerce without abandoning their existing content, administration and commerce infrastructure.

Its value is not simply that PHP can render a web page.

It can enforce permissions, process data, expose APIs, integrate external systems and implement business rules behind that page.

That is how I use PHP: as the server-side engineering layer that turns a WordPress-based website into a reliable, maintainable application.

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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

Mohou:

Aplikace musí umět tyto situace zpracovat.

HTTP požadavky

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

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:

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:

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:

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:

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

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:

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:

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:

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:

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:

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:

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

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:

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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.