DEV Community: Muhammad Zeeshan Sardar

Next.js 15 Support Ends Oct 21: The Upgrade Changes Your Build Won't Catch

Muhammad Zeeshan Sardar — Wed, 14 Oct 2026 14:30:00 +0000

TL;DR: Next.js 15 leaves its support window on 21 October 2026. Run the upgrade codemod and the separate next-async-request-api codemod, then test the things a build can't: image quality now defaults to 75 only, image cache TTL went from 60 seconds to 4 hours, next build no longer lints, sitemap id is a Promise<string>, and proxy.ts runs on Node.js only.

Next.js 15 leaves its support window on 21 October 2026. From that date, the version most production Next.js apps still run on stops receiving the critical fixes and security updates it has been getting since Next.js 16 shipped a year ago.

Most upgrade guides stop at "run the codemod and fix the type errors." That gets you a green build. It does not get you a finished upgrade, because several of the changes in Next.js 16 compile cleanly and then quietly change what your users see: image quality, how long images stay cached, whether your CI still lints, and how the page scrolls between routes.

This guide is the checklist we work through on every Next.js upgrade. It is organised so you can run it top to bottom, and every section opens with the answer so you can skip to the parts that apply to your app. Version numbers are current as of 13 October 2026: Next.js 16.4.0 is the latest stable release, and the newest Next.js 15 backport is 15.5.27.

What happens to Next.js 15 on October 21, 2026

Next.js 15 reaches the end of its Maintenance LTS period on 21 October 2026, two years after its release on 21 October 2024. After that date it falls outside the Next.js support policy, which means no more scheduled critical bug fixes or security patches.

Your app does not stop working on the 22nd. Nothing is switched off. What changes is the risk profile: the next vulnerability disclosed in the framework will be fixed in Next.js 16, and a Next.js 15 app will either need that upgrade done under pressure or stay exposed. The policy does allow for patching unsupported versions "in rare circumstances" for severe issues, but that is an exception, not a plan.

The support model works like this. A major version stays in Active LTS, with features, fixes and security patches, until the next major ships. It then moves to Maintenance LTS, where it only receives critical bug fixes and essential security updates, for two years from its original release date. Next.js 16 has been Active LTS since 21 October 2025. Next.js 15 has been in maintenance since the same day, and its clock runs out next week.

If you are still on Next.js 14, you are already a year past its end of life, which was 26 October 2025. The same upgrade path applies, with the Next.js 15 breaking changes stacked on top.

Why a green build is not a finished upgrade

A passing next build proves your code compiles under the new rules. It says nothing about whether the app behaves the way it did before, and in Next.js 16 several changes are deliberately silent.

The official upgrade guide says as much in its own migration checklist: a green build alone does not close runtime findings. Here are the changes that fit that description, each covered in detail below:

Image requests for a quality other than 75 are now quietly coerced to the nearest allowed value, so images can look different without any error in the build.
Optimised images without cache headers now stay cached for four hours instead of sixty seconds, so an image replaced in your CMS can keep serving the old version all afternoon.
next build no longer runs ESLint, so a pipeline that relied on the build to catch lint errors now ships them.
Next.js no longer overrides a global scroll-behavior: smooth during route changes, so navigations that used to jump to the top now animate.
A sitemap id is now a promise of a string, and plain JavaScript will not warn you when arithmetic on it produces the wrong number.

Each of these is a reasonable default on its own. Together they are why the testing section near the end of this guide matters more than the codemod at the start.

Check Node.js, TypeScript and browser requirements first

Next.js 16 requires Node.js 20.9.0 or newer, TypeScript 5.1.0 or newer, and drops support for older browsers. Check these before touching any code, because a mismatch here produces confusing errors later.

Requirement	Next.js 16 minimum
Node.js	20.9.0 (Node.js 18 is no longer supported)
TypeScript	5.1.0
Browsers	Chrome 111+, Edge 111+, Firefox 111+, Safari 16.4+

Three places tend to get missed. The first is the Node.js version in your hosting configuration, which is separate from the one on your laptop. The second is the Node.js image in your CI workflow and any Dockerfile. The third is your browser support promise: if a client contract or analytics data says you support older Safari versions, that conversation needs to happen before the upgrade, not after.

Update @types/react and @types/react-dom alongside react and react-dom. The App Router in Next.js 16 runs on the React canary channel that includes React 19.2 features such as View Transitions, useEffectEvent and Activity, and stale type packages produce misleading errors.

Run the upgrade codemod, then run the one it skips

Start on a dedicated branch and run the official upgrade codemod:

npx @next/codemod@canary upgrade latest

According to the codemod documentation, this updates next.config.js for the new top-level turbopack option, migrates next lint to the ESLint CLI, renames the middleware convention to proxy, removes the unstable_ prefix from stabilised APIs, and removes the experimental_ppr route segment config.

What it does not do is migrate synchronous request APIs. If your app still reads params, searchParams, cookies(), headers() or draftMode() synchronously, which Next.js 15 allowed with a warning during its compatibility period, run the second codemod as well:

npx @next/codemod@canary next-async-request-api .

This is the single most common reason an upgrade that "ran the codemod" still fails, so it is worth running even if you believe your code is already async.

If you work with a coding agent, the guide now recommends npx next@canary upgrade --agent=latest, which prepares the migration guides and codemod commands for the agent to apply and verify. The checklist below still applies, because an agent can also produce a green build that behaves differently.

