Publishing to the Plugin Directory

A directory plugin has a public page at https://wordpress.org/plugins/<slug>/ built from its readme.txt, its main file header and the images in its assets folder. Its code lives in a Subversion (SVN) repository at https://plugins.svn.wordpress.org/<slug>/, which the Plugin Handbook calls a release repository: every commit regenerates the downloadable zips, so development stays in Git and only finished releases reach SVN. Approved plugins also get a support forum and a project on translate.wordpress.org, from which sites receive language packs (see Internationalization).

The directory is optional: in-house plugins such as Lumen Press’s own lumen-catalog install from a zip, Composer or Git and update from a private server (see Updates outside the directory).

Every plugin, every committer and everyone who officially supports a plugin is bound by the eighteen Detailed Plugin Guidelines, plus the community and forum guidelines. Violations can close a plugin; repeated ones can ban the developer. The guidelines in short, in the order the handbook numbers them:

Source: Plugin Handbook: Detailed Plugin Guidelines

The "Common issues" page lists what reviews flag most: unescaped output, unsanitised input and missing nonces (see Security for Developers), direct file access, missing prefixes, curl instead of the HTTP API, inline scripts instead of wp_enqueue_script(), variables as text domains, plugins that (de)activate other plugins, update checkers, undocumented services and development folders in the zip. Block Directory plugins also follow the Block Specific Plugin Guidelines (one top-level block, minimal PHP, no admin screens); blocks are covered from Block Development Environment onwards.

For lumen-catalog the guidelines change three things: the Update URI header pointing at Lumen Press’s server goes (guideline 8); the optional stock synchronisation stays off until enabled and the readme documents what it sends and the service’s terms (6 and 7; see also Privacy and Personal Data); and the release keeps composer.json beside vendor/ (4).

The slug is derived from Plugin Name in the main file when the zip is uploaded (Lumen Catalog becomes lumen-catalog); an existing slug gets a -2 suffix. It becomes the page URL, the SVN path, the folder name on every site and the text domain. It can be changed once from the submission page before the review starts, by the Plugins Team until approval, and never afterwards; the display name can change at any time. Slugs may not contain "wordpress" or "plugin", version numbers or vulgarities, and use only English letters and digits.

Because updates match plugins by folder name, a slug already used outside WordPress.org by many sites is refused; for a plugin first released privately, as lumen-catalog was, the Plugins Team asks to be emailed.

The directory page comes from readme.txt, a text file in a dialect of Markdown with === Plugin name ===, == Section == and = Subsection = headings. lumen-catalog ships this one:

Source: Plugin Handbook: Plugin Readmes

Page images go in the top-level assets folder of the SVN repository, beside trunk (never inside it, so they are not shipped to sites). They are served through a cached CDN; changes can take up to six hours to appear.

The size in a file name is the size the image must have; other names and sizes are ignored. Images must not use someone else’s logo. In Git, lumen-catalog keeps them in .wordpress-org/, the folder the deploy action below copies to assets.

Images committed with the wrong MIME type download instead of displaying; svn propset svn:mime-type image/png fixes them (see the SVN example below). Setting image/svg+xml on icon.svg makes Subversion 1.14 warn that the file looks like text, so the handbook only sets PNG and JPEG types.

Plugin Check (PCP) runs the automated part of the review: a submission must pass its Plugin repo checks, and other categories cover security, performance, accessibility and best practice. It adds Tools > Plugin Check and wp plugin check; 2.1.0 (August 2026) adds a Tools > Plugin Check SVN screen for stray files in the SVN repository and optional AI features on WordPress 7.0+. Passing it does not guarantee approval.

The release is one folder named after the slug with runtime files only: PHP, built assets, vendor/ from composer install --no-dev --optimize-autoloader, languages/, readme.txt and the build configuration guideline 4 asks for; no tests, CI files, node_modules/ or hidden files. A submission zip may be up to 10 MB.

Official estimates differ: one to ten days on the submission page, 14 business days on the planning page, replies within ten business days in the FAQ. An unfinished review is rejected after three months (resumable by replying); queue jumping is only for security or legal reasons.

Source: Plugin Handbook: Using Subversion

The rules: the main file sits directly in trunk/ (a trunk/lumen-catalog/ subfolder breaks downloads); branches/ is no longer created and the directory ignores it; tags look like version numbers (0.1.0, not "first release"); no zip files and no svn:externals; nothing goes into SVN that should not reach every site. The SVN username is the case-sensitive WordPress.org username, and the password is a separate SVN password set in the account settings.

Teams that develop in Git usually let CI do the SVN steps. The 10up WordPress.org Plugin Deploy action is a widely used community option, not a WordPress.org product: it commits a Git tag to trunk/ and tags/<version>/ and copies .wordpress-org/ to assets/. The lumen-catalog workflow builds the release folder, checks it with Plugin Check, and deploys it:

Source: GitHub: 10up/action-wordpress-plugin-deploy

The workflow passed actionlint; the build step’s rsync and the version check were run locally and produced the same file list as wp dist-archive. It was not run against WordPress.org. Notes:

Version, Stable tag and the Git tag must agree; the grep step stops a release where they do not.

Plugins outside the directory declare their update source with the Update URI header (5.8) and the update_plugins_{$hostname} filter, shown with Lumen Press’s update server in Plugin Fundamentals: Update URI and private updates. For the directory:

Committers are managed on the plugin’s Advanced tab (also the fix for a plugin submitted from the wrong account); support happens in its forum. The Plugins Team can close a plugin over a security report and, in extreme cases, patch it. Authors close their own plugins on the Advanced tab below 10,000 users; closure is permanent, stops downloads, keeps SVN readable and shows a broad reason after 60 days. Plugins with no commit six months after approval may be closed.

The older books (WordPress All-in-One For Dummies, Pro WordPress, Ultimate WordPress Handbook) cover installing directory plugins but not publishing one: no readme.txt, Plugin Check, SVN or review. One of them states that plugins cannot depend on other plugins; since 6.5 Requires Plugins declares dependencies by WordPress.org slug, and Plugin Check 2.1.0 validates each slug against the directory. Release confirmation (2021) and the automated security review with its cooldown (June 2026) postdate all three.

Security notes: SVN credentials and release automation reach every auto-updating site, so a dedicated SVN password, release confirmation and a protected CI environment matter; the cooldown review is a backstop.