

WordPress Notes: How to Use Them for Team Collaboration
Notes let your team leave feedback directly on blocks and text in the WordPress editor. Here is how to add, resolve and manage them, and who can see them.
You open a plugin’s page on WordPress.org and there it is, the yellow box: “This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”
The plugin still works. It might be running your contact form, the gallery on the homepage, or some feature nobody remembers setting up but everyone would notice if it disappeared. Nothing’s broken. But nobody’s maintaining it either, and the day something does break, there won’t be anyone to send a fix.
So how worried should you be? That depends on the plugin, mostly on what it touches and whether anyone has found a hole in it yet.
People use these three words as if they mean the same thing. They don’t:
| Status | What it means | How you notice it |
|---|---|---|
| Outdated | Not updated or tested with recent WordPress versions | An old “Last updated” date or the “not tested” warning |
| Abandoned | The developer has stopped maintaining it | No updates, unanswered support threads, an inactive developer website |
| Closed | Removed from the WordPress.org directory | A notice on the plugin page saying it has been closed and is not available for download |
The WordPress.org plugin handbook lists five reasons a plugin can be closed: author request, guideline violation, licensing or trademark violation, merged into core and security issue. You won’t always see the reason straight away, though. According to the handbook, it shows up 60 days after the closure.
When it does show up, it tells you how fast to move:
Developers don’t usually announce that they’ve abandoned a plugin. You have to piece it together from a few places, and where you look depends on where the plugin came from.
Any one of these on its own doesn’t prove much. Some small plugins do one job, do it well and barely need touching. When three or four of them line up, though, it’s fair to assume nobody’s home.
Bought the plugin from a marketplace or straight from the developer? Then WordPress.org won’t warn you about anything. Check the vendor’s changelog, whether your license still gets updates and whether the product page is still up.
With a long plugin list, checking each one by hand gets old fast. Security plugins like Wordfence can flag plugins that look abandoned or have been pulled from WordPress.org.
Sometimes. The longer a plugin goes without maintenance, though, the worse the odds get, and there are two reasons for that.
Patchstack’s State of WordPress Security in 2026 report found that 46% of vulnerabilities didn’t get a fix from the developer in time for public disclosure. That figure covers all plugins, including ones that are actively maintained. With an abandoned plugin, there may be nobody left to write the fix at all.
A WordPress or PHP update changes something the plugin relies on, and no update comes to patch it. The site can go from fine to broken after a routine update, and there’s nobody to ask.
| Plugin handles | Risk if abandoned |
|---|---|
| Forms, user input, file uploads | Higher |
| Logins, user accounts, memberships | Higher |
| Payments and checkout | Higher |
| Admin-only tools used by your team | Medium |
| Simple display features (icons, small widgets) | Lower |
Before you decide anything, look the plugin up in Patchstack, Wordfence or WPScan. If it has a known vulnerability and no fix, the decision is pretty much made for you.
For the bigger picture, see Is WordPress secure? What the data actually shows.


Most cases end up in one of these:
| Option | When it makes sense |
|---|---|
| Replace it with a maintained plugin | A well-maintained alternative does the same job |
| Use a built-in WordPress feature | The feature now exists in WordPress core |
| Switch to a fork or adopted version | Another developer has taken over the code and you trust them |
| Remove it completely | You no longer really need the plugin |
| Build a custom solution | The feature is specific to your business and no good alternative exists |
| Keep it for now, with monitoring | Low-risk plugin, no known vulnerabilities, replacement planned |
That last option should come with an expiry date. “We’ll deal with it later” has a way of turning into three years, and the plugin only gets older.
On paper, you deactivate one plugin and install another. In practice, old plugins leave things behind: settings, database tables, shortcodes scattered across pages and custom blocks.
This is the order we’d do it in:
A deactivated plugin doesn’t run inside WordPress, but its files are still on the server, and in some cases attackers can reach vulnerabilities through those files directly. That’s why most security guides tell you to delete plugins you don’t use rather than switch them off.


You can’t stop a developer from walking away. You can make it hurt less when they do:
| Check | Where |
|---|---|
| When was the plugin last updated? | WordPress.org page or “View details” |
| Which WordPress version was it tested with? | “Tested up to” on WordPress.org |
| Is there a warning or closure notice? | Top of the WordPress.org plugin page |
| Are support threads being answered? | WordPress.org support forum |
| Are there known vulnerabilities? | Patchstack, Wordfence or WPScan |
| What does the plugin handle? | Forms, logins and payments mean higher risk |
Check the last update date, the “Tested up to” version and the support forum. If WordPress.org says it hasn’t been tested with the last 3 major releases and nobody answers support threads, it’s most likely abandoned.
The developer hasn’t confirmed it works with your WordPress version. It may work fine, but it’s a good reason to check when the plugin was last updated.
Not always, and the risk usually grows over time. Watch plugins that handle forms, logins or payments most closely, especially if they have known vulnerabilities.
You can’t download it from the directory anymore, and sites that already use it stop getting updates through WordPress.org. If it was closed for a security issue, plan to replace it as soon as you can.
Usually not noticeably. A deactivated plugin’s code doesn’t run, but some plugins leave settings in the database that WordPress still loads on every page. That’s one more reason to delete plugins you don’t use.
In most cases, yes. A deactivated plugin doesn’t run, but its files stay on the server. Fewer leftover files means fewer things someone could exploit.
Abandoned plugins rarely cause trouble on the day they’re abandoned. The trouble tends to come months later, right after a WordPress update or a vulnerability report, and usually when you’re busy with something else. If you catch it early, you get to choose when to replace it.
Don’t feel like going through your plugin list yourself? Send it to us. As part of WordPress maintenance, the 24WP team will tell you what to keep, what to replace and what to delete.
Your 24wp website is developed by experts from Cubes — an IT company that has been creating complex IT ecosystems and stable web systems for a decade.
Visit cubes.rs