Async request APIs: synchronous access is gone

In Next.js 16, cookies, headers, draftMode, params and searchParams can only be read asynchronously. Next.js 15 introduced the async versions with a temporary synchronous fallback, and that fallback has been removed.

The change covers params in layout, page, route and default files, in opengraph-image, twitter-image, icon and apple-icon, and searchParams in page files.

The cleanest way to get the types right is the generated helpers. Run npx next typegen and you get globally available PageProps, LayoutProps and RouteContext types that know your route parameters:

// app/blog/[slug]/page.tsx
export default async function Page(props: PageProps<'/blog/[slug]'>) {
  const { slug } = await props.params
  const query = await props.searchParams
  return <h1>Blog Post: {slug}</h1>
}

After the codemod runs, search the codebase for UnsafeUnwrapped and for comments the codemod left where it could not migrate safely. Those markers are easy to commit by accident and they are exactly the places the upgrade guide tells you to resolve. In Client Components that need a value synchronously, React's use hook is the documented route.

Metadata images and sitemaps now receive promises

The image generation functions behind opengraph-image, twitter-image, icon and apple-icon now receive params and id as promises, and so does the sitemap function when you use generateSitemaps. The generateImageMetadata and generateSitemaps functions themselves still receive synchronous values.

For Open Graph images, the fix is mechanical:

// app/shop/[slug]/opengraph-image.js
export default async function Image({ params, id }) {
  const { slug } = await params
  const imageId = await id
  // ...
}

Sitemaps deserve more care. In Next.js 15 the id passed to sitemap was the number you returned from generateSitemaps. In Next.js 16 it is a promise that resolves to a string. TypeScript will flag the missing await, but in a plain JavaScript project nothing stops id * 50000 from quietly evaluating to NaN, and nothing stops resolvedId + 1 from producing "11" instead of 2. Either one gives you a sitemap that builds, deploys and lists the wrong URLs.

// app/product/sitemap.js
export default async function sitemap({ id }) {
  const resolvedId = await id
  const start = Number(resolvedId) * 50000
  // ...
}

Convert to a number explicitly, then open the generated sitemap files in a browser and check the first and last URL in each one. Sitemaps are not something anyone looks at after launch, which is why a broken one can go unnoticed until Search Console starts reporting coverage drops.

Turbopack is the default bundler, and custom webpack config fails the build

Turbopack is now stable and used by default for both next dev and next build. If your project has a custom webpack configuration, next build will fail on purpose rather than silently ignore it.

You can remove the --turbopack and --turbo flags from your scripts. If the build fails because a webpack config was found, you have three options:

Migrate the configuration to Turbopack equivalents, which is the long-term answer.
Keep webpack for production builds with next build --webpack while you migrate.
Build with Turbopack and ignore the webpack config, but only if you are sure nothing in it matters.

If you never wrote a webpack config yourself and still see this error, a plugin added one. Bundle analysers, MDX setups, SVG loaders and some monitoring SDKs are common sources.

The experimental.turbopack block has moved to a top-level turbopack key in next.config.ts. Two smaller changes catch people out. Turbopack does not support the legacy tilde prefix in Sass imports, so @import '~bootstrap/...' becomes @import 'bootstrap/...'. And code that relied on webpack's resolve.fallback to silence errors about Node.js modules like fs in client bundles needs turbopack.resolveAlias instead, although the better fix is to stop importing server modules from client code.

middleware.ts becomes proxy.ts, unless you run on the edge

The middleware file convention is deprecated and renamed to proxy, along with the exported function name and any config flags containing the word, such as skipMiddlewareUrlNormalize, which becomes skipProxyUrlNormalize.

mv middleware.ts proxy.ts

// proxy.ts
export function proxy(request: Request) {}

The important detail is the runtime. proxy runs on Node.js, and that cannot be configured. The edge runtime is not supported in proxy. If your middleware currently runs on the edge, for geolocation, low-latency redirects or A/B routing at the network edge, the guidance is to keep using middleware for now rather than renaming it.

The upgrade codemod handles the rename. After it runs, check whether any of your middleware declared the edge runtime, and if it did, decide deliberately whether to move it to Node.js or keep the old convention. The proxy documentation is the reference to read before choosing.

next/image defaults changed in six ways

next/image has six breaking changes in Next.js 16, and most of them change behaviour without producing an error. This is the section where we spend the most testing time.

Quality values. images.qualities now defaults to [75] only. A quality={90} prop is quietly coerced to the closest allowed value, so it renders at 75. Direct requests to /_next/image with an unsupported q value return a 400. If your design depends on higher-quality hero or product images, list the values you use:

images: {
  qualities: [50, 75, 90],
}

Cache lifetime. images.minimumCacheTTL now defaults to 4 hours (14,400 seconds) instead of 60 seconds. This reduces CPU cost when upstream images lack cache headers, which is a sensible default. The side effect is that an image replaced at the same URL in a headless CMS can keep serving the old version for hours. If editors expect instant changes, either set a lower value or change the image URL on update.

Image sizes. 16 has been removed from the default images.imageSizes array, which shortens the srcset. Add it back only if you genuinely serve 16-pixel images.

