DEV Community: Muhammad Zeeshan Sardar

React 19.3 View Transitions: The Suspense Patterns That Keep an App Fast

Muhammad Zeeshan Sardar — Thu, 12 Nov 2026 14:00:00 +0000

TL;DR

React 19.3 (9 September 2026) made <ViewTransition> stable, and Next.js 16.4 ships it. In the App Router every navigation is a Transition, so boundaries animate with no extra code.
An unconfigured boundary animates on every trigger. Start from default="none" and opt into the triggers you want.
Follow the Suspense rule: fallbacks appear instantly, the reveal animates, cached content never animates. update="auto" default="none" around <Suspense> does all three.
A DOM node above a boundary, a boundary in a layout, or a shared pair without share all disable animations silently.
Reduced motion and clicks during animations are your responsibility, not React's.

Most of the View Transition bugs that ship in React apps over the next year will come from animating too much, not too little. React 19.3 made <ViewTransition> stable, Next.js 16.4 bundles it, and the default behaviour is generous: an unconfigured boundary cross-fades on every Transition that touches it. That is pleasant in a demo and tiring in a product. The teams that get this right will treat animation as something each boundary opts into, starting from default="none", and will follow one rule for loading states that the React team spelled out in the 19.3 announcement.

This guide takes that position and builds on it. It covers what became stable and when, which updates can trigger an animation at all, the Suspense rule, shared elements and directional navigation in Next.js, the placement mistakes that switch animations off without an error, and the accessibility and browser-support work that remains your responsibility. It ends with the checks we run on a codebase before View Transitions go to production.

Every API detail below was checked on 9 November 2026 against the React 19.3 release post and reference docs, the Next.js 16.4 release post and view transitions guide, the documentation bundled inside the next@16.4.5 package, and the npm registry. Where two official sources disagree, the section says so.

What React 19.3 made stable, and which versions you need

React 19.3.0 was published to npm on 9 September 2026, and the React 19.3 announcement moved two APIs out of the experimental channel: <ViewTransition> and Fragment refs. Both had been previewed as experimental the year before. The current patch at the time of writing is 19.3.1, published on 14 October 2026, and it is what the latest tag on npm resolves to.

The release also added addTransitionType support for typed animations, a browser() API in react-dom for opting components out of server rendering, Trusted Types support, and the ability for Server Components to render a Context directly. Nothing in the release is listed as a breaking change, which is consistent with it shipping as a minor version rather than React 20.

For Next.js projects, the version that matters is 16.4. The Next.js 16.4 release post, published on 6 October 2026, states that it ships with React 19.3, including stable View Transitions and Fragment refs. If you are upgrading for this reason, go straight to the current patch rather than 16.4.0. On 3 November the team published a security release as 16.4.5 and 15.5.29, fixing one high and several medium severity issues, most of them in Cache Components. If your project is still on Next.js 15, our Next.js 16 upgrade checklist covers the breaking changes to handle first.

Package	Version checked	Published	Why it matters
`react`, `react-dom`	19.3.1	14 October 2026	Stable `<ViewTransition>`, Fragment refs, `addTransitionType`
`next`	16.4.5	3 November 2026	Ships React 19.3, `transitionTypes` on `<Link>`, security fixes

Keep react and react-dom on the same version. A mismatch is one of the quicker ways to lose an afternoon, because npm refuses the install and forcing it produces runtime errors that look unrelated to the upgrade.

Which updates can trigger a View Transition

A View Transition only runs when an update is marked as non-urgent. The <ViewTransition> reference names three sources: state updates inside startTransition, a <Suspense> boundary revealing its content, and an update coming from useDeferredValue. A plain setState in an event handler never animates, however the boundary is configured.

That design is deliberate, and it is worth understanding before writing any CSS. Urgent updates, such as typing into an input or toggling a checkbox, should appear immediately, and React will not put an animation between the user and the result. Non-urgent updates are the ones where React is already willing to wait, so adding a short animation does not change how responsive the interface feels.

import { ViewTransition, useState, startTransition } from 'react';

function Panel() {
  const [open, setOpen] = useState(false);

  return (
    <>
      <button onClick={() => startTransition(() => setOpen(o => !o))}>
        Toggle details
      </button>

      {open && (
        <ViewTransition>
          <Details />
        </ViewTransition>
      )}
    </>
  );
}

Remove startTransition from that click handler and the panel still opens, but without animation. When someone reports that "the animation only works sometimes", this is the first thing to check: one code path wraps the update in a Transition and another does not.

In the Next.js App Router, route navigations are already Transitions, so <ViewTransition> boundaries animate during navigation without any extra code. The Next.js view transitions guide makes this point directly, and it is the reason a single unconfigured boundary in a shared component can start animating on every page change.

You also never call document.startViewTransition() yourself. React calls it for you, and calling it alongside React's own handling produces competing transitions.

The four triggers: enter, exit, update and share

React picks an animation based on how the tree changed around each boundary. There are four triggers, and each one can be configured separately:

enter runs when the <ViewTransition> is inserted during a Transition.
exit runs when it is removed.
update runs when DOM inside it changes, or when its size or position changes because of an immediate sibling.
share runs when a named boundary is removed in one place and a boundary with the same name is inserted somewhere else.

