DEV Community: Dipesh Batheja

Nuxt 3 Is End of Life: Migrate to Nuxt 4 Now or Wait for Nuxt 5?

Dipesh Batheja — Wed, 11 Nov 2026 12:55:31 +0000

TL;DR: Nuxt 3 reached end of life on 31 July 2026, so it no longer receives security or bug fixes. Nuxt 5 is still unreleased as of mid-November 2026. For most production apps the answer is to migrate to Nuxt 4 now: it is the only supported version, it is a small step from Nuxt 3, and Nuxt's policy keeps it supported for at least six months after Nuxt 5 ships. Waiting only makes sense if a critical module blocks you, a change freeze is in force or the app is about to be retired, and then only with paid extended support and a dated plan.

If you pay for a Nuxt application rather than write it, the Nuxt 3 end of life can look like a developer's problem. It becomes yours the first time a security questionnaire asks which framework versions you run. This guide is for founders, product owners, agency owners and engineering managers. It covers what the Nuxt 3 EOL changes in practice, whether waiting for Nuxt 5 is a sensible bet, what makes a migration large or small, and how to keep your search rankings through the move.

What Nuxt 3 end of life means for an app in production

Your app does not stop working. Nuxt 3 stays on npm and your site keeps serving pages. What changes is what happens when something goes wrong.

No more security patches

The Nuxt roadmap lists 3.x as unsupported, with an end-of-life date of 31 July 2026. The Nuxt 4 announcement originally promised maintenance only until the end of January 2026, which is why some articles still quote that date. It was later moved to 31 July, and that date has now passed. The independent tracker endoflife.date shows the same dates.

The effect is already visible. On 2 November 2026 the Nuxt team shipped version 4.6.4, described in the release notes as a security release fixing eight advisories in Nuxt and three more in Nitro, its server engine. There was no matching 3.x release. Whether or not those issues affect Nuxt 3, nobody upstream is checking or patching that line any more.

Compliance and customer questionnaires

Running unsupported software is a recognised risk category. OWASP's Top 10 entry on Vulnerable and Outdated Components says you are likely vulnerable "if the software is vulnerable, unsupported, or out of date". If you sell to enterprises or hold SOC 2, ISO 27001 or PCI obligations, an end-of-life framework is a finding you will have to explain, with either a migration date or a compensating control.

Module support dries up

Module authors build and test against the current major version. Over time, new releases of official and community modules tend to stop supporting the old one, so a Nuxt 3 app ends up pinned to older versions of its dependencies as well. It is the pattern we describe in our post on legacy system modernisation mistakes: the upgrade never gets cheaper by waiting.

What changed in Nuxt 4, in plain language

Nuxt 4 went stable on 16 July 2025 after a year of public testing. The team called it a stability-focused release, and that is fair: there is no new rendering model and no rewrite of how pages are built. The main changes are:

A tidier project layout. Application code moves into an app/ folder. Nuxt still detects the old layout, so the move is recommended, not forced.
More consistent data fetching. The functions that load page data share results more predictably and have slightly different defaults. Most of the real code review goes here.
Stricter TypeScript. App code and server code are type-checked separately, which often surfaces bugs that were already there.
Updated metadata handling. The library that manages titles and meta tags moved to a new major version, which matters for SEO.

The Nuxt team wrote that they hoped "most Nuxt 3 projects can upgrade with a minimum of effort". The official upgrade guide rates each change by impact, and most are marked minimal. It also ships a codemod that applies the mechanical changes automatically:

npx codemod@0.18.7 nuxt/4/migration-recipe

The guide pins a specific codemod version, so check it for the current one. The codemod handles the repetitive edits. It does not test your app, check your modules or confirm your pages still render the same HTML. That is the part you pay people for.

Migrate to Nuxt 4 now or wait for Nuxt 5?

There is a serious argument for waiting. TuxCare, which sells extended support for Nuxt 3, sets it out clearly: "If you migrate 3 to 4 now, you're committing to another migration cycle once Nuxt 5 ships." Their alternative is to stay on Nuxt 3 with paid security cover, skip Nuxt 4 and jump straight to Nuxt 5 once it stabilises. To be fair to them, the same article says that "for most Nuxt 3 apps, upgrading to Nuxt 4 is the right move."