Local images with query strings. A local source like /assets/photo?v=1 now requires a matching images.localPatterns entry with a search value. This prevents enumeration attacks, and it also breaks cache-busting query strings that used to work.

Local IP addresses. Optimising images from local IP addresses is now blocked by default. Hosting inside a VPC with split-horizon DNS is the usual way to hit this, and it shows up as a 400. images.dangerouslyAllowLocalIP exists for private networks, and the name tells you how carefully to use it.

Redirects. images.maximumRedirects now defaults to 3 rather than unlimited. Image CDNs that chain redirects can start failing.

Two deprecations belong on the same list. next/legacy/image is deprecated in favour of next/image, and images.domains is deprecated in favour of images.remotePatterns, which is stricter about protocol and hostname. The full option list is in the image configuration reference.

Caching APIs: revalidateTag needs a profile, and updateTag is new

revalidateTag now takes a second argument naming a cacheLife profile. The single-argument form is deprecated and produces a TypeScript error.

// Before
revalidateTag('posts')

// After
revalidateTag('posts', 'max')

The more interesting change is what the second argument forces you to decide. revalidateTag gives stale-while-revalidate behaviour: readers see the old content while fresh data loads in the background. That is right for blog posts, product catalogues and documentation.

For changes a user makes and expects to see immediately, Next.js 16 adds updateTag, which is only available in Server Actions and gives read-your-writes semantics by expiring and refreshing the data within the same request:

'use server'
import { updateTag } from 'next/cache'

export async function updateUserProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile)
  updateTag(`user-${userId}`)
}

There is also a new refresh() for refreshing the client router from inside a Server Action, which suits cases like updating a notification count after marking something as read. cacheLife and cacheTag are stable, so imports aliased from unstable_cacheLife and unstable_cacheTag can be simplified.

When you review each revalidateTag call during the upgrade, ask one question: would a user who just made this change be confused to see the old value? If yes, it should probably be updateTag.

Parallel route slots now need default.js

Every parallel route slot now requires an explicit default.js file, and builds fail without one. This one is loud, which makes it easy.

To keep the previous behaviour, add a default.js that either calls notFound() or returns null:

// app/@modal/default.tsx
export default function Default() {
  return null
}

The decision between the two matters. Returning null renders nothing in that slot on a hard navigation or reload. Calling notFound() turns the whole route into a 404. Test both a direct visit and a browser refresh on any route that uses a modal or a slot, because that is where the difference shows. The default.js reference explains when each one fires.

next lint is gone, and next build no longer lints

The next lint command has been removed, next build no longer runs linting, and the eslint option in next.config is no longer supported. If your CI relied on the build step to catch lint errors, it has stopped doing that.

The codemod migrates your scripts to the ESLint CLI:

npx @next/codemod@canary next-lint-to-eslint-cli .

Then add an explicit lint step to your pipeline before the build, so a lint failure blocks a merge the way it used to. Biome is an equally valid choice if you were already considering it.

@next/eslint-plugin-next now defaults to the ESLint flat config format, in line with ESLint 10 dropping legacy configuration. If you still use .eslintrc, the ESLint configuration reference covers the flat config setup. One practical note from the official troubleshooting section: migrating off next lint does not require upgrading ESLint itself. eslint-config-next@16 needs ESLint 9, but if an ESLint upgrade causes peer dependency conflicts, you can restore your previous lint stack and run the upgrade with --skip-eslint-upgrade.

Removed features to search your codebase for

Several features deprecated in earlier versions are now removed outright. A quick search for each one tells you whether any of these sections apply to you.

AMP. All AMP APIs are gone, including the amp config, useAmp from next/amp, and export const config = { amp: true }. If you still serve AMP pages, this is a product decision before it is a code change.

Runtime configuration. serverRuntimeConfig and publicRuntimeConfig have been removed. Server-only values come from process.env directly in Server Components. Values the browser needs use the NEXT_PUBLIC_ prefix. Note that NEXT_PUBLIC_ values are inlined at build time, so if you relied on runtime config to change a value without rebuilding, call await connection() from next/server before reading process.env, which forces the read to happen at request time.

Experimental flags. experimental.dynamicIO, experimental.useCache and the experimental Partial Prerendering flag are gone. If you were actively using them, the replacement is the top-level cacheComponents option. If you were not, delete them rather than renaming them, because enabling cacheComponents is a model change, not a rename.

Smaller removals. unstable_rootParams is replaced by next/root-params, and the appIsrStatus, buildActivity and buildActivityPosition options under devIndicators are removed, although the indicator itself remains.

Search terms worth running: next/amp, RuntimeConfig, getConfig, dynamicIO, useCache, experimental_ppr, rootParams and devIndicators.

Smaller behaviour changes that surprise people

A handful of changes do not break anything but will generate questions from your team or your clients. Knowing about them in advance saves time.

Smooth scrolling between routes. If your global CSS sets scroll-behavior: smooth on <html>, earlier versions temporarily overrode it during navigation so route changes snapped to the top. Next.js 16 no longer does this, so navigations now animate. To restore the old behaviour, add data-scroll-behavior="smooth" to the <html> element in your root layout.

Build output metrics. The size and First Load JS columns are gone from next build output because they were inaccurate with React Server Components. If someone on your team tracked bundle size from that output, switch to Lighthouse or real-user Core Web Vitals data. Our guide to passing Core Web Vitals on real phones covers how to measure what users actually experience.