Each trigger prop accepts "auto" (the browser's default cross-fade), "none", a class name of your own, or an object keyed by transition type. A class name is the usual choice, because it connects the boundary to CSS through the view transition pseudo-elements:

<ViewTransition enter="slide-up" exit="fade-out">
  <Notice />
</ViewTransition>

::view-transition-new(.slide-up) {
  animation: 220ms ease-out both slide-up;
}

::view-transition-old(.fade-out) {
  animation: 150ms ease-in both fade-out;
}

@keyframes slide-up {
  from { opacity: 0; transform: translateY(8px); }
  to   { opacity: 1; transform: translateY(0); }
}

@keyframes fade-out {
  to { opacity: 0; }
}

The React docs recommend styling through these classes rather than targeting view-transition-name values directly. Classes survive refactors and work with React's generated names; hard-coded names do not.

There is also an imperative route. The event props onEnter, onExit, onUpdate and onShare receive the transition instance and the active types, so you can drive the animation with the Web Animations API and return a cleanup function. Only one event fires per boundary per Transition, and onShare wins over onEnter and onExit. Most interfaces never need this, and CSS keeps the animation where designers can find it.

One more detail matters for layouts: React treats each boundary's content as a single image that moves, scales and cross-fades. Child elements inside it do not animate their own positions. If a card's title and image should move independently, they need separate boundaries.

Why default="none" should be your starting point

default="none" turns off every trigger on a boundary except the ones you list explicitly. It is the single most useful prop on <ViewTransition>, and starting from it is the opt-in model this guide argues for.

The problem it solves is not obvious until an app has more than a few boundaries. An unconfigured boundary uses "auto" for every trigger, so it cross-fades whenever any Transition updates it. In the App Router that means every navigation, every router.refresh(), and every Suspense reveal nearby. The Next.js guide puts it plainly: without default="none", every named <ViewTransition> animates whenever any transition runs on the page. Individually, each cross-fade is subtle. Together, they make an interface feel slow even when the data arrives quickly, because the user watches content dissolve rather than appear.

<ViewTransition default="none" enter="slide-up">
  <SearchResults query={query} />
</ViewTransition>

That boundary animates when the results first enter and stays still for everything else. If you later decide that updates should cross-fade too, you add update="auto", and the change is visible in code review instead of being an accident of defaults.

There is one trap. A named pair used for a shared element transition needs an explicit share prop once you add default="none". The Next.js guide warns that with default="none" and no share, the pair silently stops morphing. Nothing errors, and the morph simply disappears.

<ViewTransition name={`product-${id}`} share="morph" default="none">
  <ProductImage id={id} />
</ViewTransition>

As a working rule, we treat any <ViewTransition> without default="none" as something a reviewer should question. Sometimes the generous default is right, for a small, self-contained widget that only ever changes through one Transition. Usually it is a boundary that nobody has fully thought through yet.

The Suspense rule: instant fallbacks, animated reveals

The React 19.3 announcement gives three principles for animating around Suspense, and they are the core of this guide:

Fallbacks should appear immediately, without animation.
A fallback should change to its final content with animation.
Children that do not suspend should appear immediately, without animation.

Each principle protects responsiveness in a different way. An instant fallback tells the user that their click registered; fading it in delays that acknowledgement for no benefit. An animated reveal smooths the jump from skeleton to content, which is the moment where a hard cut feels most jarring. And content that is already cached should never animate, because an animation on data the user has seen before turns an instant response into a slow one.

The default configuration breaks the first and third principles. Wrap a Suspense boundary in a plain <ViewTransition> and the fallback fades in, then content that was already loaded animates again every time the component is shown. The announcement's fix is to switch off everything except updates:

<ViewTransition update="auto" default="none">
  <Suspense fallback={<OrderSummarySkeleton />}>
    <OrderSummary orderId={orderId} />
  </Suspense>
</ViewTransition>

Now the skeleton appears at once, the change from skeleton to summary cross-fades, and once the summary is cached, toggling it is instant. This is a small change with a large effect on how an app feels, and it is the pattern we would put in a team's shared components before anything more decorative.

Suspense boundaries also wait for more than data. Inside a <ViewTransition>, React waits up to 500 milliseconds for fonts and visible images to load before running the animation, and the 19.3 post shows how wrapping images and stylesheets inside a boundary lets them take part in Suspense. That turns the familiar flicker of an image arriving late into a coordinated reveal, as long as the image loads within that window.

Choosing between the update and enter/exit patterns for Suspense

There are two ways to animate a Suspense reveal, and they communicate different things.

The update pattern wraps the whole Suspense boundary in one <ViewTransition>. The fallback and the content share one identity, so React cross-fades from one to the other in place. It suits content that occupies the same space as its skeleton, such as a card, a table or a summary panel.

The enter and exit pattern puts one boundary around the fallback and another around the content. The fallback exits and the content enters, each with its own animation:

<Suspense
  fallback={
    <ViewTransition exit="slide-down" default="none">
      <ArticleSkeleton />
    </ViewTransition>
  }
>
  <ViewTransition enter="slide-up" default="none">
    <Article slug={slug} />
  </ViewTransition>
</Suspense>

This is the pattern the Next.js guide uses for a detail page, with deliberately uneven timing: the skeleton leaves in about 150 milliseconds, and the content's fade waits for that exit to finish before arriving over roughly 210 milliseconds, while its slide runs for 400. The reasoning is sound. Old content should leave quickly so that it does not compete for attention, and new content should arrive gently enough for the eye to register it.

Situation	Pattern	Why
Skeleton and content occupy the same box	Update, one boundary around `<Suspense>`	Reads as the same thing becoming ready
Content is a different shape from its skeleton	Enter and exit, one boundary each	Avoids stretching one image into another
Content is usually cached	Either, with `default="none"`	Cached reveals should not animate
Many small boundaries on one screen	Update, or none at all	Several entrances at once looks busy

If you are unsure, start with the update pattern and default="none". It is the quieter of the two and the harder one to get wrong.

Shared element morphs and the prefetch condition

A shared element transition makes one element appear to move between two states: a product thumbnail growing into the hero image on its detail page, for example. You create one by giving two boundaries the same name, one in the old tree and one in the new:

// In the grid
<Link href={`/products/${p.id}`}>
  <ViewTransition name={`product-${p.id}`} share="morph" default="none">
    <Image src={p.thumb} alt={p.title} width={320} height={320} />
  </ViewTransition>
</Link>

// On the detail page
<ViewTransition name={`product-${p.id}`} share="morph" default="none">
  <Image src={p.hero} alt={p.title} width={960} height={960} />
</ViewTransition>

Three conditions decide whether the morph actually plays, and each one fails silently.

Names must be unique across the whole app at any moment. Only one boundary with a given name can be mounted at a time. A list where every item uses the same name raises an error about two components sharing a name, which is the easy case. The harder case is a name that collides only when two specific components happen to be mounted together. Build names from a stable identifier, and keep any fixed names in a module of namespaced constants.

Both sides must be in the viewport. If either element is off screen, React does not form a pair, and each side runs an ordinary enter or exit animation instead.

The destination must render in the same commit. This is the condition that catches Next.js teams. The guide explains that the morph plays when the destination content renders in the same commit as the navigation, which is the case for prefetched pages. If the destination suspends into a fallback first, there is no pair, and the content uses its enter animation when it arrives. In practice, a shared element morph is only as reliable as your prefetching. If the detail page fetches uncached data before it can render the hero image, the morph will rarely play, and the fix belongs in your data and caching strategy, not in CSS.

The Next.js guide also adds a short blur to the image pair during the morph. It is a useful trick, because it hides the scaling artefacts that appear when a small image is stretched to a larger size mid-flight.

Directional navigation with transition types in Next.js 16.4

Transition types let one boundary choose different animations depending on why a Transition happened. In plain React you add a type inside the Transition with addTransitionType, for example addTransitionType('next'). In Next.js, <Link> accepts a transitionTypes prop, and the bundled documentation for 16.4.5 records it as added in version 16.2.0. useRouter supports the same option on push() and replace().

<Link href={`/orders/${order.id}`} transitionTypes={['nav-forward']}>
  View order
</Link>

<Link href="/orders" transitionTypes={['nav-back']}>
  Back to orders
</Link>

Each page then maps those types to animations, with everything else switched off:

<ViewTransition
  enter={{ 'nav-forward': 'nav-forward', 'nav-back': 'nav-back', default: 'none' }}
  exit={{ 'nav-forward': 'nav-forward', 'nav-back': 'nav-back', default: 'none' }}
  default="none"
>
  <OrdersTable />
</ViewTransition>

Two details from the Next.js guide decide whether this works. First, put the wrapper in each page.tsx, not in a layout. Layouts persist across navigations, so their boundaries never enter or exit and the directional animation never fires. Second, decide which links count as forward and which as back based on your navigation hierarchy, because Next.js does not infer it. The guide's convention, with forward content sliding in from the right and back content from the left, matches how readers of left-to-right languages expect pages to turn.

Directional slides also need a fixed reference point. If the header slides with the content, the user loses track of what moved. The guide gives the header its own viewTransitionName and disables its animation, so the header stays put while the page content moves beneath it. And it adds pointer-events: none to the ::view-transition overlay, because without it, clicks made during an animation are swallowed by the overlay instead of reaching the page.

::view-transition {
  pointer-events: none;
}

That one rule is easy to miss and fixes a whole class of "the button didn't respond" reports.

A Next.js configuration detail where the docs disagree

Whether Next.js needs a configuration flag for View Transitions depends on which page of its documentation you read. The hosted reference page for experimental.viewTransition, still labelled for version 16.2.3, says to enable the flag in next.config.js and warns that the feature is experimental and not recommended for production. The view transitions guide, last updated on 15 October 2026, says that view transitions work in the App Router with no configuration and that React 19.3 provides everything it uses.

The documentation bundled inside the next@16.4.5 package settles it for current versions. That package contains the guide with the "no configuration" wording and no longer includes a reference page for the viewTransition flag at all. On 16.4 and later, there is nothing to switch on. On 16.2 or 16.3, follow the flag documentation for your installed version, which you can read in node_modules/next/dist/docs. That folder is a reliable tiebreaker whenever the hosted docs and your installed version seem to disagree.

Placement mistakes that silently disable animations

Most "my View Transition does nothing" problems come from where the boundary sits in the tree, not from its props. None of these produces an error.

A DOM node above the boundary. Enter and exit only activate when the <ViewTransition> comes before any DOM node in the part of the tree being inserted or removed. Wrapping it in a <div> breaks it. The fix is to move the boundary outside the element:

// Does not animate on enter or exit
<div className="card">
  <ViewTransition><Card /></ViewTransition>
</div>

// Animates
<ViewTransition>
  <div className="card"><Card /></div>
</ViewTransition>

Boundaries inside layouts. As above, layouts persist, so enter and exit never fire there. Directional and page-level animations belong in pages.

Wrappers inside lists. Nested boundaries receive their own mutations rather than passing them to the parent, and in a list, the update animation applies to each item only when its <ViewTransition> sits directly in the list rather than inside a wrapper element. Reordering also needs stable keys. An index used as a key makes React believe every item changed.

Unstable keys on keyed swaps. The Next.js guide's tab example relies on key={slug} to make React treat old and new content as an exit and enter pair. If the key does not change when the content does, React performs an update in place instead.

This is also where Fragment refs help indirectly. A common reason for a wrapper <div> above a boundary is that some other code needed a DOM node to attach an IntersectionObserver or an event listener. In React 19.3, a ref on a <Fragment> gives you a FragmentInstance with observeUsing, addEventListener, focus and measurement methods that act on the fragment's children as a group, without adding a node. The <Fragment> reference covers the full method list. Removing those wrapper elements is often what lets a boundary sit at the top of its subtree, where it needs to be.

Back navigation, interruptions and flushSync

Three runtime behaviours explain the remaining cases where an animation should play and does not.

Browser back and forward. The React reference says React skips animations for popstate navigations, because scroll and form restoration have to finish synchronously, and notes that routers built on the Navigation API avoid the limitation. The Next.js guide describes the result in its own router slightly differently: back and forward gestures carry no transition type, so directional slides do not play, while a shared element morph still applies if both pages have matching names. The two descriptions are about different layers, but they leave the same advice. Never rely on an animation to explain a back navigation, and test the back button and swipe gestures on each browser you support.

A transition already running. If one View Transition is in progress, React waits for it to finish, and updates that arrive in the meantime are batched. A long animation therefore delays the next one. This is the practical case for short durations: the Next.js guide's timings sit between 150 and 400 milliseconds, and we would treat anything longer on a frequently used screen as a design decision that needs a reason.

flushSync. A flushSync call in the middle of the sequence makes React skip the Transition. Third-party components that call it internally can disable animations in a way that is hard to trace, so when an animation stops working after a library upgrade, search the dependency for it.

Reduced motion and accessibility remain your job

React does not disable View Transitions for users who have asked their operating system to reduce motion. The reference docs recommend always handling the prefers-reduced-motion media query, and the Next.js guide supplies a blunt but effective default:

@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(*),
  ::view-transition-new(*),
  ::view-transition-group(*) {
    animation-duration: 0s !important;
    animation-delay: 0s !important;
  }
}