We agree with that last sentence. We have a commercial interest too, since we do migrations, so here is the reasoning for you to judge.

Where Nuxt 5 actually stands

The roadmap lists Nuxt 5 as "Q4 2026 (estimated)". As of 11 November 2026 there is no stable, beta or release-candidate version of Nuxt 5 on the releases page, and the Nuxt 5 upgrade guide says it "is still in development". Its biggest change is Nitro v3, which the guide calls "a major rewrite of the server engine". Nitro v3 itself only reached release-candidate stage at the end of October 2026, according to its release history.

An estimate is not a date. Even once Nuxt 5 ships, community modules need time to catch up with a rewritten server engine before a production app can safely move.

Why Nuxt 4 is not a wasted step

Three facts weaken the "two migrations" objection:

The support window is defined. Nuxt commits "to support each major version of Nuxt for a minimum of six months after the release of the next major version". Since Nuxt 5 has not shipped, Nuxt 4 is covered until at least May 2027, and later for every week Nuxt 5 slips.
Nuxt 4 is the on-ramp to Nuxt 5. The Nuxt 4.6 release post says "most of what's new in Nuxt 5 is already in 4.6, either on by default or behind a flag". One setting, future.compatibilityVersion: 5, switches on the Nuxt 5 defaults inside Nuxt 4 so a team can fix what breaks at its own pace.
Skipping a major doubles the jump. Going from 3 to 5 means absorbing the Nuxt 4 changes and the Nitro rewrite in one release, on an app that has had no security fixes in the meantime. Two small, tested steps carry less risk than one large one.

A decision by app type

Public marketing or content site: migrate now. It is public, the job is small and search traffic depends on it.
SaaS dashboard holding customer data: migrate now. An unpatched server layer in front of user accounts is a poor place to economise.
App under SOC 2, ISO 27001 or PCI audit: migrate now, or buy extended support to cover the gap until you can.
Still on Nuxt 2: start now and go straight to Nuxt 4.
Blocked by a module with no Nuxt 4 version: replace the module if you can. If you truly cannot, wait with extended support and review the position each quarter.
In a change freeze or regulated release window: wait with extended support, and use the time to prepare in place.
Being retired within months: do not migrate. Limit its exposure and switch it off on schedule.

If you do wait, wait with cover

Commercial extended support exists for this case. HeroDevs offers Never-Ending Support covering Nuxt 2.x and 3.x, and TuxCare sells a similar service. Both provide patched builds of the framework. They are a reasonable bridge and a poor destination: you pay a subscription to stand still while your modules keep ageing. Put an end date on it.

What drives Nuxt migration cost and effort

We are not going to print a price here. Nuxt migration cost depends on the codebase, and any number given without seeing yours would be a guess. What we can tell you is what moves the estimate.

Module count. Every module is a compatibility check. Ten well-maintained official modules are easy. Three abandoned community ones are not.
Custom modules and plugins. Code that hooks into Nuxt's internals is the code most likely to break, and no codemod understands it.
Data fetching complexity. The more pages load data in unusual ways, the more of the Nuxt 4 changes need human review.
Test coverage. With good automated tests, most of the checking is automatic. Without them, every page is checked by hand or tests are written first. See our post on non-functional testing.
Starting point. Nuxt 3 to 4 is an upgrade. Nuxt 2 to 4 is a migration to a different version of Vue, and a different size of budget.

How that plays out for three typical apps

A small marketing site has few pages, a handful of official modules and little custom code. The work is mostly mechanical, and more of the effort goes into verifying SEO parity than changing code.

A content platform (a blog, documentation site or headless storefront) has many templates, a CMS integration and heavy prerendering. Effort concentrates in data fetching and page-by-page verification, because organic traffic is the business. If your content lives in a headless CMS, give the integration its own line in the plan (our Strapi developers cover that side).

A SaaS dashboard has authentication, complex state, custom plugins and server routes. SEO matters less behind a login, but custom code and stricter TypeScript checks take longer, and test coverage decides how calm the release is.

A proper estimate starts with an audit: every module, plugin, store and build customisation, marked as compatible, replaceable or removable. That is the first step of the staged playbook we use when clients hire Nuxt developers from us: audit what you have, prepare in place, migrate in slices, verify page by page, then cut over and clean up. For wider budgeting context, see our guide to custom web application development cost.