Separate dev output. next dev now writes to .next/dev, so dev and build can run at the same time, and a lockfile stops two instances of the same command from running on one project. Scripts that cleaned or inspected .next directly may need a path update.

Config loaded once in development. The config file is no longer loaded twice during next dev, which means checking whether process.argv includes 'dev' inside next.config now returns false. Plugins that used that check to start side processes should check process.env.NODE_ENV === 'development' or use the config phase instead.

Prefetching. Navigation prefetching has been rebuilt with layout deduplication and incremental prefetching. You may see more individual prefetch requests in the network tab, each much smaller in total transfer size. This is expected and needs no code changes.

A testing plan that catches what the build misses

The build tells you the code compiles. This testing plan tells you the app still behaves the same way. We run it on a preview deployment of the upgrade branch, side by side with production.

Images. Open your heaviest image pages, typically the homepage, a product or portfolio page and a blog post, on both deployments. Compare visually at full size. Check the network tab for any /_next/image request returning 400.
Content freshness. Replace an image and edit a piece of content in your CMS. Confirm both update within the time your editors expect.
Sitemaps and metadata. Open every generated sitemap and check the first and last URLs. Share a page link in a social preview tool to confirm Open Graph images render.
Routes with slots or modals. Visit each one directly, then refresh the browser on it.
Proxy or middleware. Exercise every redirect, rewrite, auth gate and locale rule it handles. If you changed runtimes, measure latency from more than one region.
Forms and Server Actions. Submit every form that changes data and confirm the user sees their change immediately where they should.
Navigation feel. Click through the main routes and confirm scroll behaviour matches what you intend.
CI. Push a commit with a deliberate lint error and confirm the pipeline fails.
Real-user metrics. After release, watch Core Web Vitals and server CPU for a few days. The image cache change usually lowers CPU, and a sudden rise is worth investigating.

If you'd rather work from paper, the printable upgrade worksheet has this test plan as tick boxes with a pass condition for each one.

The upgrade guide closes with its own migration checklist, and it is worth reading line by line before you merge. One line in particular is worth repeating to anyone in a hurry: do not enable React Compiler or Cache Components just to complete the upgrade.

Should you turn on React Compiler or Cache Components during the upgrade?

No. Both are worth evaluating, and neither belongs in the same pull request as a major version upgrade.

React Compiler support is stable in Next.js 16 through the top-level reactCompiler option, following React Compiler 1.0. It is not enabled by default, it requires babel-plugin-react-compiler, and the documentation notes that it increases compile times because it relies on Babel. It is a reasonable experiment once the upgrade has settled, measured against real render performance.

Cache Components, enabled through cacheComponents: true, is how Partial Prerendering works in Next.js 16. It can surface build errors for uncached data accessed outside a <Suspense> boundary and asks you to adopt a different caching model. The Cache Components migration guide is the place to start when you are ready.

Keeping these separate is basic change management. If something regresses after release, you want one change to suspect, not three. For teams building larger products, our post on multi-tenant SaaS architecture covers the same principle at the system level: isolate changes so failures stay small and traceable.

Next.js 16 Upgrade Worksheet

All 24 checks from this guide on two printable pages, each with a pass condition, plus a readiness score that tells you when it's safe to merge. No account, no sales sequence.

Get the PDF

Frequently asked questions

Will my Next.js 15 site stop working after October 21, 2026?

No. Your site keeps running exactly as it does today. What ends is support: Next.js 15 stops receiving the critical bug fixes and security updates it gets during Maintenance LTS. The risk is that the next security issue in the framework will be patched in Next.js 16, leaving you to upgrade under time pressure.

Can I upgrade from Next.js 14 directly to Next.js 16?

Yes, but you take on two sets of breaking changes at once. Read the Next.js 15 upgrade guide as well, because the async request API change started there, and run both the upgrade codemod and the next-async-request-api codemod. Next.js 14 has been unsupported since 26 October 2025, so this upgrade is overdue rather than optional.

Do I have to switch to Turbopack?

No. Turbopack is the default, but you can keep webpack for builds with next build --webpack. If your project has a custom webpack configuration, you must choose explicitly, because the build fails rather than ignoring it. Migrating to Turbopack is the recommended long-term path.

Does the upgrade codemod handle everything?

No. It handles the Turbopack config move, the next lint migration, the middleware to proxy rename, unstable_ prefixes and the experimental_ppr segment config. It does not migrate synchronous request APIs, which need the separate next-async-request-api codemod, and it cannot test the behaviour changes in images, caching, scrolling and CI linting.

Is the minimum Node.js version for Next.js 16 really 20.9?

Yes. Next.js 16 requires Node.js 20.9.0 or newer and no longer supports Node.js 18. Check the version in your hosting platform settings, CI configuration and Docker images, not just on your development machine.

The short version

Next.js 15 support ends on 21 October 2026. Run both codemods, fix what the build reports, then spend real time on the changes it cannot report: image quality and caching, sitemap IDs, CI linting, scroll behaviour and any edge middleware. Keep React Compiler and Cache Components for a later, separate change.

If you are planning the rest of your stack for the coming year, our roundup of what actually changed in web development in 2026 puts this release in context. The full detail for everything above lives in the official Next.js 16 upgrade guide, which is worth keeping open in a tab while you work.