With this in place, content swaps instantly, which is what the browser does without view transitions at all. A finer approach keeps cross-fades and removes positional movement, since large horizontal slides are the most likely to cause discomfort, while opacity changes carry far less risk. Whichever you choose, ship the media query in the same pull request as the first animation, not as a follow-up.

The overlay matters for keyboard and pointer users too. Named participants, such as an anchored header, are skipped by hit-testing for the duration of a transition even with pointer-events: none on the overlay, so avoid naming elements that people click quickly and repeatedly. And because animations wait for Transitions, focus management should not depend on an animation finishing: move focus as part of the state change, not in an onEnter callback.

If your products serve customers in the EU, motion and focus behaviour are part of the accessibility picture your team is already assessing, and our guide to European Accessibility Act compliance covers where those obligations come from.

Browser support and progressive enhancement

Same-document view transitions reached Baseline status on 14 October 2025, when Firefox 144 shipped them and all three major browser engines supported the core API. web.dev's announcement also noted that Firefox's first implementation did not include view transition types, which React's integration depends on for typed animations.

The Next.js guide, updated in October 2026, says React's integration uses the newer parts of the API, namely transition types and view-transition-class, and lists them as available in Chromium 125 and later and in recent Safari and Firefox versions, with a warning that some animations may behave differently in Safari. Check the current support tables on the day you ship rather than relying on a version number in an article, this one included. The MDN View Transition API documentation links to them.

The reassuring part is the failure mode. Without browser support, the application works normally and the transitions simply do not animate. View Transitions are progressive enhancement by design, so the risk in an unsupported browser is a plainer experience, not a broken one. That is also the right way to brief a client or product owner: animation is a refinement on top of a working interface, and no user flow should depend on it.

Two adjacent limits are worth knowing. <ViewTransition> works only in the DOM today; React Native support is in progress but not available. And because the browser animates snapshots of the old and new content, a transition that covers the whole page asks more of a low-end phone than one that covers a single card. Animate the element that changed, not the whole page, and measure the screens that matter with real devices. If interaction latency is already a concern on your mobile templates, our piece on mobile-first design and Core Web Vitals is the right place to start before adding motion.

Should you replace your animation library?

For route transitions, loading reveals and simple enter and exit effects, <ViewTransition> is now a credible replacement for a JavaScript animation library, and it has two advantages a library cannot easily match. It is coordinated with React's own scheduling, so animations line up with Suspense and Transitions instead of fighting them. And it runs on a browser API, so there is less JavaScript to download for those effects.

It is not a replacement for everything. Gesture-driven motion, spring physics, scroll-linked effects and animations that must respond continuously to input are still better served by a dedicated library or by CSS scroll-driven animations. That is our view rather than an official position, and it reflects what each tool is designed for: View Transitions animate between two states, while those effects describe motion that has no fixed end state.

A sensible migration moves one category at a time. Route transitions first, because the App Router already treats navigations as Transitions. Suspense reveals second, using the rule above. Leave interactive motion where it is until there is a specific reason to change it.

A test plan before shipping View Transitions

A View Transition that looks right on a fast laptop in Chrome has passed the easiest test available. Before switching them on in production, we work through these checks on every screen that uses them:

Confirm versions. npm ls react react-dom next shows matching React versions at 19.3.1 or later, and Next.js at 16.4.5 or later.
List every boundary. Search the codebase for <ViewTransition and record which triggers each one animates. Anything without default="none" needs a reason.
Check placement. For each boundary that should enter or exit, confirm no DOM node sits above it in the inserted subtree, and that page-level boundaries live in pages rather than layouts.
Test the Suspense rule. Throttle the network in DevTools and confirm fallbacks appear instantly, reveals animate, and revisiting cached content does not animate.
Test shared elements cold and warm. Navigate with an empty cache and with prefetched data. The morph should play when prefetched, and fall back to a clean enter animation when not.
Click during animations. Confirm buttons and links respond while a transition is running.
Use the back button and gestures on every supported browser, and confirm nothing depends on an animation to make sense.
Turn on reduced motion in the operating system and confirm positional movement stops.
Test the browsers you support, including at least one where typed animations may be missing, and confirm the interface still works without animation.
Check keyboard focus after every animated state change.

Each of these, with pass criteria and a readiness score, is in the printable audit worksheet below, so the checks can be split across a team and ticked off screen by screen.

Get the React View Transitions Audit Worksheet

A two-page printable worksheet with 20 checks across setup, behaviour and release, each with clear pass criteria, plus a readiness score that tells you whether a screen is ready for View Transitions in production. No account, no sales sequence.

Get the PDF

FAQ

Do I need a configuration flag to use ViewTransition in Next.js?

Not on Next.js 16.4 or later. The view transitions guide and the documentation bundled with next@16.4.5 say view transitions work in the App Router with no configuration, because React 19.3 provides <ViewTransition> and addTransitionType. Older 16.x versions documented an experimental.viewTransition flag, so check the docs in node_modules/next/dist/docs for your installed version.

Why does my ViewTransition not animate?

The most common causes are an update that is not wrapped in startTransition, a DOM element placed above the boundary, a boundary inside a layout that never enters or exits, and default="none" on a shared pair without an explicit share prop. A flushSync call during the update also makes React skip the animation. None of these produces an error.

Does React ViewTransition work in Firefox and Safari?

The core View Transitions API has been supported in all major browser engines since October 2025. React's integration also uses transition types and view-transition-class, which Next.js lists as available in Chromium 125 and later and in recent Safari and Firefox versions. Where support is missing, the app works normally and simply does not animate.

Does React turn off View Transitions for reduced motion?

No. React does not check the user's motion preference. Add a prefers-reduced-motion media query that sets animation durations and delays to zero on the ::view-transition-old, ::view-transition-new and ::view-transition-group pseudo-elements, or keep only opacity changes and remove movement.

Can I use ViewTransition with React Native?

Not yet. The React 19.3 announcement says <ViewTransition> currently works only in the DOM, and that support for React Native and other platforms is being worked on. Fragment refs and the other 19.3 changes are separate from this limitation.

Originally published on zignites.com.

WordPress 7.2 for Plugin Developers: Secrets API, 410s and What to Test

Muhammad Zeeshan Sardar — Thu, 29 Oct 2026 14:00:00 +0000

TL;DR: WordPress 7.2 ships on 8 December 2026 and RC1 is on 17 November. Most breaking changes are small: load-scripts.php and load-styles.php now return 410 Gone, and wp_kses() output is being normalised by an HTML API rewrite (7.2 or 7.3). The change worth real time is the new Secrets API, which lets plugins store API keys encrypted instead of as plain text in wp_options. Below: the schedule, getter, setter and migration code, and a test plan.

Most of the breaking changes in WordPress 7.2 will cost a well-maintained plugin an afternoon. The change that deserves real engineering time is not a breaking change at all. It is the new Secrets API, and the reason is simple: a plain-text API key sitting in wp_options is a bigger liability for most plugins than anything 7.2 removes.

That is the position this guide takes, and it shapes the order of everything below. First the schedule, so you know how much time you have. Then the Secrets API, because it is where the most value sits. Then the changes that can actually break a plugin: retired script concatenation, a rebuilt wp_kses(), a database session change and the new admin icons. It finishes with the test environment and the test plan we run on any plugin before a major release reaches its first release candidate.

Every technical detail here was checked against the WordPress 7.2 Beta 1 announcement, the Make WordPress Core posts, the developer blog and the relevant commits on 27 October 2026. 7.2 is still in beta, so function names and behaviour can change before release. Where a feature is not yet confirmed for 7.2, the section says so.

WordPress 7.2 release date and beta schedule

WordPress 7.2 is scheduled for release on 8 December 2026, and it is the final major release of the year. Beta 1 landed on 20 October and froze the feature list. The official release party schedule sets every milestone at 15:00 UTC:

Milestone	Date (2026)	What it means for plugin developers
Beta 1	20 October	Feature freeze. Start testing
Beta 2	27 October	Bug fixes from Beta 1
Beta 3	3 November	Bug fixes
Beta 4	10 November	Last beta. Your compatibility fix should be ready
RC1	17 November	Release candidate. Time to update "Tested up to"
RC2	24 November	Final fixes
RC3	1 December	Final fixes
Dry run	7 December	24-hour code freeze
Final release	8 December	WordPress 7.2 ships

The date that matters most is RC1 on 17 November. Before it, a bug report against a beta can still change what ships. After it, you are mostly confirming fixes. If 7.2 breaks something in your plugin and the cause is a regression in core, the beta weeks are the only window where reporting it changes the outcome for everyone.

What changes for plugin developers in WordPress 7.2

Seven changes in 7.2 are worth a plugin developer's attention. Some add capability, some remove old behaviour, and two are not yet guaranteed to land in this release.

