Since the PHP2Shell story went round, the phone has rung more than usual. Mostly from business owners who, until last week, had never really thought about who was looking after their website. Then they realised the honest answer was "nobody", and they wanted a chat.
A scare does our sales job for us, which is not something we particularly want. We would much rather you came to us for a sensible conversation before something has gone wrong on your site than after. So this post is for the people who did ring up, and for the ones who meant to but got distracted.
If you missed it, we wrote about our 24 hours with PHP2Shell. The two-sentence version is that a serious flaw was found in PHP, the software underneath most of the internet, and anyone running an unpatched server was briefly a sitting duck. The fix is in. The lesson, if there was one, is that most owners had no idea whether their site was patched or not, because nobody was watching.
The honest truth is that almost nothing goes wrong on a website that was being properly looked after. Almost everything goes wrong on sites where nobody was. The gap between the two is three bits of work. Keeping the plugins current, keeping the PHP underneath on a version that still gets security fixes and keeping the old code on top of it compatible with the modern version. Here they are, with the jargon stripped out so you can see what matters for your own site.
Keeping plugins up to date
A typical small business WordPress site has somewhere between 20 and 30 plugins installed. Each one is a piece of code written by somebody you have never met, doing a specific job on your site. They are brilliant when they work. They are the single biggest source of security problems on the web when they are not kept current.
The 2026 numbers from Patchstack are a bit startling. There were 11,334 new WordPress vulnerabilities disclosed in 2025, up 42 percent on the year before. Ninety-one percent of them were in plugins. Nine percent were in themes. Six were in WordPress core itself. Six, in the entire year, across the whole of core. The core team are extremely good at their job. The plugins are where almost all of the risk lives.
Speed matters more than most people realise too. The same report found the most targeted of those flaws were being exploited within five hours of going public, and about half of the high-impact ones were being hit within 24. "I will get round to it next month" is not a plan. "I will do it after the weekend" is often too slow.
Here is the one that catches people out. Forty-six percent of those vulnerabilities had no fix available from the plugin developer at the point they went public. Which means pressing update does nothing. In those cases the only sensible move is to replace the plugin with a maintained alternative, or remove it altogether. That is a judgement call, not a button, and it is why "press update when WordPress tells you to" is not quite the same job as proper plugin maintenance.
Most people avoid updates because updates can break things. Fair enough, they can. The way around that is to back the site up first, apply the update on a copy, check nothing has fallen over and only then push it to the live site. That is a lot more fiddly to do than it is to describe. It is also most of our Thursdays.
The other thing worth saying is that fewer plugins means less of this to go wrong. Where we can build a feature properly into the site in code, we do. Smaller plugin pile, fewer things updating in the night, less to go sideways.
Running a supported version of PHP
PHP is the engine underneath WordPress, Statamic, Laravel and most of the web. Updating WordPress does not update PHP. Updating plugins does not update PHP. PHP is a hosting job, which is exactly why PHP2Shell caught so many people off guard. They had been pressing the update buttons in the admin dashboard and assumed that was the lot.
Every version of PHP has a shelf life. After its end date it stops receiving security fixes. Not just the critical ones, not just the inconvenient ones. All of them. Here is where the versions sit now, straight from php.net's supported versions page:
PHP 8.1 and anything older: no longer supported at all.
PHP 8.2: security fixes end on 31 December 2026. That is weeks away as this post goes up.
PHP 8.3: supported until 31 December 2027.
PHP 8.4: supported until 31 December 2028.
PHP 8.5: the latest version, supported until 31 December 2029.
The 8.2 deadline is why I am writing this bit now. There are a lot of sites still on it, and most of their owners have no idea. If you want to check your own, log into the WordPress admin, go to Tools, then Site Health, then the Info tab, then expand the Server section. It tells you the version of PHP your site is actually running on. If it begins with 8.1 or lower you are already on a version that gets no security fixes. If it starts with 8.2, you have a bit of runway, but not much.
Updating the old code underneath
PHP does not just get patched. It changes. Every new version removes functions that have been retired and tweaks the way some things work. Mostly for the better. The catch is that older themes, custom code and abandoned plugins often lean on exactly the pieces that have been taken out. So when the hosting is upgraded, those older bits stop working. Sometimes a page starts behaving oddly. Sometimes it goes blank white.
This is why a lot of sites end up stuck on old PHP. The owner, or whoever built the site originally, puts the upgrade off because the site might break. Then another year goes by. Then PHP 7 goes end of life. Then another year. By the time the upgrade genuinely has to happen, the gap between where the site is and where the server needs to be is enormous, and the job of closing it is a proper piece of work rather than a routine update. Left too long, the cheapest sensible option can quietly become a rebuild rather than a repair.
The way we handle it is unglamorous and effective. Check the site code against the version of PHP we are moving it to. Find anything that will break and fix it or replace it. Spin up a copy of the whole site on the newer version, test the bits that actually matter: contact forms, checkout, logins, the admin itself. Only switch the live site over once the copy is behaving. The client sees a quiet hop from one version to the next. We see the twenty hours underneath.
What our support actually covers
Our support plans are built around those three bits of work and a few more. In our own words, roughly in the order you would notice them:
A real person who already knows your site. Not a ticket queue, not a chatbot asking you to describe the issue in three to five words. If you email, you reach the same team every time.
Plugin, theme and WordPress updates applied carefully. Backup first, apply on a copy, check the site, push to live. In that order, every time.
PHP kept on a supported version, with the compatibility work done for you so nothing breaks on the way across.
Someone keeping an eye on the security news so you do not have to. PHP2Shell is the live example. Servers patched, every client site checked, email out to all of them while they carried on with their day.
Help when something has gone sideways. The occasional 'can you just...' job. Small fixes, small changes, odd questions. All part of it.
Plans cover WordPress, WooCommerce, Shopify and Statamic too, not just WordPress. WordPress is still the biggest part of what we do, and plenty of our support clients had their sites built somewhere else originally. The previous developer moved on, retired or got bored, and they needed someone to pick it up. That is a normal starting point for us, not an unusual one.
A five minute check for your own site
If nothing else, do this now. It costs you five minutes and tells you more than you might think.
What version of PHP is your site running? Tools, then Site Health, then the Info tab, then expand Server.
How many plugin updates are waiting in the dashboard? Just counting, not deciding whether to apply them yet.
Are any of your plugins no longer maintained? Open each one's page on wordpress.org and look at 'last updated'. More than a year ago is a worry.
When was your site last backed up, and if the answer is 'the host does it, I think', could you actually get a copy out and restore from it?
If your site broke tonight, who are you ringing in the morning?
That last one is the question. If the answer is 'I am not sure' or 'the agency we used three years ago who do not reply any more', the rest of the checklist is beside the point.
If any of that made you wince
If you went through those five questions and did not like your answers, give us a ring or book a call. We would honestly rather you came to us before a scare than after one. Even if you decide not to go with us, you will come away with a clearer idea of what your site needs, and that is useful on its own.
Nothing on your site is broken this afternoon. That is the time to think about this, not Thursday evening when it is.
Brad Goddard
·
Founder, We Are Jungle
·
30 October 2026