Originally published on zignites.com.

How to Tell If a WordPress Plugin Is Abandoned (One Field Won't Tell You)

Muhammad Zeeshan Sardar — Fri, 02 Oct 2026 13:00:00 +0000

TL;DR: The last release date is the strongest signal. "Tested up to" goes stale on its own. A closed listing means opposite things depending on the reason field. Support-thread ratios are noisy. Premium plugins sit outside the directory entirely. There is a script at the end that checks a list of plugins in one run.

Ask the WordPress.org plugin API about Display Widgets and you get this:

{
  "error": "closed",
  "description": "This plugin has been closed as of January 30, 2021 and is not available for download. This closure is permanent. Reason: Security Issue."
}

Ask it about Paid Memberships Pro and you get this:

{
  "error": "closed",
  "description": "This plugin has been closed as of October 17, 2024 and is not available for download. This closure is permanent. Reason: Author Request."
}

Same error, same wording, same word "permanent". But these are opposite situations. Display Widgets was pulled over a security issue. Paid Memberships Pro left the directory by its own authors' choice and kept shipping releases from its own site. It was still releasing updates in September 2026.

Any check that stops at "is it listed?" treats those two plugins the same way. So does any check that stops at "when was it last updated?", for different reasons.

There is no official definition of an abandoned plugin, and no single field that tells you. What you do have is a handful of facts the directory publishes, each of which means something narrower than it looks. Read them together and you get a reliable picture. This post goes through each one, then gives you a short script that checks a list of plugins in one run.

Get the facts yourself first

Everything below comes from one public endpoint. No key, no signup:

curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=akismet&request[fields][sections]=0"

The fields that matter for maintenance:

Field	What it holds
`version`	The current release
`last_updated`	When a release last shipped, e.g. `2026-08-18 11:42pm GMT`
`tested`	The newest WordPress version the author says they tested against
`requires_php`	The minimum PHP version the plugin declares
`active_installs`	A rounded floor, not an exact count
`support_threads` / `support_threads_resolved`	Forum threads in the recent window, and how many are marked resolved

For a closed plugin you get closed: true, a closed_date, and a reason such as security-issue or author-request, instead of the fields above.

Signal 1: the last release date (the strongest one)

A release is the only thing in the list that proves someone recently did work on the plugin. A reasonable way to read it:

Under 6 months: actively maintained by any sensible standard.
6 to 11 months: worth a look, especially for anything large.
12 to 23 months: ageing. Find out what you would replace it with.
24 months or more: treat it as unmaintained until you learn otherwise.

The nuance is plugin size. A small plugin that does one narrow thing may genuinely need no changes for two years, and WordPress is careful about backwards compatibility. A page builder, a checkout extension or a membership system that has not shipped in two years is a different story, because those plugins touch everything that changes around them.

The date is not the risk on its own. The risk is what happens when PHP or WordPress next ships a breaking change and nobody is there to fix the plugin. You want to know about that before your host upgrades PHP, not after.

Signal 2: "tested up to" (stale by design)

The tested field is the author telling you the newest WordPress version they checked the plugin against. It goes stale on its own. WordPress ships two or three major releases a year, so a plugin that nobody touches falls behind whether or not anything in it is broken.

WordPress.org shows a warning on a plugin's page once it has not been tested with the latest three major releases, which is a sensible line.

Read it alongside the release date:

Recent release, old "tested up to": usually the author forgot to bump the header. Low concern, but test it on staging before a major WordPress upgrade.
Old release, old "tested up to": both fields are telling you the same thing, and it is the release date that matters.

Do not add the two together as if they were separate problems. When the last release is over a year old, the "tested up to" gap is a symptom of the same fact.

Signal 3: closed does not mean one thing

This is the case from the top of the post. The reason field is what separates them:

security-issue (and the other reasons set by the plugin review team): the directory pulled the plugin. Take this seriously, find out why, and plan to replace it.
author-request: the author asked for the listing to be removed. That can mean they gave up. It can also mean they moved distribution to their own site, which is exactly what happened with Paid Memberships Pro.

For author-request closures, the next step is to check the author's own site or repository for recent releases. If they are still shipping, the plugin is maintained. It simply is not in the directory any more.

Signal 4: support threads (noisy, use with care)

It is tempting to read support_threads_resolved / support_threads as a responsiveness score. Be careful.

A thread only counts as resolved when someone marks it resolved. Plenty of active authors answer every thread and never tick the box, and plenty of users never come back to close their own threads. The ratio also needs a reasonable sample. Five threads with two resolved tells you almost nothing.

Use it as a prompt to open the forum and read the last page of threads yourself. If recent questions have replies from the author, the plugin is supported, whatever the ratio says.

Signal 5: premium plugins sit outside all of this

Commercial plugins sold from the developer's own site are not in the directory, so none of the fields above exist for them. That is completely normal, and it carries its own risk.

Premium plugins usually only get updates while the licence is active. When a renewal lapses, the plugin keeps running and quietly stops receiving fixes, and nothing on the site tells you. No outside check can see that.

For premium plugins, the questions are not technical. Which licences are still active, and who is responsible for renewing them?

Putting it together

What you see	How to read it
Recent release, current "tested up to"	Maintained
Recent release, old "tested up to"	Maintained, test before major upgrades
No release for 12+ months	Ageing, know your replacement
No release for 24+ months, large plugin	Treat as unmaintained
Closed, `security-issue`	Replace it
Closed, `author-request`	Check the author's own site before deciding
Not in the directory	Premium or custom, check the licence

A script to check a list of plugins

Save this as check-plugins.mjs and run it with Node 18 or later: node check-plugins.mjs akismet contact-form-7 display-widgets.

const API = 'https://api.wordpress.org/plugins/info/1.2/';

function monthsSince(lastUpdated) {
  const date = new Date(lastUpdated.replace(/(\d)(am|pm)/i, '$1 $2'));
  if (Number.isNaN(date.getTime())) return null;
  return Math.floor((Date.now() - date.getTime()) / (1000 * 60 * 60 * 24 * 30.44));
}

async function check(slug) {
  const url = `${API}?action=plugin_information&request[slug]=${encodeURIComponent(slug)}&request[fields][sections]=0`;
  const res = await fetch(url);
  const data = await res.json();

  if (data.closed) {
    return `${slug}: closed on ${data.closed_date} (${data.reason})`;
  }
  if (data.error) {
    return `${slug}: not in the directory (premium, custom, or a typo)`;
  }

  const months = monthsSince(data.last_updated);
  const age = months === null ? 'unknown' : `${months} month${months === 1 ? '' : 's'} ago`;
  return `${slug}: v${data.version}, last release ${age}, tested up to ${data.tested}`;
}

for (const slug of process.argv.slice(2)) {
  console.log(await check(slug));
}

Two details in there are worth knowing. last_updated comes back in a format like 2026-08-18 11:42pm GMT, which JavaScript's date parser does not reliably accept until the space before pm is added. And a slug that has never existed also returns an error without closed, so "not in the directory" covers typos as well as premium plugins.

Doing this for a whole site

The script works when you already know the slugs. On a client's site you often do not, especially before you have a login.

That is the gap I built a free WordPress plugin checker to fill. You paste a URL, and it detects the plugins the site loads publicly and reads the same directory fields covered above for each one. It separates plugin-team closures from author requests, marks which installed versions are inferred, and says plainly what it could not see. It does not make vulnerability claims, because that data sits behind commercial APIs and guessing at it does more harm than good.

If you want the signals for one plugin at a time, there is also a plugin maintenance check covering widely installed plugins, with the date each one was read from the directory.

And if you are on the other side of this and maintain a plugin yourself, this guide to WordPress plugin development covers what keeping one healthy in the directory actually involves.

The standard I would suggest for any site you are responsible for is simple. For every plugin that has gone a year without a release, know what you would replace it with before you need to. The day you need that answer is usually the day a host upgrades PHP.

The Obvious Way to Detect WordPress Plugins Counts WooCommerce Six Times

Muhammad Zeeshan Sardar — Wed, 30 Sep 2026 13:00:00 +0000

TL;DR: Asset paths, script handles and REST namespaces all reveal WordPress plugins from outside, and each one produces false positives if you trust it on its own. Deny core handles, map handle families to their parent plugin, require corroboration, and never trust a ?ver= that matches the core version.

Point a naive plugin detector at a WooCommerce store and it will tell you the site runs wc, wc-admin, wc-analytics, wc-telemetry, wccom-site and wc-admin-email. Six plugins. It is one plugin, WooCommerce, and the real woocommerce slug may not appear in the list at all.

The same detector will report wp-block-editor and wp-site-health as plugins. Both are WordPress core.

I build WordPress plugins, and I recently built a free scanner that reads a public site and lists the plugins it runs, with the maintenance facts WordPress.org publishes about each one. The use case is quoting: before a client hands over a login, you want to know whether you are walking into twelve current plugins or four that have not shipped a release since 2022.

Getting that list right turned out to be the whole job. Detection from outside is mostly an exercise in not believing your own evidence too quickly. Here are the three signals that work, the trap in each one, and the rules that keep the list honest.

Signal 1: asset paths (the one to trust most)

Plugins live in /wp-content/plugins/<slug>/, and when a plugin loads a stylesheet, script or image on a page, that path shows up in the HTML.

const PLUGIN_PATH = /\/wp-content\/plugins\/([a-z0-9-]+)\//gi;

function slugsFromPaths(html: string): Set<string> {
  const slugs = new Set<string>();
  for (const match of html.matchAll(PLUGIN_PATH)) {
    slugs.add(match[1].toLowerCase());
  }
  return slugs;
}

When a slug appears in an asset path, the plugin is installed and active on that page. That is about as strong as outside evidence gets, and the directory name matches the WordPress.org slug for anything installed from the directory.

The trap: absence proves nothing. Three things hide plugins from this signal:

Optimisation and caching plugins that combine every stylesheet and script into one bundle served from their own cache folder. The individual plugin paths disappear from the HTML.
Plugins with no front-end assets. Anything that works entirely in wp-admin or on the server leaves no trace in the page.
Security plugins that rewrite or hide plugin paths on purpose.

So a short list from this signal is evidence of what is visible, not evidence of a small install. That distinction has to reach the person reading the report, or they will draw the wrong conclusion.

Signal 2: script and style handles (useful, and full of traps)

When WordPress prints an enqueued script or stylesheet, it adds an ID built from the handle the code registered:

<link rel="stylesheet" id="contact-form-7-css" href="...">
<script id="wc-add-to-cart-js" src="..."></script>

Strip the -js or -css suffix and you have the handle. This signal matters because it survives some of the situations that hide asset paths, including assets served from a CDN under a different URL structure.

const HANDLE_ID = /<(?:script|link)\b[^>]*\bid=["']([a-z0-9_-]+)-(js|css)["']/gi;

function handlesFromIds(html: string): Set<string> {
  const handles = new Set<string>();
  for (const match of html.matchAll(HANDLE_ID)) {
    handles.add(match[1].toLowerCase());
  }
  return handles;
}

The regex requires the closing quote straight after -js, which quietly skips inline companions such as wc-add-to-cart-js-extra and -js-after. Those belong to a handle you have already counted.

This is where the six WooCommerce rows come from. A handle is not a slug. It is whatever string the developer chose, and three kinds of handle break the naive approach. (Core packages also start with wp-, so a blanket "anything beginning with wp-" rule would throw away real plugins such as wp-mail-smtp. The deny list has to be explicit.)

Core handles. WordPress registers dozens of its own scripts: wp-block-editor, wp-polyfill, jquery-core, wp-emoji-release, wp-block-library, global-styles, classic-theme-styles and more. None of them is a plugin. You need an explicit deny list, and it needs a comment saying where it came from, because it will need extending every few releases.

Handle families. One plugin often registers many handles under a shared prefix. WooCommerce uses wc-* and wccom-*. Yoast uses yoast-* and wpseo-*, and its directory slug is wordpress-seo, which no handle contains. You need a maintained map from prefix to parent slug, and you emit one row for the parent.

Theme handles. Themes enqueue assets too. A theme stylesheet with the ID acme-siteheader-css produces the handle acme-siteheader, which looks exactly like a plugin that does not exist.

The rule that fixes all three is corroboration. A slug derived only from a handle is accepted when it resolves in the WordPress.org directory, or when the same slug also appears as a real asset path on the site. Anything else is dropped silently.

// Core script and style handles. Extend this as WordPress adds packages.
const CORE_HANDLES = new Set([
  'jquery', 'jquery-core', 'jquery-migrate', 'wp-polyfill', 'wp-emoji-release',
  'wp-block-library', 'wp-block-editor', 'wp-site-health', 'global-styles',
  'classic-theme-styles', 'admin-bar', 'regenerator-runtime', 'lodash', 'moment',
]);

// Prefix to parent slug. Order matters: more specific prefixes first.
const HANDLE_FAMILIES: Array<[string, string]> = [
  ['wccom-', 'woocommerce'],
  ['wc-', 'woocommerce'],
  ['wpseo-', 'wordpress-seo'],
  ['yoast-', 'wordpress-seo'],
  ['elementor-', 'elementor'],
];

function familyParent(handle: string): string | null {
  if (handle === 'wc') return 'woocommerce';
  const match = HANDLE_FAMILIES.find(([prefix]) => handle.startsWith(prefix));
  return match ? match[1] : null;
}

function acceptHandle(
  handle: string,
  pathSlugs: Set<string>,
  directorySlugs: Set<string>,
): string | null {
  if (CORE_HANDLES.has(handle)) return null;

  const parent = familyParent(handle) ?? handle;
  if (pathSlugs.has(parent) || directorySlugs.has(parent)) return parent;

  return null;
}

Dropping silently is the important part. The tempting alternative is to show unmatched handles as "not in directory". That turns a theme stylesheet into a finding, and a WordPress developer will spot it in the first ten seconds and stop trusting everything else on the page.

Signal 3: REST API namespaces

Most WordPress sites expose an index at /wp-json/, and its namespaces array lists the route prefixes every active plugin has registered:

{
  "namespaces": ["oembed/1.0", "wc/v3", "yoast/v1", "contact-form-7/v1", "wp/v2"]
}

This catches plugins that load nothing on the front end but still register routes, which fills part of the gap Signal 1 leaves.

The trap: namespaces are not slugs either. wp/v2 and oembed/1.0 are core. yoast/v1 belongs to wordpress-seo. wc/v3 belongs to woocommerce. The same family map from Signal 2 does most of the work here, and the same corroboration rule applies.

It is also the weakest of the three signals. A namespace proves the plugin registered routes. It does not prove the plugin does anything visible, and some sites disable or restrict the REST index. When you report a plugin, record which signal found it (path, handle, namespace, or several), so you can tell later how much weight each row deserves.

Getting the installed version

Knowing a plugin is installed is half of it. Knowing the site runs 4.2 while the current release is 6.1 is the part that matters for a quote.

The best source is the plugin's own readme.txt, fetched from /wp-content/plugins/<slug>/readme.txt, which carries a Stable tag line. Many sites block direct requests to plugin folders, and larger ones block them almost always.

The fallback is the ver query string on asset URLs:

function versionFromAsset(
  src: string,
  pageUrl: string,
  coreVersion: string | null,
): string | null {
  const ver = new URL(src, pageUrl).searchParams.get('ver');
  if (!ver) return null;
  if (coreVersion && ver === coreVersion) return null;
  return ver;
}

The core version check exists because of how wp_register_script behaves. When a plugin registers an asset without passing its own version, WordPress appends the core version instead. Read that at face value and you will report that a plugin is on version 6.8, when 6.8 is simply the WordPress version.

Two more rules make this usable:

Label it. A version from a readme is confirmed. A version from ?ver= is inferred, because it is a cache-busting parameter and a site can put anything in it. The report should say which is which.
Find the core version from core assets, such as the ver on files under /wp-includes/. The generator meta tag is often removed, so it cannot be the only source.

What the directory can tell you, and what it cannot

Once you have a clean list of slugs, the WordPress.org plugin API gives you the maintenance facts for each one: when it last shipped a release, which WordPress version its author last tested against, and whether the directory still lists it.

What it does not give you is vulnerability data. I made a deliberate decision not to guess at it. Good vulnerability data for WordPress plugins sits behind commercial APIs, and a free tool that fakes it has two options. It can guess from version numbers, which flags plugins that are fine. Or it can flag a few famous cases and stay quiet on the rest, which implies everything unflagged has been checked. Both are worse than saying clearly that no security check was run.

The same principle applies to the score. If a site loads 11 plugins and 8 of them are premium plugins sold outside the directory, there is no public release history to judge those 8 on. A score built on the remaining 3 should say so, rather than printing "Healthy" next to it.

The standard I hold a scanner to

Fewer, truer findings beat a longer list. Every rule above removes rows rather than adding them: the deny list, the family map, the corroboration check and the core version check. Each one exists because a plausible-looking false positive costs more trust than a missing row.

If you want to see the result on a real site, the scanner is free and needs no signup: WordPress Plugin Checker. It marks which installed versions are inferred rather than confirmed, and states plainly what it could not see. If you only care about one plugin, the plugin maintenance check covers widely installed plugins one at a time.

If you build plugins yourself, I wrote about what maintaining one actually involves, including why "tested up to" goes stale on its own.

I would like to hear from anyone who has built detection like this. Which handle families or namespaces have caught you out? The family map only gets better with more eyes on it.

Export Installed WordPress Plugins & Themes to CSV (Developer-Friendly Method)

Muhammad Zeeshan Sardar — Mon, 09 Mar 2026 23:08:21 +0000

If you manage WordPress websites, you've probably encountered this problem.

You open a project and need to quickly answer questions like:

What plugins are installed on this site?
Which theme is active?
How can I export this list for documentation or auditing?

Surprisingly, WordPress does not provide a built-in way to export installed plugins and themes.

For developers and agencies managing multiple projects, this can become frustrating.

So I built a small tool to solve this problem.

In this article, I’ll show you how to export installed WordPress plugins and themes in seconds.

If you just want the quick solution:

Install Site Extensions Snapshot
Go to Tools → Site Extensions Snapshot
Click Export to CSV You will instantly download a list of all installed plugins and themes.

Plugin link:
https://wordpress.org/plugins/site-extensions-snapshot/

Why Developers Need a Plugin Snapshot

In real-world development, having a snapshot of installed extensions is extremely useful.

Here are a few common scenarios.

Client Documentation
When handing over a project, you may need to document all plugins and themes used in the website.

Website Audits
Security or performance audits often require reviewing installed plugins.

Troubleshooting
Plugin conflicts are common in WordPress. Having a full list helps identify potential issues faster.

Migration Preparation
Before migrating a website, it's helpful to know exactly which extensions are installed.

The Problem with WordPress

WordPress lets you view plugins inside the dashboard, but it doesn't allow you to:

Export the plugin list
Download the plugin inventory
Share it with a team

Most developers end up:

Manually copying plugin names
Taking screenshots
Writing custom scripts

This wastes time.

The Solution: Site Extensions Snapshot

To make this easier, I built a small WordPress plugin called:

Site Extensions Snapshot

It allows developers to export installed plugins and themes into a CSV file with one click.

Plugin page:
https://wordpress.org/plugins/site-extensions-snapshot/

What the Plugin Does

Once installed, the plugin allows you to:

✔ Export installed plugins to CSV
✔ Export installed themes to CSV
✔ Create a quick snapshot of the site environment
✔ Use the exported list for documentation or audits

It's a lightweight utility tool designed to save developers time.

How to Use the Plugin

Step 1 — Install the Plugin

Go to your WordPress dashboard:
Plugins → Add New
Search for:
Site Extensions Snapshot
Install and activate it.

Step 2 — Export Installed Plugins & Themes
After activating the plugin:

Go to Tools
Click Site Extensions Snapshot
Click Export to CSV That's it.

The plugin will download a CSV file containing all installed plugins and themes.
You can now use this file for:

Documentation
Website audits
Migration planning
Team collaboration

Who This Plugin Is For

This tool is useful for:

WordPress developers
Freelancers
Agencies
Website auditors
DevOps teams managing WordPress environments

If you work with multiple WordPress projects, this tool can simplify documentation and save time.

Why I Built This Plugin

While working on WordPress projects, I often needed a quick list of installed plugins and themes for documentation or troubleshooting.

Since there wasn't an easy way to export that information, I decided to build a small tool that solves this problem.

Try It Out

If you'd like to try the plugin, you can install it from the WordPress plugin directory.

https://wordpress.org/plugins/site-extensions-snapshot/

If you try it, I’d love to hear feedback or suggestions from the developer community.

Sometimes the simplest tools solve real developer problems.

If you regularly manage WordPress websites, having a quick way to export installed plugins and themes can make documentation and audits much easier.