Change	Status in 7.2	Who is affected	Effort
Secrets API for encrypted credential storage	In Beta 1	Any plugin that stores an API key, token or password	A small sprint, worth it
Script and style concatenation retired	In Beta 1	Plugins that link to `load-scripts.php` or `load-styles.php`, or rely on held output	An afternoon, or nothing
`wp_kses()` rebuilt on the HTML API	Targeting 7.2 or 7.3	Plugins that sanitise HTML and then compare, store or test the result	Run your fixtures
`NO_BACKSLASH_ESCAPES` stripped from the database session	In Beta 1	Almost no one. Sites that rely on that SQL mode	Usually nothing
Core admin icons replaced with SVGs	In Beta 1	Admin CSS or scripts that target core menu or toolbar icons	Visual check
Five `@wordpress/components` deprecated	Deprecated in 7.2, removal planned for 7.4	Block and admin UIs built with those components	Plan a replacement
Automated security review of plugin releases	Live on WordPress.org	Every plugin in the directory	Check your committer email

The Beta 1 announcement covers the editor features too: responsive controls, text shadow presets, Notes in the margin, client-side media processing in the Media Library and an "On This Day" dashboard widget. Those matter to site builders, but they rarely break a plugin. The sections below stay with the changes that touch plugin code.

The Secrets API: encrypted storage for API keys

The Secrets API gives plugins a standard way to store credentials encrypted at rest instead of in plain text. It is the most useful addition to WordPress for plugin developers in years, and it arrives without breaking anything.

The problem it solves is familiar to anyone who has built an integration. A plugin that talks to Stripe, an SMTP service, WhatsApp or an AI provider needs to keep a key somewhere. The safe option has always been a constant in wp-config.php, but most site owners cannot or will not edit that file. So the key ends up in wp_options as plain text, and from there it travels into every database backup, every staging copy and every SQL dump a support engineer is ever sent. One leaked backup is one leaked key.

The Beta 1 announcement describes the new API as supporting encryption at rest, credential rotation and customisable storage providers. It was committed to trunk under Trac #66187 on 13 October 2026, following the Secrets API proposal published in August. The function-level behaviour below comes from that ticket and a hands-on test of the committed code on trunk, since the official developer note had not been published when this was written.

The key points for a plugin developer:

wp_set_secret( $name, $value ) stores a value encrypted and returns true or a WP_Error.
wp_get_secret( $name ) returns one of three things: a WP_Secret object, null if nothing was ever saved, or a WP_Error if a value exists but cannot be decrypted.
A WP_Secret object does not print its value. Echoing it, JSON-encoding it or dumping it shows a placeholder. Serialising or cloning it throws an exception. The only way to the plain value is $secret->reveal().
Values are encrypted with libsodium (XChaCha20-Poly1305), and the key that unlocks them is derived from wp-config.php, never stored in the database. A stolen database on its own yields ciphertext.
Secret names follow a plugin-slug/key-name pattern using lowercase letters, numbers, hyphens and underscores.
The functions do not check capabilities, because they must work from cron and REST requests. Your settings screen still has to check current_user_can() and a nonce. Core adds a manage_secrets capability you can use.
There is no admin screen for secrets in 7.2. It is planned for a later release.

The namespace in the name is for organisation, not access control. Any plugin running on the site can read any secret. That is an honest limitation, and it is the right one: the API protects credentials from leaked databases and backups, not from malicious code already running inside WordPress.

How to read and save a key with the Secrets API on any WordPress version

Your plugin will support versions below 7.2 for a long time, so the integration has to feature-detect the API and fall back cleanly. The pattern we use keeps three sources in a fixed order of trust: a constant first, the Secrets API second, the old option last.

function acme_sync_get_api_key(): string {
    // 1. A constant in wp-config.php is still the strongest option.
    if ( defined( 'ACME_SYNC_API_KEY' ) && ACME_SYNC_API_KEY ) {
        return (string) ACME_SYNC_API_KEY;
    }

    // 2. WordPress 7.2 and later.
    if ( function_exists( 'wp_get_secret' ) ) {
        $secret = wp_get_secret( 'acme-sync/api-key' );

        if ( $secret instanceof WP_Secret ) {
            $value = $secret->reveal();
            return is_wp_error( $value ) ? '' : $value;
        }

        if ( is_wp_error( $secret ) ) {
            // Stored but unreadable. Surface an admin notice.
            // Never fall back to a plain-text copy here.
            return '';
        }
    }

    // 3. Older WordPress, or a site that has not migrated yet.
    return (string) get_option( 'acme_sync_api_key', '' );
}

function acme_sync_save_api_key( string $key ) {
    // Capability and nonce checks belong in the calling form or route.
    if ( function_exists( 'wp_set_secret' ) ) {
        return wp_set_secret( 'acme-sync/api-key', $key );
    }

    return update_option( 'acme_sync_api_key', $key, false );
}

Two details in that code are deliberate.

The WP_Error branch returns an empty string instead of trying the old option. If a site's salts change, every secret becomes unreadable, and silently reading a stale plain-text copy would hide the problem while putting the leaked value back into use. The correct response is a visible notice asking the administrator to re-enter the key.

The null and WP_Error cases are handled separately because they mean different things. null means "never connected", so showing your setup screen is right. WP_Error means "connected, but something is wrong with the encryption keys", and resetting the plugin to its setup screen would confuse the site owner and lose context.

Call reveal() as late as possible, right before the HTTP request that needs the key, and keep the result in a local variable. Do not cache it, log it or pass it through filters. A useful side effect of this design is that every place your plugin touches a credential becomes searchable: look for ->reveal().

Migrating existing keys out of wp_options

Core will not move your plugin's existing options for you. It provides a helper, wp_import_option_as_secret(), which copies an option into a secret, leaves the original option in place and marks the secret as needing rotation. Removing the old option is your job, and it should only happen after you have confirmed the copy reads back correctly.

function acme_sync_migrate_api_key(): void {
    if ( ! function_exists( 'wp_import_option_as_secret' ) ) {
        return;
    }

    $legacy = get_option( 'acme_sync_api_key' );
    if ( ! is_string( $legacy ) || '' === $legacy ) {
        return; // Nothing to migrate, or already done.
    }

    if ( null !== wp_get_secret( 'acme-sync/api-key' ) ) {
        return; // Never import over an existing secret.
    }

    $imported = wp_import_option_as_secret( 'acme_sync_api_key', 'acme-sync/api-key' );
    if ( is_wp_error( $imported ) ) {
        return; // Try again on the next upgrade run.
    }

    $secret = wp_get_secret( 'acme-sync/api-key' );
    if ( $secret instanceof WP_Secret && hash_equals( $legacy, (string) $secret->reveal() ) ) {
        delete_option( 'acme_sync_api_key' );
    }
}

Run this from your plugin's upgrade routine, not on every request. The guard against importing over an existing secret matters: a second import moves the current value into the "previous" slot, which is not what you want.

The "needs rotation" flag is the part most developers will be tempted to ignore, and it is the part that matters most. Encrypting a key today does nothing for the plain-text copies already sitting in last month's backups. The real fix is a fresh key from the provider. After migrating, tell your users clearly that they should generate a new key and paste it in, and explain why in one sentence. Site Health lists secrets that still need rotation, so the reminder does not depend on your plugin alone.

WP_SECRETS_KEY, rotation and what the Secrets API does not protect

Three operational details decide whether the Secrets API helps or causes support tickets.

The site key. By default, the encryption key chain starts from the LOGGED_IN_KEY and LOGGED_IN_SALT values in wp-config.php. A dedicated WP_SECRETS_KEY constant overrides that, and Site Health recommends one, because changing the salts (a common step after a compromise) otherwise makes every secret unreadable. The catch is timing: adding WP_SECRETS_KEY to a site that already has secrets changes the site key, and every existing secret then fails to decrypt. Nothing falls back to plain text, which is correct, but the result is still a broken integration. If your documentation tells users to set the constant, tell them to do it before saving any keys.

Rotation. Each secret keeps two slots, current and previous. Saving a new value moves the old one into the previous slot, so you can switch providers' keys without downtime: try the new one, fall back to the previous while the provider catches up, then call wp_retire_secret_version() to remove the old value. Nothing retires it automatically, because core cannot know when your provider stopped accepting it.

What it does not protect. The API is a hardening layer, not a sandbox. It protects against leaked database dumps, SQL injection that reads wp_options, staging copies and keys appearing in debug output. It does not protect against a malicious plugin, an administrator who can run arbitrary code, or anyone who holds both the database and wp-config.php, such as a full-site backup archive. For sites where you control the server, a constant or an environment variable is still the stronger option. The Secrets API exists for the large majority of sites where the administrator pastes the key into a settings screen.

Hosts can also replace the storage entirely through a secrets.php drop-in, moving credentials into a managed vault. If that store is read-only, saving fails, so check wp_secrets_provider_is_writable() before showing an editable key field.

Script and style concatenation is retired: what breaks

WordPress 7.2 no longer concatenates admin and login-screen scripts and styles through load-scripts.php and load-styles.php. Every script and stylesheet is now printed as its own tag, and the two loader files respond with 410 Gone without loading WordPress.

Concatenation made sense when browsers opened few connections per host over HTTP/1.1. It had also been a long-running source of bugs, from ignored SCRIPT_DEBUG settings to duplicated inline styles. Core turned it off by default earlier in the cycle and began prefetching the assets of the next admin screen instead. The commit that retired it landed on 19 October under Trac #57548, the day before Beta 1.

For most plugins, nothing changes. The breakage is concentrated in three patterns:

