You have decided to update to WordPress 7.0. Good. The question now is not whether to update, it is whether your plugins are ready for it.
Here is the thing about a major version like 7.0. WordPress core itself is tested hard and rarely the problem. Your plugins are. A major release changes how WordPress works underneath, and any plugin that was leaning on the old way can break the moment you upgrade. The more plugins you run, the higher the odds that one of them is not ready yet.
So this is a WordPress 7.0 plugin compatibility checklist, not a should-I-update piece. If you want the full update walkthrough, the backup-staging-go-live process, read our WordPress 7.0 update guide. This page is the part that sits just before that: how to check whether your specific plugins are compatible with WordPress 7.0, which ones are most likely to break, and how to prove it before you touch the update button.
Why Plugins Are the Real Risk in WordPress 7.0
7.0 is the biggest core release in years, and a few of its changes hit exactly the parts of WordPress that plugins hook into. That is what makes this version worth a proper plugin check rather than a quick glance.
Three changes in 7.0 are the ones that actually break plugins:
- The admin list screens changed. The classic Posts, Pages, Media, and Users list tables have been replaced with a faster interface called DataViews. Any plugin that added its own columns, filters, or bulk actions to those old screens has to be updated to work with the new system. This is one of the highest-risk areas in the whole release, because a lot of plugins touch those screens.
- Classic meta boxes are on notice. Plugins that still add their settings through the old meta box method can disable newer editor features for that post in 7.0. Plugins built the modern way are fine. Older ones that never moved on are the ones to watch.
- The minimum PHP version is now 7.4. WordPress 7.0 will not run on PHP 7.2 or 7.3. If your host is still on one of those, you cannot even install 7.0 until PHP is updated, and some older plugins have their own PHP version assumptions on top of that.
None of this means 7.0 is dangerous. It means a plugin written years ago and never updated is far more likely to trip on this release than on a routine minor update. The fix is not to avoid 7.0. It is to check your plugins first, which is what the rest of this page walks through.
The WordPress 7.0 Plugin Compatibility Checklist
Work through these in order. The early steps clear out most of the risk for free, and the last one is the only real proof.
1. List every plugin you actually run
Open your Plugins screen and write down what is active. Note two things for each one: when it was last updated, and whether it is still actively maintained. A plugin that had an update this month is in good shape. A plugin whose last update was two years ago is your first yellow flag, whatever it does.
While you are there, deactivate and delete anything you are not using. Every plugin you remove is one less thing that can break on update day, and fewer plugins is the simplest compatibility win there is.
2. Check each plugin’s tested-up-to version
On a plugin’s page in the WordPress plugin directory, look for the “Tested up to” value and the last-updated date. If an author has tested their plugin up to 7.0, they are telling you they have done the work. If it still says 6.8 or older and has not been touched in a long time, treat that as a plugin to test carefully or replace.
For premium plugins that do not live in the directory, check the developer’s site or changelog for a 7.0 compatibility note. Reputable authors announce it.
3. Update every plugin to its latest version first
Do this while you are still on your current WordPress version, before you touch core. Plugin authors ship their 7.0 compatibility inside their own updates, so getting everything current is the single biggest thing you can do to clear risk before the upgrade. A lot of “the update broke my site” stories are really “I updated core but left the plugins on last year’s versions.”
4. Flag the high-risk plugin types
Some kinds of plugin are more exposed to 7.0’s specific changes. Give these a closer look:
- Anything that adds columns, filters, or bulk actions to your Posts, Pages, Media, or Users screens. These are the most likely to be affected by the move to DataViews.
- Page builders and plugins that extend the block editor. They sit close to the parts of WordPress that changed most, so confirm the author has shipped a 7.0-ready version.
- Plugins with their own AI features. 7.0 introduces a built-in AI client, and plugins that rolled their own integration may need to update to fit the new approach.
- Older plugins that use classic meta boxes for their settings, since those can switch off newer editor features for a post.
- Anything abandoned. If a plugin has no recent updates and no sign of 7.0 support, it is the most likely thing on your site to break. Plan to replace it with a maintained alternative.
5. Confirm your PHP version is 7.4 or higher
WordPress 7.0 requires PHP 7.4 as a minimum, and 8.3 or newer is the recommended target. Most hosts show your current PHP version in the dashboard. On a managed host this is handled for you. If you are on PHP 7.2 or 7.3, sort that out before anything else, because 7.0 will not install until you do.
6. Test the update on a staging copy
This is the step that turns the whole checklist from guesswork into proof. A staging site is a private copy of your live site that visitors never see. Run the 7.0 update there, then click through the site the way a visitor would: load your key pages, submit a contact form, log in, and if you run a store, put something through the cart and checkout. If a plugin is going to break, it breaks on the copy, with nobody affected and no pressure on you.
If everything works on staging, you have your answer: your plugins are compatible, and you can update live with confidence. If something breaks, you found it safely, and you can fix it or wait for the plugin author to ship a fix before going anywhere near production.
7. Keep a rollback ready
Before the live update, take a full backup of the site, files and database both, and keep it off the server. If anything slips through, restoring that backup puts the site back to its working state in minutes. A checklist plus a backup is the difference between a calm update and a bad afternoon.
How Long Does a Plugin Check Take?
For a small site with a handful of well-maintained plugins, the checklist above is maybe twenty minutes plus a staging test. For a larger site, a store, or a site with a long plugin list built up over years, it is more, mostly because there is more to click through and more chance that one old plugin needs replacing. Either way it is far less time than cleaning up a broken live site after an update you did not test.
WordPress 7.0 Plugin Compatibility FAQ
How do I check if my plugins are compatible with WordPress 7.0?
Start with the plugin directory. For each plugin, check the “Tested up to” version and the last-updated date. If it says 7.0, the author has done the work. Update every plugin to its latest version while still on your current WordPress version, since authors ship 7.0 compatibility inside their updates. Then run the 7.0 update on a staging copy and click through your site. Staging is the only way to be certain, because it shows you exactly how your specific mix of plugins behaves on 7.0.
Which plugins are most likely to break in WordPress 7.0?
The highest-risk ones are plugins that add columns, filters, or bulk actions to the Posts, Pages, Media, or Users screens, because those screens moved to a new system called DataViews. Page builders and plugins that extend the block editor, plugins with their own AI features, and older plugins that use classic meta boxes are also worth a close look. Above all, any plugin that has not been updated in a long time is the most likely thing on your site to break.
Can I update to WordPress 7.0 if a plugin is not compatible yet?
You can, but you should not until you have tested it. If a key plugin has not shipped 7.0 support, the safe move is to wait for the author to update it, or switch to a maintained alternative, and confirm the result on a staging copy before updating your live site. Updating live with a known-incompatible plugin is how contact forms go quiet and checkouts start throwing errors.
Do I need to update plugins before or after updating WordPress 7.0?
Before. Update all your plugins to their latest versions first, while you are still on your current WordPress version. That is where authors deliver their 7.0 compatibility, so doing it first clears out most of the risk before core changes underneath them.
Or Let Forge Check Compatibility For You
Everything above is doable yourself. It also takes a plugin-by-plugin audit, a staging environment, a careful read of changelogs, and the patience to click through your whole site on a copy before you commit. On update day for a release as big as 7.0, that is real work.
Forge is managed WordPress hosting, which means this is our job, not yours. Our approach to a major update is to test it on a copy of your site before it ever touches production. With managed updates we run that process for you: we update on staging, check your plugins behave, and only then push live. If a plugin is not ready for 7.0 yet, we catch it on the copy, not on your live store. And because we keep proactive monitoring on your site around the clock, if anything does go wrong after an update, we tend to know about it before you do.
Your site also runs on its own dedicated server, never shared with other customers, so a neighbour’s bad update can never knock your site over. Forge pricing is flat: $39 to $209 a month depending on plan, with everything included and no renewal increase. Every plan also comes with a free migration we run end to end, so moving to managed hosting is not its own project.
When you are ready for the full walkthrough, our WordPress 7.0 update guide covers the backup, staging, and go-live steps in order. And if you would rather not run the next major update yourself at all, that is exactly what managed hosting is for.
See managed WordPress hosting plans