Keeping your search rankings through the move

A framework upgrade should be invisible to Google: same URLs, same content, same or better speed. Rankings are lost when something small changes unnoticed across hundreds of pages, so we compare old and new, page by page, on five points.

Rendered HTML parity. The HTML the server sends must contain the same headings, copy and links as before. Google's JavaScript SEO guidance notes that server-side or pre-rendering "is still a great idea because it makes your website faster for users and crawlers".
Redirects. Ideally no URL changes at all. If any do, Google's site move documentation recommends mapping every old URL to its new one with permanent server-side redirects, and keeping them "for as long as possible, generally at least 1 year".
Metadata. Titles, descriptions, canonical tags and hreflang come from the library that changed in Nuxt 4. Compare them across every route.
Structured data. JSON-LD for articles, products, FAQs and breadcrumbs is easy to drop silently. Validate it before and after.
Core Web Vitals. Per web.dev, a good page has a Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads. Record your numbers before the migration so you can prove they held.

After launch, watch Search Console and your server error rates for a few weeks. This verification stage is where a specialist Nuxt development agency earns its fee. The upgrade commands are public. The discipline of checking every template is not.

Still on Nuxt 2? The longer path

Nuxt 2 reached end of life on 30 June 2024, so these apps have now been without upstream security fixes for more than two years. The path is longer because Nuxt 2 runs on Vue 2, and Nuxt 3 and 4 run on Vue 3. Three pieces of work dominate:

Vuex to Pinia. State management moves to Pinia, the store Vue now recommends.
Options API to Composition API. Not every component has to be rewritten, but mixins and anything built on Nuxt 2-only features do.
Modules and build setup. Nuxt 2 modules have to be replaced with versions built for Nuxt 3 and later, some have no direct successor, and the default build tool changes from webpack to Vite.

Nuxt Bridge, which the Nuxt docs describe as "a compatibility layer that allows you to use Nuxt 3+ features in Nuxt 2 with an opt-in mechanism", can shorten the path for large apps. For small ones it is often quicker to skip it.

Do not migrate to Nuxt 3 on the way. It is end of life too. Go straight to Nuxt 4, in slices, with old and new running side by side behind a proxy so releases continue. If your app is plain Vue 2 with Vuex rather than Nuxt, the same staged approach applies, and our Vue.js developers handle those upgrades. Agencies with client sites on old versions can run this under their own brand through our white-label web development service.

Frequently asked questions

Is Nuxt 3 still supported?

No. Nuxt 3 reached end of life on 31 July 2026 and no longer receives security or bug fixes from the Nuxt team. Nuxt 4 is the only supported major version.

When will Nuxt 5 be released?

The official roadmap lists Nuxt 5 as "Q4 2026 (estimated)". As of 11 November 2026 it has not been released, and its upgrade guide describes it as still in development.

Should I skip Nuxt 4 and go straight to Nuxt 5?

For most apps, no. Nuxt 4 is supported for at least six months after Nuxt 5 ships, and it lets you switch on Nuxt 5 behaviour early with a compatibility flag. Skipping it means running unpatched software until Nuxt 5 and its modules are stable.

How hard is it to upgrade Nuxt 3 to Nuxt 4?

For most apps it is a modest upgrade. The official codemod handles the mechanical changes. Module count, custom code and test coverage decide the rest.

Can I migrate from Nuxt 2 directly to Nuxt 4?

Yes, and you should, since Nuxt 3 is also end of life. It is a larger project because it includes the move from Vue 2 to Vue 3, Vuex to Pinia and a new build setup, so it is best done in stages.

Final thoughts

The Nuxt 3 end of life is not an emergency, but it should not be ignored. For most teams the sensible move is to upgrade to Nuxt 4 now while the step is small, switch on the Nuxt 5 compatibility flag when you are ready, and take Nuxt 5 as a routine upgrade once it and your modules have settled. If you have to wait, do it with extended support and a date in the calendar.

Our own website runs on Nuxt 4, and migrations are the most common reason teams hire Nuxt developers from us. If you want a written audit and a staged plan before you commit a budget, tell us about your app or send us a project brief. To hand over upgrades for good, our Support service covers dependency updates, monitoring and fixes for live apps.

