PHP maintenance, kept online.

Laravel, WordPress and custom PHP. Security releases, feature work, and a move off a version that no longer gets patches.

06 PHP maintenance

PHP maintenance

Laravel, WordPress and custom PHP kept online: security releases, feature work, and a move off a version that no longer gets patches.

LaravelWordPressPHP 8.2+
Estimate this Talk to an engineer
What you get
Security releases for the PHP version you are on
Feature work without a rewrite as the price of entry
Takeover of an inherited codebase
A patch order before any monthly care
Typical engagementFrom a short upgrade

Build it, or take it over

Some companies need a new PHP application. More of them have one already, and the person who built it has left. We do both.

  • New products in Laravel or custom PHP: accounts, payments, admin and the workflow your team actually uses.
  • Feature work on a live WordPress, Laravel or bespoke site, without a rewrite as the price of entry.
  • Takeover of an inherited codebase: where it runs, which version, what is untested, and what to change first.

The code goes in your repository. You can stop at the end of any cycle.

Security releases, shipped

On 21 October 2026 PHP published emergency fixes for two critical bugs, CVE-2026-109618 and CVE-2026-109619. An unpatched server can be taken over before your application code runs. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 have minimal source backports from the PHP security team, and some vendors ship a package. Anything older than 7.4 does not.

A firewall rule is a stopgap. We install the fixed release for the branch you are on, retest login, checkout, uploads and queues, and tell you if an extension will not survive the jump. If the honest answer is that your host can do this today, we say so.

Laravel, WordPress and the custom app from 2016

The framework is rarely the hard part. The hard part is the site that still takes orders.

  • Laravel for applications with real business rules, queues and an admin your staff can use.
  • WordPress when the editors are the point: themes, blocks and the plugins you actually need, kept updated.
  • Custom PHP that is too important to rewrite this quarter and too old to ignore. We patch it, put tests around the risky paths, and write down what a later rebuild would keep.

When PHP should become something else

If the application is on PHP 8.1 or older and every upgrade breaks it, another patch is not a strategy. We will say that before anyone signs a retainer. The usual next step is a Django rebuild that keeps the data and puts the old URLs behind redirects, or a rescue when the stack is already Python and only the version is the problem.

How an engagement starts

A healthy site on PHP 8.2 or newer is a short upgrade and a retest. A scattered estate, old hosting and nobody sure what is live, starts with a discovery sprint: an inventory, a patch order and a recommendation you can hand to your board. Monthly care comes after that, scoped to the sites we have actually seen.

Email [email protected] or send a brief with the output of php -v and whether the site is on the public internet. If you do not know the version, say that. We reply within one working day.

Who it's for

PHP stays a supporting service. The homepage is the Python studio. This page is for a company that already has Laravel, WordPress or a custom PHP application and needs it maintained, patched or extended by the same engineers who build in Python. We do not lead with PHP, and we do not pretend a public case study exists for it. The studies on Work are the Python products.

A healthy site on a supported release is a short upgrade and a retest. An estate nobody can draw on a whiteboard starts with discovery: an inventory and a patch order, covering weeks 0–4 including a first fix on the riskiest site. Anything built after that starts in week 5. Monthly care is priced only after we have seen the sites, so this page does not print a from-price for it.

The public studies are the Python products This work usually sits inside a client's own system, so it is not written up as a named study.
See the work
Send a brief

Questions

Do you build new PHP applications?

Yes. Laravel and custom PHP for products with accounts, payments and an admin, and WordPress when editors need to publish without calling a developer.

Which PHP versions do you support?

We install at least PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, the releases named in the 21 October 2026 PHP Foundation advisory. PHP 7.4, 8.0 and 8.1 have no upstream fix. Some vendors ship a backport. Anything older than 7.4 does not. Those sites come off the internet until they move to a supported release or are replaced.

Can you maintain a site you did not build?

Yes. We start by finding every PHP runtime, including the one hiding on shared hosting, then agree what monthly care covers: security releases, backups, uptime and a named engineer.

Is a firewall enough?

No. It can block some requests while you upgrade. Updating PHP is the only complete fix, because one of the October 2026 bugs depends on state left inside a worker, which a firewall cannot see.

When would you tell us to leave PHP?

When the application is stuck on an unsupported version and each upgrade attempt breaks it. We will recommend a Django rebuild, keep the data, and map the old URLs, and we will say that before you commit to a build.