WordPress Plugin License Expired: What Actually Breaks

When a WordPress plugin license expired notice appears in your dashboard, the plugin itself almost never stops working — what stops is the supply of updates, the support channel, and in some cases a hosted service the plugin was only ever a front end for. That distinction is the whole decision. A plugin whose code does all the work can sit unrenewed for a year and keep doing its job badly; a plugin that calls a vendor’s API goes dark on a schedule the vendor chooses, and you need to know which kind you are running before the renewal invoice arrives.

What a WordPress plugin license expired warning actually means

Two separate things get confused here, and keeping them apart saves money and panic in roughly equal measure.

The first is the software license. Everything in the WordPress.org plugin directory has to be GPL or GPL-compatible — the directory’s own guidelines put it plainly: all code, data and images must comply with the GPL or a GPL-compatible license, with GPLv2 or later strongly recommended. Most commercial plugins distributed outside the directory follow the same model, because they are derivative works of WordPress itself. Under that license you may keep running the version you have, indefinitely, on as many of your own sites as you like.

The second is the commercial agreement attached to your license key. That is a support-and-updates subscription with an expiry date, and it is enforced technically: the vendor’s update server checks your key and declines to hand over a new ZIP when it has lapsed. Nothing checks your key at runtime on a well-behaved plugin, because there would be no legal basis to switch off code you already lawfully hold.

WooCommerce states the first part about as directly as a vendor can. Its FAQ says you can still use the product on your site for as long as you like, while you can no longer access the file for download or receive support or updates. Gravity Forms says the same in its own words: the plugin will remain on your sites and continue to operate, but with limitations — no updates, including bug fixes and security updates, and no support.

Three things that break, and only one of them is obvious

Group your paid plugins by which of these they are. The grouping predicts what expiry costs you far better than the price does.

The service-backed row deserves a concrete example, because “it keeps working” is misleading there. WP Rocket’s documentation says the plugin will continue to operate normally after expiry, then lists the cloud features — Remove Unused CSS, Load CSS Asynchronously and Rocket Insights — as stopping 15 days after the license expires. Caching carries on. The optimisations that made your Core Web Vitals numbers look good are the ones that quietly leave, two weeks later, long after anybody connects the change to a billing email. If you are weighing that kind of dependency up front, WooCommerce caching plugins: what breaks and what works goes through which parts of each option run locally.

The download-gated row is the one that ambushes agencies. Gravity Forms documents that an expired key cannot download the core plugin files or any add-ons, and cannot register a new site even when you are restoring a backup of a site the key previously covered. Read that again if you maintain client sites: your disaster recovery plan assumes you can reinstall what you already own, and for some vendors that assumption expires with the key.

Why “it still works” is the dangerous part

An expired plugin does not just stop receiving updates. It usually stops appearing in the places you look for updates, which is a different and worse problem.

Commercial plugins are not in the WordPress.org directory, so core has no way to check them. Each one ships its own updater, typically a filter on pre_set_site_transient_update_plugins that calls the vendor’s license server while WordPress is building the update list. Feed that server an expired key and it returns nothing available. Your Plugins screen then shows exactly what it shows for a plugin that is fully up to date: no notice, no row, nothing to click.

There is a second way to miss it. Because the check lives in the plugin’s own code, it only runs when the plugin is loaded — so an automated update job that runs WP-CLI with --skip-plugins never registers those filters and never sees those updates. Sites with disciplined automation can therefore be the ones most confident about patch levels they do not actually have.

Put those together and the failure mode is a plugin sitting at a version from fourteen months ago, with a vulnerability disclosed nine months ago, on a site whose owner reasonably believes everything is current because nothing is asking to be updated. Compare that with how a core problem behaves: when WordPress 7.1.2 shipped a fix for a critical CVE, the update appeared on every site within hours and automatic updates handled most of them. Commercial plugins have no equivalent, and WordPress 7.1 does nothing to change that.

Audit what you are actually paying for, from the shell

Most sites cannot answer two basic questions: which installed plugins are commercial, and which of those keys are still live. Both are a couple of commands with WP-CLI.

1. Separate the paid plugins from the free ones

# Plugins WordPress.org has no record of are your commercial ones
wp plugin list --fields=name,version,update,update_version,wporg_status,auto_update

The wporg_status column is the useful one: anything blank or unrecognised there is a plugin core cannot check against the directory, which is your shortlist. Note that update saying none for those rows means “the plugin’s own updater reported nothing”, which includes the expired-key case — so treat none on a commercial plugin as unknown rather than reassuring.

2. Find the license keys and their stored state

# Almost every commercial plugin stores its key and status in wp_options
wp option list --search='*license*' --fields=option_name,autoload,size_bytes
wp option list --search='*_lic*'    --fields=option_name,autoload,size_bytes

# Read one back, unserialised, to see the expiry date the plugin cached
wp option get edd_sample_license_status --unserialize