Linking to the loaders directly. Some plugins copied a load-scripts.php or load-styles.php URL from an admin page's source years ago to style a dialog, a preview window or a setup screen. Those requests now get a 410, so the page loses its styles or scripts. The commit notes that around 45 plugins in the directory still do this.
Relying on held output. A few plugins set the do_concat property to true, or return false from the print filters, so core holds markup back and the plugin prints it elsewhere. Items are now always printed immediately, so this no longer works.
Using the print filters for their return value. print_head_scripts, print_footer_scripts, print_admin_styles and print_late_styles are now applied through apply_filters_deprecated(). Callbacks still run, with a deprecation notice, but their return values are ignored.

Other things keep working. Defining CONCATENATE_SCRIPTS has no effect any more because nothing reads it, so plugins that set it to false are fine. The deprecated properties are still declared, so reading them raises no notice. script_concat_settings(), _print_scripts(), _print_styles(), in_default_dir() and WP_Dependencies::get_etag() are deprecated but still callable, with a notice.

How to find concatenation dependencies in your plugin

A single search across your codebase tells you whether any of this applies. Run it from the plugin's root directory:

grep -rnE "load-(scripts|styles)\.php|CONCATENATE_SCRIPTS|do_concat|print_html|script_concat_settings|_print_(scripts|styles)\(|print_(head|footer)_scripts|print_(admin|late)_styles|in_default_dir" \
  --include=*.php --include=*.js --include=*.html .

Then sort each match into one of three buckets:

A loader URL in a template, dialog or inline HTML. Replace it. In a page that runs inside WordPress, enqueue the handles you need with wp_enqueue_script() and wp_enqueue_style(). In a standalone page that prints its own document, call wp_print_scripts() and wp_print_styles() with the handles instead.
do_concat set to true, or a print filter returning false. Rewrite the logic. If you were capturing markup to move it, enqueue in the right place instead, or use the script_loader_tag and style_loader_tag filters to adjust individual tags.
Everything else (setting do_concat to false, reading default_dirs, defining CONCATENATE_SCRIPTS). This works, but clean it up when convenient, since the code no longer does anything.

Bundled third-party code deserves a look too. A match inside a vendor SDK is still your plugin's problem once it ships in your zip. If you want a quick picture of how many active plugins on a client site might be affected by changes like this, our WordPress Plugin Risk Report lists what a site runs and how recently each plugin was maintained, which is usually the best predictor of who will fix things in time.

wp_kses() on the HTML API: sanitised output will look different

wp_kses(), the function behind wp_kses_post() and most HTML sanitisation in WordPress, is being rebuilt on the HTML API. The progress report targets 7.2 or 7.3, depending on what testing turns up. It is not guaranteed for this release, but if it lands, the output of sanitised HTML changes in ways your code can notice.

The interface stays the same. What changes is the shape of the result:

Output is normalised. Tags come back lowercase, attributes are double-quoted, the self-closing slash on void elements is dropped and character references are decoded and re-escaped consistently. An <IMG class=x /> input becomes <img class="x">.
Disallowed script and style elements are removed with their contents. The legacy implementation stripped the tags and left the code behind as visible text.
Text that only looked like a tag is kept. Input such as "under <$500" used to swallow text; it is now escaped and preserved.
Incomplete trailing markup is dropped. A fragment that ends mid-tag loses that tail instead of having it escaped.
Complex SVG and MathML is cut off. Embedded SVG or MathML that needs full tree-aware parsing is rejected from that point onward.

Plugins that only sanitise and output HTML will rarely notice. The risk sits with code that sanitises and then compares the result, such as change detection, cache keys or hashes built from sanitised content, and with unit tests that assert exact HTML strings. The Core team suggests assertEqualHTML() for tests, which compares HTML semantically rather than byte for byte.

There is an escape hatch, add_filter( 'wp_kses_force_legacy_parser', '__return_true' );, which restores the old implementation. Treat it as a way to keep a site running while you fix your code, not as a fix. The report is explicit that the legacy parser will be removed, possibly as early as 7.2.0, and any problems belong on Trac #66208 while there is still time to address them.

NO_BACKSLASH_ESCAPES is now stripped from the database session

From 7.2, wpdb removes the NO_BACKSLASH_ESCAPES SQL mode from WordPress's own database session. The developer note explains why: WordPress escapes special characters with backslashes, and when that mode is enabled on the server, MySQL treats the backslash as a literal character, so escaped queries fail or return wrong data. Some hosts enable it, and the resulting bugs are hard to trace.

For nearly every plugin this is a fix rather than a risk. It only affects WordPress's session, not the server's global settings, and plugins that use $wpdb->prepare() get more predictable behaviour.

If a site genuinely depends on that mode, it can be kept with the existing incompatible_sql_modes filter, but only from a db.php drop-in. WordPress connects to the database before plugins and must-use plugins load, so a filter added in a plugin runs too late. If your plugin opens its own database connection with a separate driver, this change does not touch it, and that connection keeps whatever mode the server sets.

Admin icons, Core icons and deprecated components

The visual changes in 7.2 will not throw errors, but they can make a plugin's admin screens look broken.

Core admin menu and toolbar icons are now SVGs. WordPress 7.2 replaces the Dashicons in the admin bar and sidebar with icons from the WordPress icon library, rendered with wp_get_icon() from 7.1. The Make Core post on the change explains the accessibility reasoning: icon fonts are read inconsistently by screen readers and can vanish in forced-colour modes. If your plugin's admin CSS or JavaScript targets the icon markup of core menu items or toolbar nodes, check those screens. A block's block.json icon slug still falls back to a Dashicon, so block icons are unaffected for now.

Core icons use strokes, not fills. Roughly 330 icons in @wordpress/icons were redrawn as stroke-based SVGs, and each sets fill: none inline. A fill prop or CSS fill rule no longer recolours them; use CSS color instead. The October developer roundup also advises updating @wordpress/icons and @wordpress/components together, because mixing new icons with an older Icon component can drop the merged styles.

Five components are deprecated. Divider, ResponsiveWrapper, Scrollable, ZStack and Elevation in @wordpress/components are marked deprecated since 7.2, with removal planned for 7.4. The suggested replacements are plain CSS (for example aspect-ratio instead of ResponsiveWrapper) and the Separator component instead of Divider. In MediaUpload, unstableFeaturedImageFlow is now featuredImageFlow, with the old name on the same removal path. Nothing breaks in 7.2, but this is the release to schedule the replacement.

Two smaller notes for editor integrations: the post sidebar is being rebuilt on DataForm, and the roundup warns that PluginPostExcerpt may not survive the move. The React 19 upgrade is listed on the roadmap but described as unlikely to fully land in 7.2.

Plugin directory releases now pass an automated security review

Shipping a 7.2 compatibility update now involves one more step outside your code. The WordPress.org Plugins team introduced an automated security review for plugin releases: during the release cooldown, several AI models and Jetpack Scan score each new release. High-risk releases are blocked automatically, and committers receive an email with the findings.

Two practical consequences follow. First, make sure the email address on every committer account is one that somebody actually reads, because a blocked release you do not hear about is a compatibility fix that never reaches users. Second, do not leave your 7.2 update until the week of the final release. Give the release room to be reviewed, and if anything is flagged, room to address it before 8 December. This is one more reason the work belongs in the beta window.

How to set up a WordPress 7.2 test environment

The fastest useful setup is a staging copy of a real site with your plugin configured as a customer would have it, upgraded to the latest 7.2 beta. A clean install catches fatal errors. A realistic one catches the problems your users will actually report. Never install a beta on a production site.

The Beta 1 announcement lists four ways to get 7.2:

The WordPress Beta Tester plugin. Choose the "Bleeding edge" channel and the "Beta/RC Only" stream, then update from Dashboard, Updates.
WP-CLI. wp core update --version=7.2-beta1, replacing the version string with the latest beta as each one is released.
A direct download of the beta zip.
WordPress Playground, which runs the beta in your browser with no setup. It is ideal for a first look, and its new terminal can run PHP and WP-CLI commands against the live instance.

Test on at least two PHP versions: the lowest your plugin supports and the newest your users run. WordPress itself has required PHP 7.4 or later since 7.0, which dropped support for PHP 7.2 and 7.3. Turn on WP_DEBUG and WP_DEBUG_LOG so deprecation notices from the concatenation changes are written to the log rather than missed.

Keep a second environment on 7.1 alongside it. Several checks below compare output between versions, and a side-by-side diff is far quicker than reasoning about what changed.

A test plan for WordPress 7.2 compatibility

A plugin that activates without a fatal error on 7.2 has passed the smallest possible test. Before RC1, we work through this list for every plugin we maintain:

Activate, deactivate and upgrade. Activate the plugin on 7.2, then run your upgrade routine from the previous release with real data, and confirm the debug log stays clean.
Run the concatenation search. Use the search command above and resolve every loader URL and every reliance on held output.
Open every admin screen. Load each settings page, dialog, preview window and setup wizard with the browser's network panel open. Any request to load-scripts.php or load-styles.php returning 410 is a bug.
Diff sanitised output. Push a set of real HTML fixtures through wp_kses_post() on 7.1 and on 7.2, and compare the results. A quick way with WP-CLI is wp eval 'echo wp_kses_post( file_get_contents( "fixture.html" ) );' on each install. Then repeat the run with the HTML API parser forced on, in case it lands.
Re-run your test suite. Pay attention to assertions on exact HTML strings and switch them to semantic comparison where the difference is cosmetic.
Exercise every query path. Run search, filters and any custom SQL with values containing quotes and backslashes, and confirm the results match 7.1.
Check the admin visually. Look at any screen where your CSS touches core menu items, the toolbar or icons, and check icon colours in both light and dark admin colour schemes.
Search for deprecated components. Look for Divider, ResponsiveWrapper, Scrollable, ZStack, Elevation and unstableFeaturedImageFlow, and plan their replacements before 7.4.
Prototype the Secrets API. Wire the getter, setter and migration into a branch, test all three return types, and test what happens when the site key changes.
Report anything that looks like a core regression on Trac or in the Alpha/Beta support forum, with steps to reproduce, while there is still time to fix it.

