wp-plugin-directory-guidelines
Overview
Authoritative reference for the 18 WordPress.org Plugin Directory guidelines. Covers GPL licensing, plugin naming/trademark rules, trialware restrictions, and all other submission requirements.
When to use
Use this skill when you need to:
- Review a WordPress plugin for compliance with the WordPress.org Plugin Directory guidelines
- Check GPL license compatibility for a plugin or its bundled libraries
- Verify license headers in plugin files
- Identify common guideline violations before submission
- Answer questions about what is or is not allowed on WordPress.org
- Evaluate premium/upsell flows, license checks, or freemium positioning
- Review "teaser" or "preview" UI for trialware violations
Inputs required
- Plugin source code (or specific files to review)
- Optional: plugin readme and plugin header metadata for naming and license checks
Procedure
- Check the plugin's license header against the Valid License Headers section below.
- Walk through the 18 Guidelines checklist, paying special attention to Guidelines 1, 4, 5, 7, 8, and 17.
- Confirm trialware/freemium compliance using the checklist in guideline-review-checklist.md (Guideline 5 section).
- For bundled third-party code, verify license compatibility against GPL-Compatible Licenses (Quick) below.
- Flag matches from Common GPL Violations (Quick) below.
- For edge cases, consult the detailed references and the GNU GPL FAQ.
18-Guideline Review Checklist
Use the detailed, per-guideline checklist in guideline-review-checklist.md. Load this reference file only when a full guideline audit is requested.
GPL Compliance (Guideline 1 in Detail)
Use gpl-compliance.md for full license tables, compatibility nuances, and examples. Keep this inline section as a quick decision aid.
Verification (Licensing)
- Every licensing-related issue must cite Guideline 1 and include the file path and exact license string.
- Confirm compatibility claims against GPL-Compatible Licenses (Quick) and escalate ambiguous licenses.
Failure modes (Licensing)
- If a license is not clearly GPL-compatible, do not guess. Check the GNU license list.
- For dual-license packages, verify both licenses and redistribution terms.
Quick Reference: WordPress GPL Requirements
- WordPress is GPLv2 or later.
- Plugins distributed on WordPress.org must be 100% GPL-compatible (code and assets).
- Include a valid
License:header andLicense URI:in the main plugin file. - Do not add restrictions that conflict with GPL freedoms.
Valid License Headers
GPL Versions Summary
| Version | Year | Key Addition |
|---|---|---|
| GPLv1 | 1989 | Base copyleft: share-alike for modifications |
| GPLv2 | 1991 | "Liberty or death" clause (Section 7), clearer distribution terms |
| GPLv3 | 2007 | Anti-tivoization, explicit patent grants, compatibility provisions |
WordPress uses GPLv2 or later, meaning plugins can use GPLv2, GPLv3, or "GPLv2 or later".
For full license texts, see:
License Compliance Checklist
When reviewing a plugin, verify:
- Main plugin file has a valid
License:header (e.g.,GPL-2.0-or-later,GPL-2.0+,GPLv2 or later) - Main plugin file has a
License URI:header pointing to the GPL text - If bundled libraries exist, each has a GPL-compatible license
- No "split licensing" (e.g., code GPL but premium features proprietary)
- No additional restrictions beyond what GPL allows
- No clauses restricting commercial use, modification, or redistribution
- No obfuscated code (violates the spirit of source code availability)
Valid License Headers for WordPress Plugins
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
License: GPL-3.0-or-later
License URI: https://www.gnu.org/licenses/gpl-3.0.html
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
GPL-Compatible Licenses (Quick)
- Safe defaults: GPL-2.0-or-later, GPL-3.0-or-later.
- Commonly accepted permissive families: MIT/Expat, BSD, ISC, zlib, Boost.
- Conditional compatibility requires care: Apache-2.0 and MPL-2.0 (verify usage context).
- For full accepted and rejected identifiers, use gpl-compliance.md.
Common GPL Violations (Quick)
- Split licensing that restricts distributed code.
- Obfuscated or non-corresponding source distribution.
- Restrictive clauses (non-commercial, no-resale, forced backlink).
- Bundling GPL-incompatible libraries or assets.
Plugin Naming Rules (Guideline 17)
Use naming-rules.md for full trademark lists, slug blocks, and naming examples. Keep this inline checklist for quick screening.
Naming Checklist (Quick)
- Name is not a placeholder and has at least 5 alphanumeric characters.
- Header name and readme name match.
- Name is specific and function-related; avoid keyword stuffing.
- Trademark/project names appear only after connectors like
for,with,using,and. - No banned/discouraged terms or trademark portmanteaus.
- Slug is lowercase, hyphenated, <= 50 chars, and avoids blocked terms.
More from wordpress/agent-skills
wp-plugin-development
Use when developing WordPress plugins: architecture and hooks, activation/deactivation/uninstall, admin UI and Settings API, data storage, cron/tasks, security (nonces/capabilities/sanitization/escaping), and release packaging.
2.2Kwp-rest-api
Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest.
1.7Kwp-block-themes
Use when developing WordPress block themes: theme.json (global settings/styles), templates and template parts, patterns, style variations, and Site Editor troubleshooting (style hierarchy, overrides, caching).
1.6Kwp-performance
Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing, Query Monitor via REST headers), database/query optimization, autoloaded options, object caching, cron, HTTP API calls, and safe verification.
1.5Kwp-block-development
Use when developing WordPress (Gutenberg) blocks: block.json metadata, register_block_type(_from_metadata), attributes/serialization, supports, dynamic rendering (render.php/render_callback), deprecations/migrations, viewScript vs viewScriptModule, and @wordpress/scripts/@wordpress/create-block build and test workflows.
1.5Kwordpress-router
Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing, release packaging).
1.4K