Option names vary by vendor — *license*, *_lic* and the plugin’s own prefix catch most of them. What you are looking for is the cached status payload, which usually contains the literal expiry date. That is faster and more honest than logging into five vendor dashboards, and it tells you about keys belonging to plugins somebody deactivated but never deleted.

While you are in there, check the autoload column. Licence status payloads are frequently autoloaded, which means they are read on every single request including every uncached front-end page view, and dead keys from removed plugins keep being loaded for years. On a site with a long plugin history that is measurable — auditing and trimming WordPress autoloaded options covers how to find and clear them without breaking anything.

3. Check the plugin headers for an Update URI

grep -rn --include="*.php" -m1 \
  -e "Update URI:" -e "^ \* License:" \
  wp-content/plugins/*/ | sort

The Update URI header, available since WordPress 5.8, exists so a plugin hosted outside the directory is not accidentally overwritten by a similarly named plugin on WordPress.org. Its presence is a reliable signal that a plugin is self-updating, and the value tells you which vendor’s server it is asking. The License header on the same pass confirms the GPL point above for each plugin you are running.

Renew, replace, or remove: how to decide

These are the criteria I weigh on client sites, in roughly this order. They are deliberately about exposure rather than about features, because features are what you compared when you bought the thing and exposure is what you are deciding about now.

If replacing is the answer, forms are the most common case, and the migration is more work than it looks: entries live in the old plugin’s tables, and notification routing, conditional logic and payment feeds all have to be rebuilt rather than imported. Contact Form 7 and Fluent Forms are the usual free destinations, and BeautyForms Form Builder is another — disclosure: I build and maintain that one, so judge it against the same criteria as the others, starting with whether its field types cover the forms you already have. Export your existing entries to CSV before you deactivate anything, because that export usually needs the old plugin active.

Whichever direction you go, do the swap on a staging copy and rehearse the deploy. Pushing staging to live in WordPress without losing orders covers getting the change onto production without clobbering data that arrived while you were working, which is exactly the risk when the plugin you are replacing collects submissions or orders.

If you decide to run a plugin unrenewed anyway

Sometimes that is the right call: a small admin-side utility, a site with no public input, a plugin you are removing next quarter anyway. Make it a deliberate, documented position rather than a drift.

1. Archive the exact ZIP you are running, with its version number in the filename, alongside your database backups.
2. Write the plugin name, version and the date the key expired into whatever document a future maintainer will actually read.
3. Subscribe to a vulnerability feed that covers plugins by slug and version, since your dashboard has stopped being that early-warning system.
4. Re-test the plugin after every WordPress and PHP upgrade, in the editor as well as the front end. Abandoned code breaks on your upgrades, not on its own.
5. Set a review date. “Indefinitely” is how a deliberate decision becomes an eight-year-old attack surface.

Point four is where most of the eventual pain lives. When an unmaintained plugin does break after a core upgrade, you have no vendor to ask, so you are isolating it yourself — troubleshooting a WordPress plugin conflict step by step is the method, and updating WordPress plugins safely covers the ordering that keeps the cause identifiable.

So should you renew?

• A form, checkout, upload or payment plugin on a public site: renew. This is the clearest yes on the page, and it is a security decision rather than a feature one.
• Anything service-backed: renew or replace now, on your schedule. Letting it lapse means the feature disappears on the vendor’s timetable, typically after a short grace period you will not remember.
• An agency or freelancer maintaining client sites: renew, and treat it as insurance on your own recovery ability rather than as a feature purchase. A key you cannot use to reinstall is a gap in every restore plan you have.
• Deep content lock-in and a working install: renew this cycle, then spend the year reducing the lock-in. Deciding under pressure after something breaks is how sites end up paying for both the renewal and the migration.
• An admin-only utility, no public input, stable site: reasonable to let it lapse. Archive the ZIP, document it, set a review date.
• A plugin whose job core or an existing plugin now does: do not renew, and do not keep it either. Removing it is the only option on this list that reduces your maintenance load — the plugins most sites genuinely need is a useful filter for that pass.

One practice is worth more than any of these individually: keep a plain list of every commercial plugin on the site, its vendor, its renewal date and who holds the account. The most common version of this problem I see is not an expensive renewal. It is a site running three paid plugins whose keys were bought on a former employee’s credit card, where nobody can renew anything because nobody can log in.

Frequently asked questions

Sources

• Detailed Plugin Guidelines — the GPL and GPL-compatible licensing requirement, and the rules on plugins that interface with external services
• WooCommerce FAQ and Auto-renewal, cancellation and refunds — what an expired extension subscription keeps and loses
• Gravity Forms: License Expiry — the download and new-site registration limits quoted above
• WP Rocket: what happens if my license expires — the 15-day cloud-feature cutoff
• Plugin header requirements — the Update URI and License headers
• wp plugin list and wp option list — the fields and search patterns used in the audit commands