Each of these, along with pass criteria and a readiness score, is in the printable worksheet below, so a team can split the work and tick it off plugin by plugin.

When to update "Tested up to" and ship

Update the "Tested up to" header in your readme.txt once you have tested against RC1, not before. Raising it during the beta tells users you have tested a version that may still change. Leaving it until after 8 December means that, from the day 7.2 ships, your plugin's directory page warns users it has not been tested with the latest major release.

A sensible sequence looks like this:

During the betas: fix anything the test plan finds, and ship those fixes in a normal release. Fixes that work on both 7.1 and 7.2 do not need to wait for anything.
At RC1 on 17 November: rerun the plan against the release candidate and raise "Tested up to" to 7.2.
Before 8 December: ship the release that includes the updated header, leaving time for the automated security review.

The Secrets API is a separate track. Because it is purely additive and feature-detected, you can ship the getter and setter as soon as 7.2 is released, then run the migration in a later version once you are confident in it. There is no reason to rush a credential migration into the same release as a compatibility fix. If you build integrations for clients, this is also a good moment to look at how your plugins handle credentials more broadly, and our guide to WordPress plugin development covers the settings, security and release practices that make changes like these routine. For a plugin that needs this work done properly and quickly, our WordPress plugin development service covers compatibility updates and Secrets API migrations.

Get the WordPress 7.2 Plugin Compatibility Worksheet

A two-page printable worksheet with 22 checks across setup, testing and release, each with clear pass criteria, plus a readiness score that tells you whether a plugin is ready for 8 December. No account, no sales sequence.

Get the PDF

FAQ

When is WordPress 7.2 released?

WordPress 7.2 is scheduled for release on 8 December 2026 at 15:00 UTC. Beta 1 arrived on 20 October, with further betas on 27 October, 3 November and 10 November. The first release candidate is due on 17 November, followed by RC2 on 24 November and RC3 on 1 December.

Is WordPress 7.2 related to PHP 7.2?

No. WordPress 7.2 is a version of WordPress, and PHP 7.2 is an old version of the PHP language. They share a number by coincidence. WordPress dropped support for PHP 7.2 and 7.3 in WordPress 7.0, so WordPress 7.2 needs PHP 7.4 or later, and a current PHP 8 release is the better choice.

Will WordPress 7.2 break my plugin?

Most plugins will keep working. The changes most likely to cause problems are the retired script concatenation, which breaks plugins that link to load-scripts.php or load-styles.php directly, and the rebuilt wp_kses(), which changes the exact output of sanitised HTML if it lands in 7.2. Testing against the betas before RC1 on 17 November is the reliable way to know.

Do I have to use the WordPress Secrets API?

No. The Secrets API is optional, and existing options keep working. It is strongly worth adopting if your plugin stores API keys or tokens, because it keeps them encrypted in the database and out of plain-text backups. Feature-detect it with function_exists( 'wp_get_secret' ) so your plugin still runs on older WordPress versions.

Does CONCATENATE_SCRIPTS still work in WordPress 7.2?

No. WordPress 7.2 no longer reads the CONCATENATE_SCRIPTS constant, because scripts and styles are no longer concatenated at all. Defining it is harmless but has no effect, so you can remove it from wp-config.php and from any plugin code when convenient.

Will the new wp_kses() ship in WordPress 7.2?

It is not certain. The Core team targets WordPress 7.2 or 7.3, depending on what testing reveals. Test your plugin against it now either way, and if something breaks, the wp_kses_force_legacy_parser filter restores the old behaviour temporarily while you fix it.

Originally published on zignites.com.

Shopify Next Gen Events: Migrate Off Webhooks Without Losing Deliveries

Muhammad Zeeshan Sardar — Thu, 22 Oct 2026 12:00:00 +0000

TL;DR: Next Gen Events (GA 1 October 2026, API version 2026-10) lets a Shopify app subscribe to exact field changes and get the data it needs in the delivery. The config is the easy part. Triggers only fire for fields you list, and a query_filter suppresses deliveries by design, so a clean deploy proves very little. Test every state change in both directions, dedupe on Shopify-Webhook-Id, respond within five seconds, and keep a reconciliation job running.

Shopify's new event system makes most apps cheaper to run. It also makes it easier than ever to stop receiving something you rely on and not notice for weeks.

That trade sits at the centre of this migration. Classic webhooks are noisy but honest: something changed on the resource, so you hear about it, and your handler works out what. Next Gen Events flips the contract. You declare in advance exactly which field changes you care about, what data should come with them, and which results should be dropped. Shopify then does precisely that. If the declaration is wrong, nothing errors. The deliveries simply never arrive.

Next Gen Events became generally available on 1 October 2026 with API version 2026-10. Classic webhooks still work, nothing has a sunset date yet, and both systems can run inside the same app. So there is no deadline forcing anyone's hand. That is the best possible time to migrate, because you can do it one workflow at a time and prove each step before you remove the old one.

This guide covers how a subscription is built, where deliveries get silently suppressed, the limits that will reject your config at deploy time, and the order we would move workflows in. Every technical detail below was checked against Shopify's documentation for API version 2026-10 on 19 October 2026.

What Next Gen Events actually changes

Next Gen Events replaces "a resource changed" with "this specific field changed, and here is the data you would have fetched next". That is the whole idea, and it changes three things for an app.

First, deliveries become targeted. Instead of subscribing to products/update and receiving a payload every time anything on a product moves, you subscribe to the exact field paths that matter, such as a variant's price or a product's status. Shopify's GA announcement describes this as fewer deliveries, richer payloads and fewer follow-up API calls.

Second, the payload carries its own context. Each delivery includes a fields_changed summary listing what was added, updated or removed, plus the result of a GraphQL query you define. For most handlers, that removes the "receive webhook, then call the Admin API to find out what actually happened" round trip.

Third, configuration moves into shopify.app.toml. Subscriptions are declared under an [events] section with their own API version, deployed with the rest of the app configuration, and validated at deploy time.

Coverage at GA is 18 topics across merchandising, customers and companies, orders and fulfilment, inventory and locations, content, and custom data. That includes Product, Collection, Customer, Company, Order, FulfillmentOrder, Refund, Return, InventoryItem, Location, Article, Page, Metaobject and the metafield definition types. Anything Events does not cover yet stays on classic webhooks, which is one more reason to plan for a period where both systems run side by side.

Why the real migration risk is suppression, not configuration

The arguable claim of this post is simple: in a Next Gen Events migration, a config that deploys cleanly is not evidence that it works. The dangerous failures do not throw errors. They drop deliveries.

Classic webhooks fail loudly. If your endpoint is down, deliveries fail and show up in the logs. If your handler crashes, you see the exception. The surface area of "silently missing data" was mostly limited to the delivery itself going wrong.

Next Gen Events adds two new places where a change can happen in the store and your app never hears about it, both by design:

Triggers. An update subscription only fires for the field paths you list. Leave one out and changes to that field produce nothing.
Query filters. A filter evaluates the query result and suppresses the delivery when it is false. Filter on the wrong condition and you suppress the exact transition you needed to see.

Both behave exactly as documented. Neither appears as a failure in your delivery logs, because from Shopify's side nothing failed. That is why the rest of this guide spends more time on what you will not receive than on what you will.

The three parts of a subscription: triggers, query and filter

Every Events subscription answers three questions, and keeping them separate in your head prevents most mistakes.

Triggers answer "which changes matter?" They are dot-notation field paths such as product.status or product.variants.price. They narrow update deliveries to specific field changes. Parent triggers ending in *, such as product.variants.*, also fire for everything nested beneath them.

The query answers "what data do I need when it fires?" It is a GraphQL Admin API operation that Shopify runs after a qualifying change. Its variables, such as $productId and $variantsId, are filled in from the change itself, and its result arrives in the delivery's data field.

The filter answers "which results should be delivered at all?" A query_filter is an expression evaluated against the query result. If it evaluates to false, the delivery is suppressed. It requires a query, and any field it references must be selected in that same subscription's query.

Shopify's optimisation guide puts the division of labour plainly: use triggers to detect changes and use the filter only to test a current business condition. Mixing those roles, for example by using a filter to approximate a trigger that does not exist, is where suppression bugs come from.

A complete subscription, line by line

The fastest way to understand the format is to read one real subscription end to end. This one watches price and compare-at-price changes on variants and sends back the data a pricing or feed sync would need.

[events]
api_version = "2026-10"

