What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Publishing a plugin to WordPress.org involves two distinct stages: submit a complete, installable ZIP for review, then—if approved—use the plugin’s Subversion (SVN) repository to publish releases. You can use Cursor and Git while developing, but neither changes the directory’s rules or makes your code live. This guide follows the documented workflow; it does not claim a particular plugin, Cursor session, or approval outcome.
How do I publish my first WordPress plugin?
WordPress.org’s process starts with a finished plugin package, not an empty directory reservation. Prepare the plugin, test it, choose a distinctive name, write its documentation, and submit a complete ZIP that is ready for manual installation. WordPress.org reviews the submission. If it is approved, you receive access details for its SVN repository; uploading the plugin files there makes the plugin available in the directory. The directory provides free hosting, statistics, user reviews, and a support forum. See the official planning and submission guide and directory overview.
- Finish and test the plugin. Make sure it has a meaningful purpose and works as intended. Review the code and its dependencies before packaging.
- Choose a distinctive name and prepare documentation. WordPress.org does not reserve names for plugins that are not submitted as complete plugins.
- Create a complete ZIP. Include the files needed for a working manual installation, not just a code sample or partial project.
- Submit the ZIP and description through the WordPress.org plugin submission process. Use an account with an email address you check regularly so you can see review correspondence.
- Address any review feedback. Monitor the submission status and reply to review email if requested.
- After approval, configure SVN and publish a release deliberately. Use the WordPress.org repository for release files, not as a mirror of every development change.
This sequence synthesizes the official submission guidance, SVN guidance, and Plugin Developer FAQ; it is not a promise of approval or a guaranteed timetable.
Recommended Free Tools
How long does WordPress.org plugin review take?
The planning guide says a queued submission will be reviewed within 14 business days, but that wording is not a guaranteed approval deadline. The FAQ says there is “no official average” because submissions vary. Check the status and respond to reviewer messages rather than treating the stated review window as a promise that a plugin will be approved by a particular date.
Can I use Git to publish a WordPress.org plugin?
Yes, for development. Git can hold your working history and support iterative changes, but WordPress.org requires its SVN repository for directory releases. The two repositories serve different purposes: Git is your development workflow; SVN is the publication mechanism. Git commits do not publish a plugin to WordPress.org, while pushing files into the plugin’s SVN folders can make them live. The distinction is explicit in the planning guide, SVN instructions, and FAQ.
| Workflow | Purpose | When it is used | Effect |
|---|---|---|---|
| Git | Track and manage development work. | During ongoing local or team development. | Commits do not themselves publish code to the WordPress.org directory. |
| WordPress.org SVN | Maintain directory release files. | After plugin approval, when preparing a public release. | Committed files in the plugin repository are published; only release-ready files belong there. |
What belongs in SVN?
The official SVN guide describes /trunk as the working release line and SVN tags as the way to mark a release version. The repository accepts individual files, not a ZIP upload. Keep development experiments and unfinished changes in Git; put only files you are prepared to deploy to users in SVN. WordPress.org says that a plugin goes live as soon as code is pushed into its SVN folders, and there is no simple “off” switch. That makes a final review before each SVN push important.
Rank #2
Prepare a release without turning SVN into your development branch
- Complete and test the change in your development workflow.
- Prepare the complete submission ZIP for review.
- Submit it and address review feedback.
- After approval, configure the SVN repository provided for the plugin.
- Put the release files in the appropriate repository structure, update the version, and tag the release.
- Push only when the files are ready to become public.
These steps combine WordPress.org’s submission, SVN, and release guidance. Avoid rapid, trivial SVN commits: the guidelines say SVN commits regenerate the downloadable ZIP.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchCan I use Cursor or AI to build a WordPress plugin?
Yes. WordPress.org’s documentation names Cursor as a possible client for its MCP server, which can provide AI-enabled development tools such as guideline access, readme validation, status checks, and help with a submission while it is under review. Once approved, updates are published through SVN. The existence of this integration does not establish that any particular plugin author used it or that AI-generated code is ready to release. See Using the WordPress.org MCP Server.
Rank #3
AI assistance does not change the standard. WordPress.org applies the same rules regardless of how the code was produced. Its guidance is direct: “You are responsible for all code in your plugin.” Review AI-generated changes so you understand what they do and can identify security vulnerabilities, licensing problems, unnecessary external service calls, or behavior that misses the intended purpose. WordPress.org recommends running Plugin Check locally before submission.
What to review in AI-assisted changes
- Read and understand the code rather than accepting generated changes as a black box.
- Check that the behavior matches the plugin’s stated purpose and does not add unintended features.
- Inspect data collection, network requests, and third-party service use.
- Verify code and dependency licenses and check the terms of any service the plugin relies on.
- Run appropriate tests and Plugin Check before creating the submission ZIP.
What rules should I check before submitting?
The Detailed Plugin Guidelines and Plugin Developer FAQ set out requirements that apply to plugins whether written by hand or with AI.
- License compatibility: Plugin code, data, images, and third-party libraries must be GPL-compatible. Verify the license of material you include and the terms of external services you use.
- Readable code: Code must remain mostly human-readable. If you include minified files, include the non-minified source or make it available as described in the readme.
- Privacy and external code: Do not track users without consent or send executable code through third-party systems. Review what information leaves a user’s site and why.
- Meaningful functionality: A plugin needs a practical purpose. The FAQ says new plugins that enable arbitrary code insertion or execution are not accepted, with PHP or JavaScript editors and file managers given as examples.
- Complete submission: Submit a full plugin ready for installation; a name is not held for a future, unfinished project.
- Release versioning: Increment version numbers for releases and keep the trunk readme’s version current.
What happens to new releases after approval?
WordPress.org’s automated security review page says that since June 2026, every new plugin release has gone through a cooldown and automated security review before distribution through the update API. Releases identified as higher risk are blocked from distribution until the issues are addressed. This describes the documented release process as of the page’s publication; check the current Automated Security Review guidance when planning a release because platform processes can change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
