Why WordPress.org no longer accepts code-snippet plugins, and what we did instead

22 October 2026 · Antony

When I finished the first version of Snipfire, I did what every WordPress plugin author does: I zipped it up and got ready to submit it to the WordPress.org plugin directory. Then I read the Plugin Developer FAQ properly, and that plan was over before it started.

This post explains what the rule says, why it makes sense, what it means for you if you use or need a snippet plugin, and how I ship Snipfire instead. Most of it is useful even if you never install Snipfire.

What the rule actually says

The rule isn’t in the numbered plugin guidelines. It’s in the Plugin Developer FAQ on developer.wordpress.org, and as of October 2026 it reads:

“We do not accept new plugins that allow arbitrary code insertion or execution. Examples include PHP or JavaScript editors, file managers, and AI tools that generate code intended to be executed on the site.”

The same answer adds that HTML output is still fine, “provided it is properly escaped and handled securely”.

Three things are worth noticing:

It’s about new plugins. WPCode (3+ million active installs) and Code Snippets (1+ million) are still listed and still updated, as of October 2026. If you already use one of them, nothing changes for you.
It’s broad. It covers PHP and JavaScript editors, file managers, and AI tools that write code which then runs on the site. Snippet plugins are the obvious case, but not the only one.
It’s a review rule, not a technical one. You can still install any GPL plugin you like from anywhere. The directory just won’t host new ones in this category.

Why the rule makes sense

The FAQ doesn’t spell out the reasoning, so this is my reading, as someone who builds one of these plugins.

A snippet plugin is, by design, a way to run code on a server through a web page. That’s the whole point, and it’s also the biggest risk in the plugin. If a snippet plugin has a permissions bug, an attacker doesn’t need to find a clever exploit: the plugin itself is the “run my code” button. That’s why vulnerabilities in this kind of feature tend to be rated critical: the damage is total.

The review team checks thousands of submissions with a small team. Reviewing a plugin whose job is to execute code safely is much harder than reviewing a contact form. Closing the category to new entries is a sensible trade-off for them, even if it’s a nuisance for people like me.

What it means for you

If you need a snippet plugin today, you have three honest options:

An established one from WordPress.org. WPCode, Code Snippets and others are still there and still maintained. Directory listing gives you automatic updates and the WordPress.org review history.
No plugin at all. Put your code in a must-use plugin (below). It’s the simplest, fastest option, and nothing can switch it off by accident.
A plugin from its author’s own site. That’s where any new snippet plugin has to live now, including mine. It can be perfectly fine, but you should check a few things first (see the checklist).

The no-plugin way: a must-use plugin

Create the folder wp-content/mu-plugins/ if it doesn’t exist, and add a file such as site-tweaks.php:

<?php
/**
 * Plugin Name: Site tweaks
 * Description: Small custom code for this site. Loaded automatically, can't be deactivated from the admin.
 * Requires PHP: 8.1
 */

defined( 'ABSPATH' ) || exit;

// Turn off XML-RPC if nothing on the site uses it (Jetpack and some mobile apps do).
add_filter( 'xmlrpc_enabled', '__return_false' );

// Replace "Thank you for creating with WordPress" in the admin footer.
add_filter(
	'admin_footer_text',
	static function ( string $text ): string {
		return esc_html__( 'Site built and maintained by Example Studio.', 'site-tweaks' );
	}
);

WordPress loads every PHP file in that folder on every request, before normal plugins, with no switch to turn it off. It’s also visible under Plugins → Must-Use.

The honest downside: there’s no safety net. A typo or a function name that already exists (Cannot redeclare…) gives you a white screen, and the only way back is FTP or your host’s file manager. Always test on a staging copy first, keep a backup of the file, and use closures (as above) instead of named functions, so two snippets can’t clash.

A checklist for plugins that aren’t on WordPress.org

This applies to any plugin you download from an author’s site, not just snippet plugins:

Who makes it? A real name, a company, an address, a way to reach them. Anonymous plugins that run code on your server are a hard no.
Is the code readable? WordPress plugins are GPL. Open the zip and look. Obfuscated or encoded PHP in a free plugin is a red flag.
Does the file match what the author published? If the author lists a checksum, compare it:

# macOS
shasum -a 256 plugin.zip
# Linux
sha256sum plugin.zip
# Windows (PowerShell)
Get-FileHash .\plugin.zip -Algorithm SHA256

Note that wp plugin verify-checksums only knows about plugins hosted on WordPress.org, so it can’t check these for you.

How does it update? Updates from outside WordPress.org need their own update checker. Find out what it sends home and how it makes sure an update really comes from the author.
What does it send home? Read the privacy section or the About page. If the answer isn’t written down, ask.
Is there a changelog and a security contact? Regular, specific changelog entries and a published way to report vulnerabilities tell you someone is looking after it.
Try it somewhere safe first. A staging site, a local install, or a WordPress Playground demo in your browser.

What we did with Snipfire

We split it in two.

Snipfire Tweaks is on WordPress.org. It’s the part of our snippet library that doesn’t need you to write code: 71 ready-made changes as on/off switches (turn off XML-RPC, stop user-name listing, drop the emoji script, WooCommerce minimum order, and so on). No code editor, no user code, no outside requests, so it fits the rules. It went live on 1 October 2026 after review, and you can read every tweak’s code on our Tweaks page before you install it.

Snipfire itself, the editor, is free from snipfirewp.com. I’ve tried to answer every point in the checklist above on the site itself:

The Download page lists the SHA-256 checksum of every release.
From 0.17.0, every release is signed. Snipfire checks the signature before it installs an update and refuses one that doesn’t match, so even someone who took over our website couldn’t push code to your site. Updates otherwise appear under Dashboard → Updates like any other plugin.
It’s GPL, with no account, email address or licence key needed for the free version.
There’s a security page for reporting problems, and a public changelog.
You can try it in your browser first with the live demo, which runs WordPress Playground and nothing on our server.

And because a snippet plugin is the riskiest kind of plugin, the safety features are the core of it: code is syntax-checked before it’s saved, Snipfire warns before you redeclare a function that already exists, it test-loads your site when you switch a snippet on, and a snippet that causes a fatal error later is switched off automatically, with the exact line shown. Safe mode gets you back in if all else fails.

If you’re on WPCode, Code Snippets or another snippet plugin and happy with it, stay. If you’d like to try Snipfire, it imports your snippets switched off, so nothing on your site changes until you say so.

The short version

WordPress.org doesn’t accept new plugins that let you run arbitrary code. Existing ones stay.
For a handful of snippets, a must-use plugin is a fine, free answer. Test first.
For any plugin from outside WordPress.org: check who makes it, read the code, compare the checksum, and know how it updates.
Snipfire Tweaks is on WordPress.org; the Snipfire editor comes from snipfirewp.com, signed.

Questions, or think I’ve got the rule wrong? Get in touch. I read everything.

Antony, maker of Snipfire