[[events.subscription]]
handle = "variant-pricing"
topic = "Product"
actions = ["update"]
triggers = [
  "product.variants.price",
  "product.variants.compareAtPrice"
]
uri = "/events/variant-pricing"
query = """
query variantPricing($variantsId: ID!) {
  productVariant(id: $variantsId) {
    id
    sku
    price
    compareAtPrice
    product {
      id
      status
    }
  }
}
"""

Going through it field by field, using the app configuration reference:

api_version under [events] is required. It sets the version used to validate and run every subscription query. Developer preview users need to change this from unstable to 2026-10, including any subscription-level overrides.
handle is required and must be unique, using letters, numbers, underscores or hyphens, up to 50 characters. It comes back in both the payload and the headers, which makes it the natural routing key in your handler.
topic is the resource, here Product.
actions is any combination of create, update and delete.
uri can be an HTTPS URL, a relative path on your app's domain, or a Google Cloud Pub/Sub or Amazon EventBridge destination.
triggers is optional, but without it an update subscription fires for every supported field change on the resource. That is classic webhook behaviour with extra steps.
query and query_filter are optional.

Notice what the query asks for. It goes straight to the changed variant using $variantsId rather than loading the product and paging through variants(first: 100). That choice matters for both correctness and the complexity limit, and both come up again below.

A note on tooling versions: at the time of writing, the GA announcement and the migration guide quote different minimum Shopify CLI versions. Run shopify version, then check the current requirement in the getting started guide on the day you deploy rather than trusting either number.

Reading a delivery: fields_changed, query_variables and data

A delivery tells you what changed and what is true now, and those are deliberately separate fields.

The delivery structure guide lists the payload as topic, action, handle, fields_changed, query_variables, and, when you configured a query, data or errors. A trimmed delivery for the subscription above looks like this:

{
  "topic": "Product",
  "action": "update",
  "handle": "variant-pricing",
  "fields_changed": {
    "added": [],
    "updated": [
      "product[id: 'gid://shopify/Product/123'].variants[id: 'gid://shopify/ProductVariant/456'].price"
    ],
    "removed": []
  },
  "query_variables": {
    "productId": "gid://shopify/Product/123",
    "variantsId": "gid://shopify/ProductVariant/456"
  },
  "data": {
    "productVariant": {
      "id": "gid://shopify/ProductVariant/456",
      "sku": "TEE-BLK-M",
      "price": "24.00",
      "compareAtPrice": "30.00",
      "product": { "id": "gid://shopify/Product/123", "status": "ACTIVE" }
    }
  }
}

Three details in that payload change how a handler should be written.

fields_changed always contains added, updated and removed arrays, even when they are empty. Each entry is a path with the IDs embedded. Adding or removing a variant arrives as action: "update" with the path in added or removed, not as a separate create or delete on the variant.

query_variables is a flat map of the IDs that were available for this change. IDs bubble up the ownership hierarchy, so a variant change also supplies productId. On a delete, this map is often the only reliable way to identify the resource, because a query for a deleted node may return null.

data reflects the state when the query ran, not a snapshot of the moment the change happened. Shopify's migration guide gives returns as an example where the queried status can differ from the state at the time of the event. Treat fields_changed as "what happened" and data as "what is true now", and do not assume the two describe the same instant.

There is also an errors field, present only when the query fails to execute. Queries run with your app's access scopes, and fields the app cannot read may come back as null rather than raising an error. A handler that checks errors but not unexpected nulls will miss scope problems.

Triggers decide what you hear about

The trigger list is where most coverage gaps start, and the rules are stricter than they look.

Start with the obvious one: only listed paths fire. The Product topic reference lists more than fifty triggers, from product.title and product.status through variant prices, barcodes, options, swatches, media, bundle components and metafields. If your handler used to react to any product update and you now list three triggers, everything outside those three has gone quiet.

The second rule is less obvious. Every query variable must be available for every trigger in the subscription. Product-level triggers such as product.title supply only productId. Variant triggers such as product.variants.price supply productId and variantsId. A query that needs $variantsId therefore cannot share a subscription with product.title. Shopify validates this at save time, so the error is visible, but the fix (splitting into two subscriptions) changes how many deliveries you receive and how your handler routes them.

Third, watch for overlapping prefixes. A parent trigger like product.variants.* already includes product.variants.price. Listing both in one subscription adds nothing. Listing them in two subscriptions means a single price change produces two deliveries, each with its own ID.

Fourth, some things you might expect to trigger on do not exist. Calculated fields such as product.description and auto-updated timestamps such as product.updatedAt are not valid triggers. There is also no inventory quantity trigger on Product at all. Stock changes live on the InventoryItem topic, through its inventory-level triggers. An app that synced stock from products/update needs a new subscription on a different topic, not a new trigger on the old one.

The working rule we use: for every field your current handler reads, write down the trigger that will fire when it changes. If you cannot name one, that field is not covered yet.

Filters decide what you never hear about

A query_filter is the single easiest way to lose data in this migration, because it suppresses deliveries on purpose.

The syntax is straightforward. Shopify's example is product.status:'ACTIVE', which only delivers when the queried product is active. The filter runs after the query, needs the referenced fields to be selected in that query, and returns nothing to your app when it evaluates to false.

Now take an app that keeps a feed of active products. Filtering on active status looks like a sensible way to cut noise. Follow what happens when a merchant archives a product:

The product's status changes from ACTIVE to ARCHIVED.
The product.status trigger fires.
The query runs and returns status: ARCHIVED.
The filter evaluates to false, so the delivery is suppressed.
Your feed never learns the product left, and keeps advertising it.

Shopify's optimisation guide calls out this exact case: a filter on active status would suppress the deactivation delivery. The general rule is to test both directions of every state change your app tracks. If a transition out of the filtered state matters, either drop the filter or handle that transition in a separate, unfiltered subscription.

Two related traps from the migration guide are worth knowing before you write any filter. Selecting a status field in a query does not filter anything on its own, so an orders/paid replacement needs triggers and a filter, not just displayFinancialStatus in the query. And the customer enable and disable cases return current state, so selecting state will not restrict deliveries to that transition.

The 100-point complexity limit

Every Events subscription query is capped at 100 complexity points, and Shopify checks this at deploy time without running the query.

The default costs come from the Admin API's cost calculation rules: scalar and enum fields cost nothing, object fields cost one point, and connections cost according to their first or last argument. Some fields carry custom costs, so counting fields by hand only gives you an estimate. A broad query that loads an order with its line items, fulfilments and transactions, or a product with all variants and media, can pass 100 quickly. The failure message reports the calculated score against the maximum, so it is clear when it happens.

Three habits keep queries under the limit and make them more correct at the same time:

Query the changed node directly. If the trigger supplies variantsId, query productVariant(id: $variantsId) rather than the product's variant connection.
Treat first: N as partial coverage. A connection like variants(first: 50) can leave out the very variant that changed if it falls outside that page. A page size limits what comes back. It is not a complexity budget and it is not a complete snapshot.
Split rather than widen. Two small subscriptions with distinct handles are usually better than one large one. Each delivery gets smaller, and you stop reloading data that did not change.

Validate before release with shopify app deploy --no-release. It checks every Events query against the limit and creates an app version without releasing it.

Verifying and deduplicating every delivery

The delivery mechanics will feel familiar if you have built classic webhook handlers, and the same discipline applies. If you want the wider context on endpoint hardening, our post on API security and the OWASP API Top 10 covers the general rules.

For HTTPS deliveries, the verification guide gives the requirements:

Each request carries a base64-encoded Shopify-Hmac-Sha256 header, computed from the raw request body with your app's client secret. Verify it before processing. Pub/Sub and EventBridge deliveries do not need HMAC verification.
After rotating the client secret, the signature can take up to an hour to reflect the new secret, so accept both during a rotation window.
Duplicates can happen, for example after a timeout and retry. Prefer idempotent processing. Where that is not possible, store each Shopify-Webhook-Id and skip any you have already seen, returning success.
If several subscriptions match the same change, each gets its own delivery with its own Shopify-Webhook-Id. Deduplicating by that header will not merge them.

The troubleshooting guide adds the timing rules. Your endpoint has five seconds to respond, any 2xx status counts as success, and Shopify retries failures automatically. The guide does not publish a retry count or window. It does say that if an endpoint keeps failing, deliveries for that subscription stop and you may need to reconcile missing data.

Five seconds is not long enough to call a third-party API, write to several tables and send an email. Verify, record, queue, respond. Here is that shape in Node with Express:

import crypto from "node:crypto";
import express from "express";

const app = express();
const SECRET = process.env.SHOPIFY_API_SECRET;

function validHmac(rawBody, header) {
  if (!header) return false;
  const expected = crypto
    .createHmac("sha256", SECRET)
    .update(rawBody)
    .digest();
  const received = Buffer.from(header, "base64");
  return (
    received.length === expected.length &&
    crypto.timingSafeEqual(received, expected)
  );
}

app.post(
  "/events/:route",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    if (!validHmac(req.body, req.get("Shopify-Hmac-Sha256"))) {
      return res.sendStatus(401);
    }

    const deliveryId = req.get("Shopify-Webhook-Id");
    const isNew = await deliveries.insertIfAbsent(deliveryId, {
      shop: req.get("Shopify-Shop-Domain"),
      handle: req.get("Shopify-Handle"),
      triggeredAt: req.get("Shopify-Triggered-At"),
    });

    if (isNew) {
      await queue.publish("shopify-events", {
        deliveryId,
        body: req.body.toString("utf8"),
      });
    }

    res.sendStatus(200);
  }
);