Originally published at netling.digital.

PHP2Shell and PHP 8.2 End of Life: What to Do With Your Client WordPress Sites Before 2027

Dipesh Batheja — Wed, 11 Nov 2026 12:52:57 +0000

TL;DR: PHP2Shell is a pair of critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) that are being exploited now. Every WordPress site needs to be on a fixed build today: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched package from your host. Separately, PHP 8.2 end of life is 31 December 2026, after which it gets no security fixes at all, and several managed hosts remove it earlier in December. Treat both as one job: confirm the patch this week, then move every site you look after to PHP 8.3 at minimum, and ideally 8.4, before the year ends.

Agencies look after more WordPress sites than they have usually counted in one place, and most business owners have one on hosting someone else chose years ago. This guide covers PHP2Shell for WordPress sites in plain language, what PHP 8.2 end of life changes, how to sort a portfolio of client sites, and a routine for upgrading each one without breaking it.

Two deadlines, one job

The first deadline has already passed. On 21 October 2026 the PHP project released emergency security updates and asked all users to update immediately. Any site still on an older build is exposed today.

The second deadline is 31 December 2026. The official supported versions page lists that as the last day of security support for PHP 8.2. The PHP 8.2.35 release note says it plainly: 8.2 "will receive no further security fixes after that date".

Both are solved in the same place, the PHP version on the server, so run them as one project and test each client site once.

PHP2Shell in plain language

PHP is the programming language WordPress runs on. PHP2Shell is the nickname for two flaws in PHP itself, not in WordPress, a theme or a plugin. They can let an attacker run their own code on the web server without logging in. The PHP security team rated both 9.2 out of 10 on the CVSS v4.0 scale. Security firm Patchstack, which credits the name to Wiz Research, reports that at least one of the two issues affects every PHP version back to 5.4.

Because the flaw sits below WordPress, updating WordPress core or plugins does nothing about it. PHP's release notes are blunt: "There are no complete mitigations, updating is the only safe choice."

Which PHP versions are fixed

PHP 8.5: fixed in 8.5.12
PHP 8.4: fixed in 8.4.27
PHP 8.3: fixed in 8.3.36
PHP 8.2: fixed in 8.2.35
PHP 8.1, 8.0 and 7.4: no official release, only minimal source-code backports for people who build PHP themselves. Some hosts and Linux distributions ship their own patched packages.
PHP 7.3 and older: nothing from the PHP project.

We checked php.net on 11 November 2026, and these are still the current releases. A related issue, CVE-2026-115560, is waiting for the next regular PHP release. PHP calls the setup it needs unlikely in practice, but the "fixed" version numbers will move again soon. Patching is never done once.

What "exploited in the wild" means for an ordinary site

On 26 October 2026 the US cybersecurity agency CISA added both flaws to its Known Exploited Vulnerabilities catalog, its list of bugs that attackers are known to be using, and gave US federal agencies until 29 October to deal with them.

That does not mean somebody has singled out your site. Attacks like this are automated sweeps of the whole internet, and they find a five-page brochure site as easily as a busy store. Being small is no protection.

Who actually applies the patch

There is no "update PHP" button in the WordPress dashboard. Who patches depends on the hosting.

Managed WordPress hosting: the host patches PHP for you. Kinsta, for example, said its customers "don’t need to install any patches or make changes to their websites" because the fix was applied across its platform. Look for a statement like this from your own host.
Shared hosting with a control panel: the host updates PHP, but you usually choose which branch each site uses. On a very old branch, the host may have had nothing to install.
A VPS, cloud server or anything self-managed: you, or whoever set the server up, must install the update. If that person has moved on, nobody is doing it.

Most agencies have all three across their client list.

How to check a WordPress site's PHP version

WordPress shows the PHP version itself. Log in as an administrator and go to Tools, then Site Health, then the Info tab, and open the Server section. The Site Health documentation describes each panel, and the Status tab warns you when the site "is running an outdated version of PHP, which requires an update".

Why the exact patch release matters

"PHP 8.2" is not an answer. PHP 8.2.34 is vulnerable and 8.2.35 is fixed, and they look identical in most hosting dashboards. You need the full three-part number.

