PHP 8.2 End of Life: Monaco Sites

On 31 December 2026, PHP 8.2 reaches the end of its security support. From 1 January 2027, the PHP project will no longer publish fixes for that branch, however serious the flaw. A week ago, the PHP2Shell flaws took the Prince's Government, the Palace and the Mairie de Monaco websites offline for a precautionary patch. The next flaw of that kind, if it arrives in 2027, will have no official fix for anyone still on 8.2.

This is not an emergency. It is a date, nine weeks away, that most Monaco business owners have never heard of and that their host may or may not handle for them. Here is what changes, how to find out whether you are affected, and how to move in time without breaking your site during the festive season.

What actually ends on 31 December 2026

PHP, the language behind WordPress, WooCommerce, PrestaShop, Drupal, Laravel and a great deal of custom code, is released in yearly branches. Each gets two years of active support, then a period of security-only fixes. PHP 8.2 was released in December 2022, left active support at the end of 2024, and loses security support on 31 December 2026.

The supported branches after that date, according to php.net, are 8.3 (security fixes until the end of 2027), 8.4 (until the end of 2028) and 8.5 (until the end of 2029).

End of life does not mean your website stops working on 1 January. It means that any vulnerability disclosed after that date stays open on 8.2 unless someone other than the PHP project patches it. Some operating-system vendors and hosting companies do backport fixes to older branches for their own customers. That can buy time, but it is a promise you need in writing from your host, not an assumption.

Why this matters more in Monaco than it sounds

Most Monaco business sites run on PHP. Hotels, restaurants, agencies, boutiques, law firms and family offices in the Principality overwhelmingly use WordPress or another PHP platform. The October shutdown of the Government's own sites showed this reaches the biggest and smallest sites in the country equally.

Monaco's data protection law expects supported software. Law No. 1.565 of 3 December 2024, supervised by the APDP, requires controllers to put in place security measures appropriate to the risk, and to notify breaches. Running a web server on software with publicly known, unpatched flaws is difficult to defend after an incident, and a contact form or client area on such a site processes personal data by definition. We are not lawyers, so confirm your specific obligations with a qualified adviser, but the direction of travel is clear.

Your host may upgrade you whether you are ready or not. Many shared-hosting providers automatically move customers off end-of-life PHP versions. If that happens in January while nobody is watching, an old theme or plugin can take the whole site down. Moving on your own schedule is far safer than being moved.

Find out where you stand

Start with a list of every site you own, not just the main one. Microsites from a past campaign, a booking subdomain, the staging copy nobody deleted: each runs its own PHP version and each is reachable from the internet.

For each site, find the PHP version. In WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section. On other platforms, ask your host or developer and insist on a written answer. Anything showing 8.2 or lower goes on the action list; anything on 8.1 or lower is already unsupported and should move first.

Then look at what the site is built with. Every WordPress theme and plugin declares a "Requires PHP" and a "Tested up to" value on its listing page. Plugins that have not been updated in more than a year, or that no longer exist in the directory, are the ones most likely to break on a newer PHP version.

Which version to move to

For most Monaco sites, PHP 8.4 is the sensible target. It is supported until the end of 2028, it is widely available on mainstream hosts, and the plugin ecosystem has had two years to adapt to it. PHP 8.3 is an acceptable fallback if a critical plugin does not yet support 8.4, but it only buys one extra year.

Whatever you choose, test on a staging copy first. The typical breakages are predictable: themes that rely on deprecated behaviour, abandoned plugins, custom functions that were written for PHP 7, and old third-party libraries bundled inside a plugin. On a well-maintained site the switch takes an afternoon. On a neglected one it can take days, mostly spent replacing plugins nobody has touched since launch. Our WordPress team does this routinely, and it always costs less than a January outage.

A nine-week plan that avoids the Christmas trade

• Now until mid-November: inventory. List every site, its PHP version, its host, and who has access. Confirm which plugins and themes block an upgrade.
• Mid to late November: test. Clone each site to staging, switch the PHP version, and go through the pages that make you money: contact form, booking flow, e-commerce checkout, client login, multilingual switcher.
• Before 10 December: switch. For retail, hospitality and e-commerce, the quiet window closes in early December. Switch early, then leave the site alone over the busy period.
• January: review. Check error logs, confirm backups are running against the new version, and document what was done. If any site stayed on 8.2, that is the first job of 2027.

If you cannot make the date

Some sites genuinely cannot move in time: a custom platform whose developer has gone, an essential plugin that is abandoned, a budget already spent. Then get three things in writing from your host: whether they will backport security fixes to 8.2 and for how long, what firewall sits in front of your site, and when they intend to force an upgrade. Set a migration date in the first quarter of 2027 and treat the gap as a known risk.

Often the inventory reveals something else: the site is six or seven years old, built on a theme nobody supports, and the honest answer is a rebuild rather than another patch. If so, a measured web development project started in January will cost less and achieve more than a series of emergency fixes. Either way, a proper website maintenance plan is what stops this from being a surprise next time.

If you would like us to check your sites' PHP versions and tell you plainly what needs doing before 31 December, get in touch. The first look takes us less than an hour.