PHP

The organisation needs a content platform, commerce site or custom web application and PHP already underpins the strongest product option. The language choice should be judged through that maintained framework and operating model, not through memories of PHP code written fifteen years ago.

Modern PHP offers type declarations, exceptions, attributes, enums and a mature package ecosystem. Its common request lifecycle remains a practical web boundary, while queues and long-running servers change assumptions about state and deployment. WordPress, WooCommerce and Laravel use the same language for very different products.

We choose PHP because one of those product ecosystems fits, then record the runtime support and application ownership needed to keep it current.

PHP’s value is usually attached to a product ecosystem

WordPress gives editors a publishing platform, WooCommerce adds a commerce system and Laravel supplies conventions for custom business applications. Selecting PHP without choosing the product shape says little about delivery.

The ecosystem can be decisive. Rebuilding a well-fit CMS in another language creates years of editorial and plugin work. Using WordPress to carry a dense operational workflow can be equally misguided. The requirement leads to framework or platform, which leads to PHP.

For a custom API, we compare PHP and Laravel with the organisation’s current backend capability. PHP is credible when the team can operate it and its conventions reduce work. It should not become a new runtime solely because one supplier has a preferred stack.

The application architecture remains more important than language reputation. Current PHP can support clear, tested software; an unsupported framework can still make it risky.

The request lifecycle provides a useful reset boundary

Traditional PHP-FPM handles a request in a worker and releases application state at the end. That reduces some classes of cross-request memory and global-state problem and makes deployments conceptually straightforward.

It does not remove state. Sessions, caches, files, databases and remote services persist. Static values and opcodes may remain in worker processes. Requests need timeouts, transaction boundaries and idempotency like any server application.

We keep request handlers small and move durable work to jobs with explicit ownership. Uploads, report generation and webhook retries should not depend on one browser connection staying open.

PHP can also run long-lived application servers and workers. Once it does, code written with request-reset assumptions needs review for retained objects, stale service state and connections.

Type declarations improve owned contracts

PHP supports parameter, return, property and class-constant type declarations. The type declaration manual explains when invalid values produce TypeError and how coercion relates to strict typing.

Types make service and domain interfaces easier to reason about, especially alongside static analysis. They do not validate an HTTP request, database record or decoded JSON by themselves. Input is parsed into typed values at the boundary.

Enabling strict types is per file and affects scalar calls from that file. It is useful within a disciplined codebase but is not a global promise that every package uses the same coercion expectations.

We avoid broad arrays carrying undocumented shapes through the application. Value objects, enums and data-transfer objects can make important states explicit. For flexible metadata, a validated array may still be the clearer solution.

Static-analysis suppressions and mixed types are tracked. A clean tool report achieved through baseline growth is weak evidence.

Composer dependencies form the application supply chain

Composer resolves PHP packages and autoloading from project constraints. Applications commit the lockfile so CI and production install the same resolved versions. Libraries publish broader constraints for consumers.

We distinguish composer install from an intentional update, use trusted repositories and run install without development packages and scripts the production build does not require. Plugins and scripts can execute code during dependency operations and deserve review.

Framework and package security notices enter an update process. composer audit can report known advisories and abandoned packages; maintainers still assess reachability and a safe replacement.

A package used for a small helper carries licence, support and transitive dependencies. We favour mature framework capability and remove unused packages as the application evolves.

Private package access and credentials belong in the build environment, not composer.json or the resulting image.

PHP-FPM capacity has to match the application

PHP-FPM manages pools of worker processes. Each concurrent dynamic request needs a worker, and each worker consumes memory according to the application and request. Too few workers cause queueing; too many can exhaust the host and trigger wider failure.

The FPM configuration manual documents static, dynamic and on-demand process management and request controls. We size from measured worker memory, CPU and target concurrency rather than copying a generic formula.

Slow logs and application traces identify requests holding workers. Nginx and FPM timeouts should express one policy; conflicting values can terminate work at one layer while it continues at another.

OPcache reduces repeated compilation and needs a deployment invalidation or reset approach that matches file replacement. Realpath and filesystem caches can also make release behaviour differ from a development server.

Health includes FPM queue and worker saturation alongside an HTTP response from a cached page.

Queues and persistent workers change deployment

Laravel queue workers and other PHP daemons keep the framework and loaded classes in memory across jobs. A deployment that replaces files does not update an already-running worker. Framework guidance therefore includes controlled worker restart.

Jobs release resources and clear tenant or request-specific state after each item. Database connections, event listeners, static caches and large objects can persist longer than expected. Memory limits and planned recycling can contain faults while the root cause is investigated.

Each job defines retries, timeout, idempotency and failed-item handling. A worker killed after an external side effect but before acknowledgement may receive the same job again.

Signals and graceful shutdown are tested through the process monitor or container. A restart should stop taking new work, complete within a deadline and allow replacement capacity to start.

PHP versions create a clear maintenance calendar

PHP branches receive active support and then security-only support before end of life. The official supported versions page publishes current dates.

The production inventory records PHP, extensions, framework, server API and operating system. Updating the language can expose deprecations and stricter behaviour in old packages, so we test regularly rather than waiting for end of support.

Hosting control panels and managed platforms may lag or remove old versions on their own schedule. The application should not depend on an unsupported interpreter merely because one host still offers it.

Extensions such as database drivers and image libraries need compatible builds. Container images or automated server configuration keep their versions reproducible.

Regular small upgrades improve the chance that maintained packages still provide a direct route.

Legacy PHP modernisation should protect behaviour first

An inherited application may mix direct SQL, global state, old framework code and server assumptions. A full rewrite can lose obscure but valuable rules. Leaving it on an unsupported runtime can block security and hosting changes.

We first reproduce the build and production request path, add characterisation tests around revenue and data flows and enable logging that identifies current failures. Static analysis can reveal undefined shapes and unsafe calls incrementally.

Runtime and framework upgrades are separated where possible. Compatibility tools identify deprecated features, while dependency replacement and database changes receive their own tests.

New modules can use current conventions behind stable interfaces. Strangler routes can move isolated capabilities without forcing two applications to edit the same data inconsistently.

The business case should name support, incident, delivery or product value, not “PHP is old.”

Questions to answer before approving PHP

• “Which PHP product ecosystem fits the requirement?” Choose CMS, commerce or custom application deliberately.
• “Which external values enter typed domain code?” Validate at request and data boundaries.
• “Which Composer packages and scripts execute in the build?” Lock and audit them.
• “How many FPM workers fit measured memory and CPU?” Observe saturation and slow requests.
• “Which processes survive beyond one request?” Restart and clear persistent workers.
• “When does the selected PHP branch leave support?” Put upgrades on the calendar.
• “Which legacy behaviours need tests before modernisation?” Protect business rules first.

When PHP is a sound web language

Choose PHP when Laravel, WordPress, WooCommerce or another maintained ecosystem directly fits the product and the team can own its runtime and packages. Its request model and hosting options remain practical for a large range of web services.

The decision is complete with a supported PHP line, controlled Composer graph, measured FPM pool and restart policy for long-running work.

When PHP is being chosen for the wrong inheritance

Do not use WordPress or PHP merely because an old website exists if the new requirement is a distinct application and another maintained capability fits better. Reuse content or data without inheriting every old assumption.

Avoid keeping an end-of-life interpreter because upgrading looks risky. Unsupported runtime is risk already; stage the work and protect behaviour with tests.

And resist a language rewrite without evidence. Poor schema, neglected dependencies and missing ownership can follow the product into any stack.