There is a catch. Hosts that patch end-of-life branches themselves usually keep the old version number, so a site showing 8.1 or 7.4 may or may not be patched. You cannot tell from the dashboard.

What to ask the host

Send the same three questions for every hosting account and keep the replies:

Which exact PHP build is this site running, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619?
On what date was the fix applied, and did it cover staging and inactive environments too?
On what date will you remove PHP 8.2, and what happens to sites still on it?

PHP 8.2 end of life: why this is the same story

PHP 8.2 received a proper PHP2Shell fix for one reason: it was still inside its security support window. PHP 8.1 left that window on 31 December 2025, according to PHP's end-of-life list. Ten months later its users got a source patch and a suggestion to ask their vendor. PHP 8.2 users will be in that position from 1 January 2027.

OWASP's Top 10 entry on Vulnerable and Outdated Components says you are likely vulnerable "if the software is vulnerable, unsupported, or out of date". CISA's PHP2Shell alert went further and advised taking systems offline if they cannot be updated or run PHP 8.1 or earlier. We covered the same pattern for JavaScript frameworks in our post on the Nuxt 3 end of life.

How many WordPress sites are affected

We read the figures behind the WordPress.org statistics page on 11 November 2026:

45.3% of WordPress sites run PHP 8.3 or newer, which keeps security support into 2027 and beyond.
22.5% run PHP 8.2, which loses it on 31 December 2026.
32.2% run PHP 8.1 or older, which is already unsupported. PHP 7.4 alone accounts for 14.4%.

Put together, 54.7% of WordPress sites will be on an unsupported PHP version on New Year's Day unless someone moves them.

Your host may switch before PHP does

Managed hosts do not wait for 31 December. Three published schedules:

Pressable retires PHP 8.2 on 8 December 2026 and automatically moves remaining sites to the next PHP version.
WP Cloud removes PHP 8.2 on 15 December 2026 at 12:00 UTC.
WordPress VIP starts updating non-production environments to PHP 8.3 on 16 November 2026 and production on 7 December 2026.

An untested switch on the host's timetable, in the busiest retail month of the year, is the outcome to avoid. Find your host's date and work back from it.

Which PHP version to move to

PHP 8.3 is the minimum. WordPress's own requirements page recommends "PHP version 8.3 or greater". Security support runs to 31 December 2027, so it buys one year.
PHP 8.4 is the target. Security support runs to 31 December 2028: two quiet years instead of one. The WordPress core team's PHP compatibility table lists WordPress 7.0 and 7.1 as supporting it.
PHP 8.5 is fine for well-kept sites. It is covered until 31 December 2029, but only 6.5% of WordPress sites run it so far, so less common plugins have had less real-world use on it. PHP 8.6 is not out yet (the first stable release is planned for 19 November 2026) and is too new for client sites.

What tends to break

A current WordPress release is rarely the problem. The risk is everything added to it:

Abandoned plugins. Patchstack's State of WordPress Security in 2026 counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins, and found that 46% had no fix from the developer in time for public disclosure. A plugin nobody maintains has not been tested on PHP 8.4 either.
Old premium themes. Bought once, customised heavily and never updated, because updating would wipe the changes.
Custom code. Snippets in the theme, a bespoke plugin from a previous developer, or an integration with a booking or payment system.

The size of the jump matters. From 8.2 to 8.3 or 8.4, problems are mostly warnings about outdated code. From 7.4 you cross a major version in which PHP became stricter and removed old features, and that is where white screens come from. If the site no longer has a developer, that is the moment to hire a WordPress developer to take it over.

Triage for a portfolio of client sites

Start with a spreadsheet: one row per site, with the host, who controls the server, the exact PHP version, the WordPress version and whether a staging copy exists. You will reuse this list every year.

One rule applies to every row: the site must be on a fixed PHP build this week, whatever branch it is on. Then put each site in one of three groups.