deliveries.insertIfAbsent should be a single atomic operation, such as an insert against a unique index, so two copies of the same delivery arriving together cannot both pass. The worker that consumes the queue does the real processing and should itself be idempotent, because a crash between processing and acknowledging will replay a message. If you build on Shopify's React Router app template, authenticate.webhook(request) handles the HMAC check for you before your code runs.

Ordering, delays and why you still need reconciliation

Next Gen Events does not promise ordered or timely delivery, and an app that assumes either will drift.

The documentation does not state an ordering guarantee. The optimisation guide says targeted subscriptions can fail or arrive out of order, and the troubleshooting guide says deliveries can arrive late without giving a maximum delay. Two consequences follow.

Do not let a late delivery overwrite newer state. Because data reflects the query result rather than the original change, it is usually current. But if you store values derived from it, compare a source timestamp such as the resource's updatedAt before writing, and discard anything older than what you already hold. Shopify-Triggered-At tells you when Shopify triggered the delivery, which is useful for spotting stale ones.

Run a reconciliation job. Shopify's own guidance is to keep a separate process that uses targeted Admin API queries or bulk operations to repair missed work and page through complete collections. That covers the delivery that exhausted its retries during an outage, the transition a filter suppressed, and the trigger you forgot. It is the safety net that makes a targeted event system safe to depend on, and it is the same pattern we recommend in any multi-tenant SaaS architecture where events feed per-tenant state.

How often to reconcile depends on how costly drift is. A nightly bulk comparison is enough for most catalogue syncs. Inventory and order state usually justify something tighter.

Large payloads and payload_url

When a delivery exceeds the channel's size limit, Shopify sends a pointer instead of the payload, and a handler that does not check for it will read empty fields.

The limits are 5 MB for HTTPS, 10 MB for Google Cloud Pub/Sub and 256 KB for Amazon EventBridge. Over the limit, Shopify stores the full content and delivers a small payload with topic, action, handle, payload_url, payload_size_bytes and expires_at. The fields_changed, query_variables and data fields only exist in the stored content.

So the first thing a worker should do is check for payload_url. If it is present, download the content before expires_at, because the URL is short-lived. For HTTPS, verify the HMAC on the small payload you received, not on the downloaded content. EventBridge users should take the 256 KB ceiling seriously, since a modest product query with metafields can approach it.

Mapping classic webhook topics: the gotchas worth knowing first

Most classic topics map cleanly onto an Events topic plus a trigger. A handful do not, and Shopify's migration guide lists them. These are the ones most likely to affect a typical app:

Field names change shape. REST payload fields generally move from snake_case to camelCase, but not always one to one. admin_graphql_api_id becomes id, body_html becomes descriptionHtml, and financial_status becomes displayFinancialStatus. Some REST fields have no GraphQL equivalent.
Tags are the full current set. On Events, tags is every tag the resource has now, not the ones added or removed. If your logic reacts to a specific tag being added, compare against stored state.
Order status webhooks need triggers and filters. orders/paid, orders/fulfilled and orders/partially_fulfilled do not have one-line equivalents.
Inventory lives on InventoryItem. There is no stock quantity trigger on Product. For a location being disconnected, subscribe to inventoryItem.inventoryLevel.isActive and check for false.
Fulfilment IDs differ. A classic fulfilment ID is not a fulfilment order ID. Query the parent through fulfillmentOrderId.
Returns need care. A create delivery cannot reliably tell you whether a return was requested or already approved. Use the return.requestApprovedAt trigger for approvals.
Some topics stay on webhooks. In 2026-10 there is no Events equivalent for the reverse fulfilment order disposition webhook, so keep reverse_fulfillment_orders/dispose where it is.

Deletes are the simplest case. No query is needed, and query_variables identifies the deleted resource.

Which workflows to move first

Move the workflows where an Events payload removes a follow-up API call and where a missed delivery is cheap to repair. Leave the ones where a missed delivery costs money until last.

A practical order:

High-volume, read-heavy handlers. A products/update handler that immediately fetches the product to see what changed is the clearest win. Targeted triggers cut volume and the query removes the fetch.
Catalogue and content sync. Product, collection, metafield, metaobject and page changes feeding a search index, a product feed or a headless front end. Our post on structured content for AI search covers why keeping that layer accurate matters.
Customer and company data. Lower volume, but useful once the pattern is proven.
Orders, refunds, returns and inventory last. These have the most topic-specific gotchas and the highest cost when something is missed. Move them once reconciliation is running and you have a few weeks of data from the earlier workflows.

Measure as you go. Shopify suggests tracking delivery volume, payload size and follow-up API calls during migration rather than assuming savings, and the GA post does not claim specific numbers. Optimised subscriptions can even produce more deliveries than before, because one merchant action may touch both product and variant data. Each delivery is smaller and cheaper, which is usually the better trade, but only measurement will tell you for your app.

Running both systems side by side

During migration, classic webhooks and Events subscriptions can live in the same app, and that overlap is what makes the move safe.

The pattern is a shadow period. Deploy the Events subscription alongside the existing webhook, but have the new handler record what it would do rather than doing it. Compare the two streams for a few days across real merchant activity: every change the webhook caught should appear in an Events delivery, and every Events delivery should map to something the webhook path processed. Gaps point straight at a missing trigger or an over-eager filter.

Two things to plan for during the overlap. The two systems produce separate deliveries with separate IDs, so Shopify-Webhook-Id will not deduplicate across them. If both paths are live and writing, rely on idempotent writes keyed on the resource and its updatedAt. And when you cut over, switch the write path to Events first, keep the webhook subscribed but inert for a short period, then remove it. Removing first leaves you with no way back.

A test plan before you release

A subscription that deploys is validated. A subscription that works has been tested against every transition your app depends on. Before releasing, we run through this on a development store:

Validate with shopify app deploy --no-release and fix any complexity or variable errors.
Confirm every trigger exists in the Events reference for 2026-10 and supplies every variable the query uses.
Confirm the app has the access scopes each topic requires, and look for unexpected nulls in data.
Exercise create, update and delete, and inspect data, errors, fields_changed and query_variables for each.
Remove a relationship (a product from a collection, a variant from a product) and check the delivery arrives.
For every filter, move the resource into and out of the filtered state, and confirm you see every transition you need.
Send the same delivery twice and confirm nothing is processed twice.
Hold a delivery past five seconds in a test and confirm the retry is handled cleanly.
Run the reconciliation job and confirm it finds and repairs a change you deliberately suppressed.

The Dev Dashboard helps with the last mile. Under your app's Logs you can see deliveries from the past seven days, filtered by topic, status and shop, with response codes, attempt numbers and payload sizes. The Overview shows failed delivery rate and 90th-percentile response time. Log data can lag by several minutes, so do not panic if a test delivery takes a moment to appear.

Every check above, along with the planning and cut-over steps, is in the printable worksheet below with pass criteria and a readiness score, so you can tick through it per workflow.

Get the Next Gen Events Migration Worksheet

A two-page printable worksheet with 22 checks across planning, building and cut-over, each with clear pass criteria, plus a readiness score that tells you whether a workflow is ready to move. No account, no sales sequence.

Get the PDF

FAQ

Do I have to migrate from classic webhooks to Next Gen Events now?

No. Classic webhooks keep working, and as of API version 2026-10 Shopify has not announced a sunset date. Both can run in the same app, so you can migrate one workflow at a time. The advantage of starting early is that you can test thoroughly without a deadline.

Which Shopify topics does Next Gen Events support?

At GA there are 18 topics: Product, Collection, Customer, Company, Order, FulfillmentOrder, Refund, Return, InventoryItem, InventoryShipment, InventoryTransfer, Location, Article, Blog, Page, MetafieldDefinition, Metaobject and MetaobjectDefinition. Each has its own triggers, query variables and access scopes, listed in the Events API reference.

How do I avoid processing the same Shopify event twice?

Make processing idempotent where you can, so receiving a delivery twice has the same effect as receiving it once. Otherwise, store each Shopify-Webhook-Id atomically and skip any you have already seen, while still returning a 2xx response. Remember that separate subscriptions matching the same change produce separate IDs.

What happens if my Events query is too complex?

Deployment fails. Each subscription query is capped at 100 complexity points and checked at deploy time. The error reports the calculated score against the maximum. Query the changed node directly using the variable the trigger supplies, and split large subscriptions into smaller ones.

Does the data in a delivery show the state at the moment of the change?

Not necessarily. The query runs after the change, so data reflects state when the query ran. Use fields_changed to understand what happened, data for current state, and source timestamps such as updatedAt to avoid overwriting newer information with a late delivery.

Can I send Events to Pub/Sub or EventBridge instead of an HTTPS endpoint?

Yes. A subscription's uri can point to an HTTPS endpoint, a relative path on your app, Google Cloud Pub/Sub or Amazon EventBridge. Payload limits differ by channel: 5 MB for HTTPS, 10 MB for Pub/Sub and 256 KB for EventBridge, with larger payloads delivered as a short-lived payload_url.

Originally published on zignites.com.

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.