wp-org-submission

Name: wp-org-submission
Author: mralaminahamed

25stars3forks

How to install wp-org-submission?

mralaminahamed/wp-dev-skills/wp-org-submission

$npx -y skills add mralaminahamed/wp-dev-skills --skill wp-org-submission

Installs into the current project.

Summary

Use when submitting a WordPress plugin to the WP.org directory for the first time, deploying a new version via SVN (plugins.svn.wordpress.org trunk, tags, assets), fixing a reviewer rejection (17-issue catalog with exact reviewer quotes), writing or correcting readme.txt (Stable

Files · 1

View on GitHub

SKILL.md

1	# WordPress.org Plugin Submission & SVN Deploy
2
3	> Model note: SVN deploy steps and asset setup are mechanical (`haiku`). Pre-submission rejection-pattern scan across a real codebase (17 patterns) requires code judgment — use `sonnet`. Responding to a human reviewer rejection also needs `sonnet`.
4
5	Get a plugin into the WP.org directory and keep releasing to it. Two distinct phases — know which one applies:
6
7	- Phase 1 — Initial submission. Plugin not yet in the directory. One-time human review, then SVN access is granted.
8	- Phase 2 — SVN deploy. Plugin already approved. Ship a new version into the existing SVN repo.
9
10	`wp-org-submission` is about the directory/SVN side. Sync the version sources first with [[wp-plugin-release]] — this skill assumes the codebase already carries the target version.
11
12	## When to use
13
14	- "Submit this plugin to WordPress.org", "publish to the .org directory", "add my plugin to wp.org".
15	- "Deploy the new version to SVN", "push the release to wp.org", "tag a release on plugins.svn".
16	- "Set up screenshots / banner / icon", "why aren't my assets showing".
17	- "Fix a WP.org rejection", "respond to plugin review email", "they flagged trialware / source code / external service".
18	- Pre-submission hygiene sweep using the 17-issue rejection catalog (real reviewer quotes).
19
20	Not for: "will this pass WP.org review?", "check guideline violations", "is my plugin GPL-compliant?" — use the official `wp-plugin-directory-guidelines` skill for authoritative 18-guideline compliance review. This skill owns the workflow (SVN, assets, rejections); that skill owns the rules.
21
22	## Phase 1 — Initial submission
23
24	The review is done by humans and can take days to weeks. Submitting a clean plugin avoids round-trips.
25
26	1. Slug availability — the directory slug is derived from the plugin name in the main file header. Pick a name not already taken at `https://wordpress.org/plugins/<slug>/` (404 = free). Slug is permanent.
27	2. readme.txt valid — must parse in the official validator: `https://wordpress.org/plugins/developers/readme-validator/`. Required header fields, valid `Stable tag`, GPL-compatible `License`. See `references/submission-checklist.md`.
28	3. Guidelines compliance — sanitize input, escape output, nonce-protect actions, prefix all globals, no obfuscation/minified-only code, no external loading of scripts, no tracking or calling home without explicit opt-in consent, GPL-compatible code + assets only. Full checklist in `references/submission-checklist.md`. 17-issue catalog with exact reviewer quotes in `references/review-issues-catalog.md`.
29	4. Build a clean zip — source files (`src/`, `composer.json`, build configs) must be included; `.wordpress-org/` and `node_modules` must not. Full include/exclude lists in §4 of `references/submission-checklist.md`.
30	5. Submit at `https://wordpress.org/plugins/developers/add/`. The reviewer replies by email. Fix what they flag, reply briefly (context only, no change list), attach the updated zip. On approval, SVN access is granted at `https://plugins.svn.wordpress.org/<slug>/`.
31
32	## Phase 2 — SVN deploy
33
34	WP.org distributes via Subversion, not git. The SVN repo has three top-level dirs:
35
36	```
37	<slug>/
38	├── trunk/ # current development copy of the plugin
39	├── tags/ # one immutable dir per released version (tags/1.2.0/)
40	└── assets/ # directory listing images — NOT shipped in the plugin zip
41	```
42
43	The `Stable tag` in `trunk/readme.txt` decides what users download — it must name a directory under `tags/`. Set `Stable tag: 1.2.0` and ensure `tags/1.2.0/` exists. (Pointing Stable tag at `trunk` is legal but discouraged — always release from a tag.)
44
45	Deploy

People who liked this also viewed

6 picks

Type

wp-org-submission

25stars3forks

View on GitHub

How to install wp-org-submission?

mralaminahamed/wp-dev-skills/wp-org-submission

$npx -y skills add mralaminahamed/wp-dev-skills --skill wp-org-submission

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# WordPress.org Plugin Submission & SVN Deploy
2
3	> Model note: SVN deploy steps and asset setup are mechanical (`haiku`). Pre-submission rejection-pattern scan across a real codebase (17 patterns) requires code judgment — use `sonnet`. Responding to a human reviewer rejection also needs `sonnet`.
4
5	Get a plugin into the WP.org directory and keep releasing to it. Two distinct phases — know which one applies:
6
7	- Phase 1 — Initial submission. Plugin not yet in the directory. One-time human review, then SVN access is granted.
8	- Phase 2 — SVN deploy. Plugin already approved. Ship a new version into the existing SVN repo.
9
10	`wp-org-submission` is about the directory/SVN side. Sync the version sources first with [[wp-plugin-release]] — this skill assumes the codebase already carries the target version.
11
12	## When to use
13
14	- "Submit this plugin to WordPress.org", "publish to the .org directory", "add my plugin to wp.org".
15	- "Deploy the new version to SVN", "push the release to wp.org", "tag a release on plugins.svn".
16	- "Set up screenshots / banner / icon", "why aren't my assets showing".
17	- "Fix a WP.org rejection", "respond to plugin review email", "they flagged trialware / source code / external service".
18	- Pre-submission hygiene sweep using the 17-issue rejection catalog (real reviewer quotes).
19
20	Not for: "will this pass WP.org review?", "check guideline violations", "is my plugin GPL-compliant?" — use the official `wp-plugin-directory-guidelines` skill for authoritative 18-guideline compliance review. This skill owns the workflow (SVN, assets, rejections); that skill owns the rules.
21
22	## Phase 1 — Initial submission
23
24	The review is done by humans and can take days to weeks. Submitting a clean plugin avoids round-trips.
25
26	1. Slug availability — the directory slug is derived from the plugin name in the main file header. Pick a name not already taken at `https://wordpress.org/plugins/<slug>/` (404 = free). Slug is permanent.
27	2. readme.txt valid — must parse in the official validator: `https://wordpress.org/plugins/developers/readme-validator/`. Required header fields, valid `Stable tag`, GPL-compatible `License`. See `references/submission-checklist.md`.
28	3. Guidelines compliance — sanitize input, escape output, nonce-protect actions, prefix all globals, no obfuscation/minified-only code, no external loading of scripts, no tracking or calling home without explicit opt-in consent, GPL-compatible code + assets only. Full checklist in `references/submission-checklist.md`. 17-issue catalog with exact reviewer quotes in `references/review-issues-catalog.md`.
29	4. Build a clean zip — source files (`src/`, `composer.json`, build configs) must be included; `.wordpress-org/` and `node_modules` must not. Full include/exclude lists in §4 of `references/submission-checklist.md`.
30	5. Submit at `https://wordpress.org/plugins/developers/add/`. The reviewer replies by email. Fix what they flag, reply briefly (context only, no change list), attach the updated zip. On approval, SVN access is granted at `https://plugins.svn.wordpress.org/<slug>/`.
31
32	## Phase 2 — SVN deploy
33
34	WP.org distributes via Subversion, not git. The SVN repo has three top-level dirs:
35
36	```
37	<slug>/
38	├── trunk/ # current development copy of the plugin
39	├── tags/ # one immutable dir per released version (tags/1.2.0/)
40	└── assets/ # directory listing images — NOT shipped in the plugin zip
41	```
42
43	The `Stable tag` in `trunk/readme.txt` decides what users download — it must name a directory under `tags/`. Set `Stable tag: 1.2.0` and ensure `tags/1.2.0/` exists. (Pointing Stable tag at `trunk` is legal but discouraged — always release from a tag.)
44
45	Deploy

People who liked this also viewed

6 picks

Type