Wordpress Repo Checker

wordpress-repo-checker

Validates a WordPress theme or plugin against the official wordpress.org repository requirements for themes and plugins. Reports compliance status and lists any violations.

Invoke

/wordpress-repo-checker [path to theme or plugin directory]

If no path is given, ask the user to provide the theme or plugin directory path.

Determination: Theme or Plugin?

Read the target directory's main files to determine type:

Theme detection:

• Contains style.css with theme header comment (Theme Name, Author, etc.)
• Contains functions.php
• Typically uses template files (index.php, page.php, etc.)

Plugin detection:

• Contains a main plugin file with plugin header comment (Plugin Name, Author, etc.)
• Contains readme.txt (standard for plugins)
• Plugin header is in {plugin-name}.php or main entrypoint

If ambiguous, ask the user to clarify before proceeding.

Check Categories

1. License & Copyright

For Themes:

• style.css header contains License: GPLv2 or License: GPLv2+ or compatible (AGPL, MIT with GPL compatibility statement)
• All bundled third-party assets have clear licensing info (check comments in CSS, JS files, or LICENSES.txt)
• No proprietary license headers on core files

For Plugins:

• Main plugin file header contains License: GPLv2 or License: GPLv2+ or compatible
• All PHP files state compatible license in header comment or are GPL-compatible
• Check for any bundled libraries without GPL-compatible licenses

Report: PASS if GPLv2+ compatible throughout, FAIL if any incompatible licenses found, WARN if licenses unclear/missing.

2. Code Obfuscation

Check for signs of obfuscation in both themes and plugins:

• No minified code in core files (minified JS/CSS is OK in /dist/ or /min/ folders, but source should be readable)
• No base64-encoded payloads or hex encoding in PHP
• No code generated by tools that output unreadable results
• Function and variable names are descriptive, not single letters except in tight loops
• No intentional mangling of code to obscure logic

Search for suspicious patterns:

grep -r "eval\|base64_decode\|gzinflate\|gzuncompress" {PATH} --include="*.php" 2>/dev/null | head -5

Report: PASS if code is human-readable, FAIL if obfuscation found.

3. Security & Input/Output Handling

For Themes:

• All user input is sanitized (search for unsanitized $_POST, $_GET, $_REQUEST)
• All HTML output is escaped with functions like esc_html(), esc_attr(), wp_kses_post(), etc.
• Nonces are used for form submissions
• Database queries use prepared statements where applicable
• No hardcoded database modifications or direct table manipulation

For Plugins:

• Same as above, plus:
• Admin pages use current_user_can() for capability checks
• Settings are registered via Settings API, not stored arbitrarily
• AJAX endpoints are protected with nonces

Common violations:

grep -r "echo \$_" {PATH} --include="*.php"  # unescaped output
grep -r "\$wpdb->query" {PATH} --include="*.php"  # potential SQL injection

Report: PASS if proper escaping/sanitizing seen throughout, FAIL if violations found, WARN if patterns missing.

4. Security Prefixes (Themes only)

• All custom functions use theme-specific prefix (e.g., mytheme_get_featured_image(), not get_featured_image())
• All custom classes use prefix
• All custom hooks/filters use prefix
• No namespace collisions with WordPress core or common plugins

Check for unprefixed custom functions:

grep -rE "^function [a-z_]+\(" {PATH} --include="*.php" | grep -v "^function " | head -10

Report: PASS if all custom code prefixed, FAIL if unprefixed functions found, N/A for plugins.

5. Functionality Restrictions (Themes)

• No plugin-like functionality (hooks, custom post types, tax rules, custom admin pages for plugin-like features)
• Does not hijack WordPress admin interface
• Does not make unauthorized database modifications
• External HTTP requests are minimal and clearly disclosed
• Theme focuses on presentation, not business logic

Common violations:

• Registering custom post types for non-presentation purposes
• Adding custom admin pages for plugin-like features
• Bundling plugin functionality disguised as theme code

Report: PASS if theme stays in presentation layer, FAIL if plugin-like functionality detected.

6. File Structure & Organization

For Themes:

• style.css exists with proper header
• index.php exists (fallback template)
• functions.php exists for theme functions
• Template hierarchy followed (page.php, single.php, archive.php, etc.)
• No extraneous files cluttering root (old_backup.php, test.php, etc.)
• Assets organized in logical folders (/css, /js, /images, /fonts)

For Plugins:

• Main plugin file exists (plugin-name.php or index.php)
• Plugin header present with name, description, version, author, license
• readme.txt exists with proper format (plugin name, description, version, etc.)
• PHP files organized logically (not all code in one giant file for complex plugins)
• Version specified in both plugin header and readme.txt
• Stable tag set in readme.txt

Report: PASS if structure follows conventions, FAIL if missing critical files, WARN if disorganized.

7. Coding Standards

For both themes and plugins, check alignment with WordPress Coding Standards:

• PHP code uses WordPress naming conventions (snake_case for functions/variables, CamelCase for classes)
• Indentation is consistent (4 spaces, not tabs)
• Comments are present for non-obvious code
• No trailing whitespace
• Line length reasonable (not excessively long)

Quick checks:

# Check for tabs (WordPress uses spaces)
grep -P "\t" {PATH}/*.php 2>/dev/null | wc -l

# Check style
head -20 {PATH}/{main_file}.php | grep -E "^\t|    "

Report: PASS if standards followed, WARN if minor inconsistencies, FAIL if major deviations.

8. Dependencies & Libraries

• External dependencies are justified and documented
• WordPress bundled libraries (jQuery, underscore.js, etc.) are used when available
• Third-party libraries have compatible licenses
• No duplicate copies of WordPress built-in libraries

Check wp_enqueue_script() and wp_enqueue_style() calls to verify proper dependency declaration.

Report: PASS if dependencies properly managed, FAIL if bundling core WP libraries, WARN if questionable dependencies.

9. Customization & Settings (Themes)

• Theme provides Customizer controls for key settings (if appropriate)
• Settings use get_theme_mod(), not arbitrary options
• Custom CSS/options do not bloat wp_options table
• Theme mods are documented for users

Report: PASS if customization follows patterns, N/A for minimal themes, WARN if questionable approach.

10. Version Management

• Version number specified in theme/plugin header
• Version increments for each release
• Changelog documented (in readme.txt or CHANGELOG.md)
• Compatibility statement present (e.g., "Tested up to: 6.4")

Report: PASS if versioning clear and maintained, WARN if missing changelog or compatibility.

Output Format

Produce a summary report with findings organized by category:

WordPress Repository Compliance Report
Type: [Theme / Plugin]
Directory: [path]
Report Date: [ISO date]

CATEGORY: Status
  ✓ Passing check
  ✗ Failing check with details
  ⚠ Warning: issue that may cause rejection

Summary:
  Passed: N checks
  Warnings: N checks
  Failed: N checks
  Compliance: [percentage]%

Recommendation: [APPROVED / APPROVED WITH NOTES / NEEDS FIXES / REJECTED]

Notes

• This tool is for submission readiness, not full review
• It catches common violations but may not catch everything the WordPress review team will catch
• Some requirements are subjective (e.g., code quality) — use this as a starting point, not a final authority
• Always refer to official wordpress.org documentation for final submission
• For themes: https://developer.wordpress.org/themes/getting-started/
• For plugins: https://developer.wordpress.org/plugins/plugin-basics/