Publishing a WordPress.org Plugin: Git to SVN

Updated 8 November 2026 · Standard formula, shown below

To publish a first plugin on WordPress.org, build and test it in Git, submit it to the WordPress.org Plugin Directory for review, then use Subversion (SVN) to upload approved releases. Git is usually where you develop; SVN is the repository and release handoff the directory uses.

How WordPress.org plugin publishing works

WordPress.org’s Plugin Directory is not simply a mirror of a Git repository. Developers submit a plugin for review, and the directory team checks that it follows the repository guidelines. If accepted, the plugin receives a directory page and an SVN repository. The SVN repository contains the files users can install and update through WordPress, including a stable release in the trunk directory and versioned snapshots under tags.

You can keep your working project in Git, use an editor such as Cursor to help write or review code, and prepare the release from that project. But Cursor does not publish the plugin, and Git commits do not automatically become directory releases. The handoff is a deliberate process: verify the release, copy the intended files into the SVN working copy, create a version tag, and commit the changes to the WordPress.org repository.

Prepare a plugin in Git and Cursor

Start with a plugin that has a clear purpose and a unique directory slug. The main PHP file should contain a valid plugin header, including a plugin name. Add a readme file in the format expected by the directory; its metadata and sections provide the description, installation instructions, FAQ, and changelog shown to users. Check the current WordPress.org plugin guidelines before submission because they govern what the directory accepts.

Git is useful for tracking source changes, reviewing diffs, and marking release points. Keep credentials, local configuration, generated files, and unrelated project materials out of the public release. A .gitignore controls what Git tracks, but it does not control what you later upload to SVN, so review the release files separately.

Cursor can assist with edits, explanations, test creation, and code review. Treat suggestions as unverified: inspect every change, run the plugin, and check security-sensitive behavior such as permissions, input validation, escaping, and database operations. Do not paste passwords, SVN credentials, private keys, or other secrets into prompts or source files. The publishing responsibility remains with the plugin author.

Submit the first version for review

Before submitting, test the plugin on a suitable WordPress installation and confirm that it behaves as described. Check activation, normal use, deactivation, and relevant edge cases. Ensure that the readme’s tested WordPress version and other claims are accurate, and that screenshots or assets referenced by the readme are included where required.

Choose a stable, descriptive plugin slug; it becomes part of the directory URL and repository path.
Prepare the plugin files and readme, and remove development-only material that should not ship.
Submit the plugin through the WordPress.org plugin submission process and provide the requested details.
Wait for the review decision and follow any instructions from the review team. Do not assume that a GitHub release or an upload elsewhere creates a directory listing.
After approval, use the repository details and access method provided for your plugin to make the initial SVN upload.

Review time and requested changes can vary. If the team identifies a problem, address the specific feedback and resubmit as directed rather than trying to publish through an unrelated repository.

The Git-to-SVN handoff

SVN is a version-control system with a different workflow from Git. WordPress.org provides SVN access for directory plugins. You can use command-line SVN or a compatible graphical client; the essential steps are the same. Authentication details and repository URLs should come from the plugin’s directory information, and credentials should be handled privately.

A typical first release uses three important locations:

trunk/: the current development line that supplies the stable plugin files.
tags/1.0/: a snapshot for release 1.0. The tag name should match the version being published.
assets/: directory listing assets, such as banners or icons, when you provide them. These are separate from the plugin’s runtime files.

Check out the repository, copy the reviewed release files into trunk, and add the files you intend to publish. Create the matching version directory under tags by copying the release snapshot from trunk. Then inspect SVN’s status and diff, commit the changes with a useful message, and confirm that the directory listing reflects the release after processing. The exact commands depend on your client; SVN’s standard operations include checkout, add, copy, status, diff, and commit.

For updates, update trunk with the new release, make sure the plugin header and readme stable tag agree on the version, and create a new tag rather than overwriting an old release tag. Keep each tag as the snapshot users should receive for that version. Do not commit your entire Git checkout blindly: Git metadata, tests, build tooling, local files, or private data may not belong in the installable plugin.

Versioning, testing, and common mistakes

The plugin version in its main file and the readme’s stable tag should describe the release you are publishing. A mismatch can make the directory show confusing update information or serve an unintended version. Review those fields alongside the SVN tag name before committing.

Committing only to Git: a Git push does not publish a WordPress.org release unless you have separately built an automation process that performs the SVN handoff.
Forgetting the tag: updating trunk without creating the corresponding version tag can leave the release structure incomplete.
Tagging the wrong files: check the tag contents, not just its name. It should be the release snapshot, not a development tree with missing or extra files.
Shipping development debris: inspect for credentials, temporary files, tests that are not meant to ship, and unnecessary dependencies.
Trusting generated code without review: run appropriate tests and examine changes, especially code that handles user input or privileged actions.

Keep a copy of the exact release snapshot and its Git commit identifier. This makes it easier to investigate a report, reproduce a release, or correct a mistake. If an error reaches the directory, publish a corrected version using the normal release process instead of silently changing the contents of an already published tag.

Frequently Asked Questions

Do I have to use SVN for a WordPress.org plugin?
For publishing through the WordPress.org Plugin Directory, SVN is the repository workflow used to deliver directory releases. You may develop in Git, but you still need to make the release available through the directory’s SVN repository, manually or with a carefully configured tool.

Can Cursor publish my plugin directly?
Cursor can help edit files, but it does not replace directory review or the SVN release process. Any automation or command it suggests should be checked before it changes or commits release files.

Does pushing to GitHub update the WordPress.org plugin?
No, not by itself. GitHub and the WordPress.org SVN repository are separate unless you set up an integration that transfers releases. Confirm the SVN trunk and tag after publishing.

What is the difference between trunk and tags?
Trunk is the current line of plugin files. A tag is a versioned snapshot, such as tags/1.0, associated with a particular release. Users receive the stable version indicated by the directory metadata.

Can I change a release after committing it?
Do not treat a published tag as a working copy. Keep tags as release snapshots; publish a corrected version with a new version number and tag when a fix is needed.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.