Patch now. Healthy sites on current WordPress with maintained plugins and theme. Confirm the fixed build, test on staging and switch to PHP 8.4. Each site is a small job.
Needs work. Sites that throw errors on staging, or that are still on 7.4, 8.0 or 8.1 because something broke the last time anyone tried. Get a patched package from the host as a stopgap, then schedule development time to replace the dead plugin, repair the theme or fix the custom code.
Retire. Old campaign microsites, sites for clients who stopped paying, forgotten staging copies and demos. Nobody will fund fixing them, so archive each one as static pages or take it offline. An unpatched site nobody owns puts everything else on the same server at risk.

Within each group, start with stores, membership sites and anything holding personal data, then servers you manage yourself, then sites on a host with a December cut-off.

The per-site upgrade routine

For each site in the first two groups, the routine is the same:

Back up. Take a full backup of files and database and confirm it restores.
Copy to staging. Use the host's staging feature or a private copy. Never test on the live site.
Update first. Bring WordPress core, plugins and the theme up to date on staging before touching PHP, so you change one thing at a time.
Check compatibility. Check each plugin and the theme for a recent update and stated support for your target PHP version. Have a developer review custom code.
Switch staging and read the error log. Turn on WordPress debug logging, then click through the pages that matter: forms, checkout, login, search and the editor. A page that looks fine can still be logging errors.
Switch live at a quiet time. Keep the previous version available as a rollback for a few days.
Monitor. Watch the error log, form submissions and orders for a week, then update your spreadsheet.

On a "needs work" site, step 4 becomes a small development project. Our post on non-functional testing explains why untested changes carry the risk.

Talking to clients, and where this fits in a care plan

Clients do not need the CVE numbers. They need three things: a serious flaw was found in the software underneath every WordPress site, theirs has been checked and patched, and its PHP version is being retired in December, so you recommend moving it now. Send that before they read about PHP2Shell elsewhere.

Be clear about what is included. On a care plan, the patch check and a routine PHP switch should sit inside it. Replacing an abandoned plugin or repairing an old theme is development work, and it is fair to quote for it separately. If the client has no plan, this is an honest moment to offer one.

PHP retires a branch every December: 8.1 in 2025, 8.2 this year, 8.3 in 2027. A care plan that lists an annual PHP review alongside core, theme and plugin updates turns a yearly scramble into a calendar entry. It is also predictable, recurring work that is easy to hand to a delivery partner, as we explain in our post on white-label partnerships for agencies.

If you do not have the hands

Thirty sites, each needing a backup, a staging test and a log review, is real work on top of a full pipeline. It is the maintenance and takeover work our WordPress team does: core, theme and plugin updates, bug fixes and small changes, including for sites another developer built and left behind. Agencies use our white-label WordPress development for it, with our developers working in your tools, under NDA, and never contacting your clients unless you ask. One-off clean-ups can run on hourly billing, and ongoing care can run on a monthly retainer with timesheets you can bill from. For work beyond WordPress, see our white-label web development service.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. They can let an attacker run code on a web server without logging in, and CISA lists both as actively exploited.

Does PHP2Shell affect WordPress sites?

Yes. WordPress runs on PHP, so any WordPress site on an unpatched PHP build is exposed, whatever plugins or theme it uses. Updating WordPress does not fix it. The host, or whoever manages the server, has to update PHP.

Which PHP version fixes PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 received source-code backports only, so sites on those branches depend on a patched package from their host or Linux distribution. PHP 7.3 and older received nothing from the PHP project.

When is PHP 8.2 end of life?

PHP 8.2 security support ends on 31 December 2026, after which it receives no fixes from the PHP project. Some managed WordPress hosts remove it earlier: Pressable on 8 December 2026 and WP Cloud on 15 December 2026.

Which PHP version should a WordPress site use now?

PHP 8.3 at minimum, which WordPress itself recommends, and PHP 8.4 for most sites because it has security support until 31 December 2028. Test on a staging copy first, since old plugins, themes and custom code are what usually break.

Final thoughts

Confirm every site is on a patched build this week, sort your sites into patch now, needs work and retire, and move the first two groups to PHP 8.3 or 8.4 before your host's December cut-off does it for you.

If you would rather hand the list to someone, you can hire WordPress developers from us for a one-off clean-up or an ongoing retainer, under your own brand if you are an agency. Tell us how many sites you look after or send us a brief.

Image credit: the PHP logo in the featured image is by Colin Viebrock, used unmodified under CC BY-SA 4.0.

Originally published at netling.digital.