I typed "zero blocks given" into Plugins › Add New and my own plugin wasn't the first result. It's called Zero Blocks Given. Nothing else on wordpress.org is called that. The search matched keywords and put something else above the exact name, which is the sort of small thing that stops being small once you've noticed it.
So the thought was: is it possible to fix that screen, so the search actually works by name and not by keyword? WordPress is filterable nearly everywhere, so I figured there'd be a hook that would let me re-rank my own results.
There is. It's called plugins_api_result, and it lives in wp-admin/includes/plugin-install.php. When you open Add New, WordPress asks the wordpress.org API for a list of plugins. Before that list reaches your screen, core hands it to this filter, and any active plugin on your site gets to edit it - reorder it, add to it, remove from it. There's no capability check on the filter itself - it fires wherever core calls it. The plugin already runs as your site.
That was the fix I wanted. Then a second thought arrived: if this hook lets me reorder the list, it lets anything already installed on the site do the same, and I had no idea whether anything did.
So I looked
I scanned every free plugin and theme on WordPress.org - 63,619 plugins and roughly 13,000 themes - for code that touches the Add New screen.
One caveat before any of this means anything. The wp.org directory is the slice of the ecosystem that goes through human review and has the strongest incentive to behave. Whatever I found there is a floor. Commercial builds, marketplace themes, nulled copies, anything fetched after install - I couldn't see any of it, so I claim nothing about it. This is not a prevalence rate for WordPress.
2,385 plugins register one of those hooks, and no themes at all. Most of what came back was routine. Licence updaters answering for their own slug, plugins adding their own tab, vendors putting their own products on top of the list while leaving everything wp.org sent underneath. Self-promotion, in the open, harming nobody. The themes came back clean on every axis I checked, and they stay out of the rest of this piece for that reason. I expected the story to end there.
Two didn't fit that shape.
The one that deletes
Meta Box has 500,000 installs. Here is the entire file, meta-box/src/FeaturedPlugins.php, version 5.13.1:
class FeaturedPlugins {
public function __construct() {
add_filter( 'plugins_api_result', [ $this, 'process' ], 10, 2 );
}
public function process( $result, $action ) {
global $tab;
if ( ! in_array( $tab, [ 'featured', 'recommended' ], true ) ) {
return $result;
}
if ( is_wp_error( $result ) || $action !== 'query_plugins' ) {
return $result;
}
foreach ( $result->plugins as $index => $plugin ) {
if ( $plugin['slug'] === 'secure-custom-fields' ) {
unset( $result->plugins[ $index ] );
}
}
return $result;
}
}Open the Featured or Recommended tab on a site running Meta Box, and Secure Custom Fields - the ACF fork that wordpress.org itself publishes - is gone from the list. The scope is exactly what the code says and no more: those two tabs, not search. You can still search for SCF and install it. But on the tabs, it's removed, there's no setting to stop it, and the readme doesn't mention it.
Slim SEO, 70,000 installs (both counts as of 29 July 2026), ships the same file with the same logic, differing only in the namespace and how it's wired up. Same vendor - eLightUp. A missing list entry is invisible by definition. You don't get a gap where SCF should have been; you get a list that looks complete. You'd only catch it by comparing against a clean install, which nobody does.
The one that displaced Featured
The ThemeIsle SDK ships inside dozens of plugins as a composer dependency. Its Featured_plugins.php module did something I found more interesting than a deletion, in the version I pulled in late July (SDK 3.3.52):
$featured = $this->query_plugins_by_author( $args );
$plugins = array_merge( $featured, (array) $res->plugins );
$plugins = array_slice( $plugins, 0, $res->info['results'] );
$res->plugins = $plugins;Merge your own plugins to the front of the Featured tab, then slice the list back to its original length. The count never changes, so nothing looks wrong from the outside - but for every plugin inserted at the top, one genuine wp.org featured plugin drops off the bottom. Up to three, silently. The inserted slugs were fixed in the code: optimole-wp, otter-blocks, wp-cloudflare-page-cache.
Two things in ThemeIsle's favour, because they're true. The module bails unless the current user can install plugins, so it never touches a subscriber or an editor. And themeisle_sdk_disable_featured_plugins is a real off switch - a code filter rather than a checkbox, so a site owner won't find it, but it exists, and I didn't find an equivalent in anything else I read for this.
Then the second layer, which was the part you'd never catch from the screen. The module is gated on a self-declared header. Product.php:
$this->wordpress_available = ( 'yes' === $file_headers['WordPress Available'] ) ? true : false;If a plugin declares WordPress Available: yes, the module stays dormant - the SDK treats free wp.org builds as exempt. But if the header is missing entirely, that comparison is false, can_load() doesn't bail, and the module runs. Seven ThemeIsle plugins - the old Webcraftic / Clearfy ones, acquired and republished under the Themeisle account - never carried that header, so the module ran in their free builds. Roughly 259,000 installs between them, as of 29 July 2026. It read like an acquisition oversight rather than a decision, and that's how I planned to write it. All 11 ThemeIsle themes carrying the SDK declared the header and had the module dormant. I have no Pro builds and no licences, so I claim nothing about what those execute.
Is any of this against the rules?
I couldn't find a guideline that named this behaviour, so I asked the plugin review team in the Make WordPress Slack, in #pluginreview, whether the handbook should say something about rewriting installer results. A reviewer, frantorres, answered that I had the question backwards:
Regarding this, the guidelines cannot be a collection of every single detail that could be wrong, it would be endless and still never accurate, it is already quite long actually.
The guideline 9 says: 9. Developers and their plugins must not do anything illegal, dishonest, or morally offensive.
Removing results from the search without telling anyone about it sounds dishonest.
The guideline 11: 11. Plugins should not hijack the admin dashboard.
Removing elements from the dashboard (when it is not something intended by a feature of the plugin that the user is aware of and which makes sense for that feature) sounds like hijacking the admin dashboard.
So the rules already cover it. But neither guideline names it. Guideline 9's list is prefaced with "includes (but is not restricted to)", and its first entry is artificially manipulating search results "via keyword stuffing, black hat SEO, or otherwise". Read closely, that "or otherwise" already reaches this. But the examples around it point at wordpress.org's own surfaces - fake reviews, sockpuppet accounts, keyword stuffing in readmes - not at the installer inside your admin. Guideline 11's text is about nags, notices and dashboard widgets. Editing the installer results inside a user's own admin appears in neither list, and I think that explains how the pattern spread: a clause broad enough to cover it that nobody ever pointed at it, so everyone shipped. Notice where the emphasis falls in both of the reviewer's readings - on without telling anyone. The suggestion I made in that thread was small: add this behaviour to the examples under guideline 9, so the clause teaches by example the way it already does for fake reviews.
That's one reviewer answering in a public channel, and I'm reporting it as that. I also emailed [email protected] with the same question, the list of plugins, and the code. The answer came on 7 August:
Silently removing third-party plugins from the results displayed by the WordPress plugin installer fall under Guideline 9's prohibition on artificially manipulating search results (there are examples, but it covers anything dishonest) and also under guideline 11 of hijacking the admin dashboard (that's not just for notices)
For this cases, users can get in touch with the plugin author (for example in the forums) and if they do not respond to that, users can get in touch with us so we can check it.
Thank you for reporting a guideline violation in this plugins. We're looking into it right now.
Both parentheticals are doing the work, and both answer the objection I'd just made. The enumerated examples under guideline 9 aren't the boundary of it - "it covers anything dishonest." And guideline 11 is "not just for notices," which is the reading I'd assumed was unavailable. So the answer to the question in this heading is yes, from the team that enforces it, on both counts.
The same email says they work case by case, weighing the developer's history, and that responses range from a warning to closing a plugin outright. It also says most reports get no further communication, simply because of the volume, so I wrote that I might never learn how this one ended.
I found out anyway, and not from them. See below.
I told them first
At this point I could have published. Instead I emailed both vendors - eLightUp on 28 July, ThemeIsle the same day - with what I found, the exact code, the questions I had, and the date I planned to publish. I'd rather print a vendor's reason than my guess, and if I'd read something wrong I wanted the chance to fix it before it went out rather than after.
One of them fixed it
The ThemeIsle side is best told by the clock.
- 28 July, 15:22 GMT - I sent the email.
- 29 July, 08:50 GMT - all seven plugins were updated on wordpress.org, carrying SDK 3.3.58.
- 29 July, 15:14 GMT - Ionut Neagu's reply arrived, about six hours after the fix was already live.
I didn't take the email's word for it. I downloaded the shipped zips from wordpress.org the same day: disable-admin-notices 1.4.7, remove-category-url 1.2.4, cyrlitera 1.3.6, cyr-and-lat 1.3.5, instagram-slider-widget 2.3.5, webcraftic-updates-manager 1.3.3, comments-plus 1.3.3. Every one now declares WordPress Available: yes in its main file, which means the module no longer runs in any ThemeIsle free build.
And they fixed more than the header. One of my three questions had been why the list gets sliced back to its original length instead of lengthened - lengthening would insert their plugins without displacing anyone. In 3.3.58 the array_slice is gone:
$featured = $this->query_plugins_by_author( $args );
$original_count = count( (array) $res->plugins );
$plugins = $this->remove_plugins_by_slug( (array) $res->plugins, $this->get_plugin_slugs( $featured ) );
$res->plugins = array_merge( $featured, $plugins );
return $this->adjust_results_count( $res, count( $res->plugins ) - $original_count );The list now lengthens, duplicates get removed, and the result count is raised by the difference so pagination stays honest. Nothing falls off the bottom anymore. They'd answered my question in code before answering it in prose. Neagu confirmed the gate reading was correct, called the missing header an oversight from the acquisition integrations, and asked that the corrections make it into the published piece. They have. With the header restored the module doesn't run in the free builds at all, so on wordpress.org there's now nothing on the Featured tab to see. What ships in the Pro builds I can't tell you - I have no licences and haven't looked. The displacement and the accidental free-build loading, the two things I flagged, were both gone within seventeen and a half hours of the email.
The other one didn't
Anh Tran, founder of eLightUp, replied the same day I wrote to him. His answer, in full and unedited:
What you found is correct. Meta Box and Slim SEO include the same code that removes Secure Custom Fields (SCF) from the Featured and Recommended tabs in the WordPress plugin installer, and there is currently no UI setting or mention of it in our readmes.
The reason is straightforward: we believe SCF is an unusual case in the WordPress ecosystem. While WordPress' licensing allows forking, SCF was created by taking the commercial version of Advanced Custom Fields rather than the free version available on wordpress.org. Many people in the community have expressed concerns about whether wordpress.org should be distributing a fork of a premium product under those circumstances.
Meta Box operates in the custom fields space, so SCF is naturally a direct competitor to us. However, our decision wasn't based solely on competition. If a third party—not WordPress.org or Automattic—had taken a premium plugin, renamed it, and redistributed it publicly, we believe the community reaction would likely have been very different.
We understand that reasonable people can disagree on this topic. Some see it as an acceptable use of the GPL; others see it as crossing an ethical line despite being legally permissible. We fall into the latter camp.
We're not attempting to prevent users from installing or using SCF. The code only removes it from the Featured and Recommended lists shown within our plugins. Users can still search for it directly, install it manually, and make their own choice.
I'm not going to rule on the SCF question. Whether wordpress.org should distribute a fork of a commercial plugin is a real disagreement that predates this post, people I respect land on both sides of it, and it isn't what I measured. He answered a courtesy email honestly and openly within hours, and that counts for something.
The facts as of 29 July: the code ships in meta-box 5.13.1 and slim-seo 4.9.11, roughly 570,000 installs combined, and removes one named competitor from two tabs. There's no setting and no readme line. He keeps it because he treats SCF as an ethical edge case rather than an ordinary competitor, and he said so plainly when I asked.
Then they were told to remove it
On 10 August, Anh Tran emailed again:
We've now heard back from the WordPress.org plugins team. They've asked us to remove this behavior from both Meta Box and Slim SEO, and we'll be complying with that request. The changes will be included in our upcoming releases.
I thought it was worth letting you know, as this changes the current status. While the broader discussion around disclosure and user choice is still relevant, readers should also know that this behavior is already being removed following guidance from the plugins team.
So the report I sent on 28 July did land. The plugins team told me on 7 August that they were looking into it, and by 10 August they had asked the vendor to remove it and the vendor had agreed. That is quick, on a thing that had been shipping unremarked for months.
He asked that readers know the behaviour is already being removed, and it's a fair request, so here it is up front. One qualifier, because "already" is doing a lot of work: it's announced, not shipped. I checked the current releases this morning, on 10 August. src/FeaturedPlugins.php is still in meta-box 5.14.0 and in slim-seo 4.9.11, and it still unsets secure-custom-fields on both tabs. Nothing has been removed yet. It's coming in releases that haven't happened. If you're reading this later, check the current versions rather than trusting that sentence.
Two smaller things changed while I was writing, both in meta-box 5.14.0 on 30 July. The two files are no longer byte for byte identical, and meta-box now wraps the removal in a filter, rwmb_modify_plugin_recommendations, so another developer can switch it off in code. Slim SEO has no such filter. That is a real change from what I described above, and it's worth being exact about what it is: a hook for developers, not a setting a user can find, and still nothing in either readme.
Where that leaves it
Same hook, same screen, same email sent the same day with the same notice. One vendor shipped a fix before his reply reached me. The other wrote back within hours, explained why he treats SCF as a case apart, and kept the code - and then agreed to remove it after wordpress.org asked him to. Both engaged from the first email. One corrected itself before I could publish; the other was asked to by wordpress.org and agreed. Those are not the same route, and the second one hasn't shipped yet.
Worth separating the two things that happened there. eLightUp's reasoning about SCF hasn't changed, and that disagreement is a real one that long predates this post. What the plugins team ruled on was the behaviour, not the opinion behind it: removing a competitor from the installer silently, which they read as covered by guidelines 9 and 11. What changed is that the plugins team read guidelines 9 and 11 as covering the behaviour, and that reading settled it. A reviewer in a public channel got there first, reading the same handbook.
I don't think that gap is an accident. Nothing in either guideline names this behaviour exactly. Guideline 9's examples are all about wordpress.org itself, guideline 11 reads like it's about notices, and a developer checking whether the rules cover editing installer results would have found nothing pointed at it. So the code shipped, in two plugins, for months, until someone asked out loud. The rule was always there. But it is generic and broad so the wording left room for interpretation ( by both the authors and reviewers ).
The "Add New" screen still works the way it did when I started. WordPress asks the directory for a list, and everything already installed gets to edit the answer before you see it with a filter. But nearly no-one does.