I build most of my WordPress plugins for sites I run, then make them generic enough for anyone. Over the last few weeks I have been preparing several for WordPress.org review. Taggy was approved and released. Ace Crawl Enhancer, my SEO and crawl plugin, has been submitted. The cache, image and carousel plugins are being prepared in turn.
Each one changed more than I expected. Code that is fine on a site I control has to be safe on a site I will never see.
WordPress.org review: one plugin at a time
The first practical lesson: WordPress.org allows only one plugin awaiting its first review per account. You cannot submit the next until the current one is approved. When I submitted, the queue held a few hundred plugins, with reviews taking from a day to over a week. Plan the order, and put the plugin you are most confident in first.
Protected content must not leak through metadata
An SEO plugin writes titles, descriptions and structured data into every page. On a site with password-protected or private posts, that metadata can reveal what the content is protecting. Ace Crawl Enhancer now keeps protected content out of public metadata entirely. The cache plugin received the same treatment: protected responses are never stored in a shared page cache, where the next visitor could be served them.
Check the permission that actually applies
Saving SEO fields for a category or tag checked a general editing capability. The reviewer's question was whether that is the right permission for that taxonomy. It now checks the taxonomy's own capability before saving. Similar fixes went in for REST routes and AJAX handlers, each checking what that specific request is allowed to do.
Explain every outside connection
Several of my plugins can optionally use an AI model or a Google service. For the directory, each optional connection is explained before it is switched on: what is sent, where, and why. AI features stay off until someone chooses them, and they stay off if an old sign-in is polled after it has been disconnected. New text features prefer the WordPress AI Client where it is available, so a site's chosen model is used consistently.
Uploads and images
The image plugin converts and edits images, including SVGs. Preparing it for release meant:
- hardening SVG uploads, because an SVG is a document that can carry scripts;
- preparing an edit completely before replacing the original, so a failure leaves the original untouched;
- keeping the original if a replacement cannot be finished;
- supporting shared upload folders, as used by many deployment tools, without trusting symlinks nested inside them;
- keeping avatar discovery read-only;
- testing that unauthorised image requests are refused.
Behave like a WordPress plugin
A lot of the review feedback was about fitting in. Load scripts and styles through WordPress rather than printing them directly. Keep admin notices inside the plugin's own screens. Make informational notices dismissible. Keep "Tested up to" in readme.txt only. Remove anything specific to my own sites, such as sitemap styling that assumed my branding. Make activation opt in to anything with side effects, such as enabling a page cache.
Upgrades must keep what is there
For the cache plugin, upgrades now preserve the installed cache state and legacy settings during version-only updates, and refresh the drop-in files it owns without touching anyone else's. Invalidation and drop-in updates are scoped to the site doing them, which matters on multisite and shared Redis.
Why it is worth doing
Every one of these changes made the plugins safer on my own sites too. The review is a structured second opinion from people who have seen thousands of plugins fail in the same ways. If you build plugins for clients, preparing one for the directory is a good way to find out what you have been getting away with.
I wrote more generally about contributing to WordPress and building better plugins.