WordPress Themes Team Standards: Tooling, Auditing, and Community Governance

The WordPress Theme Directory is home to thousands of free, open-source themes that power millions of websites globally. To maintain the security, performance, and code quality of these themes, the WordPress Themes Team establishes rigorous guidelines and maintains a robust suite of automated and manual testing tools. This team of volunteers is responsible for reviewing submissions, maintaining default themes, and guiding developers through major architectural shifts, such as the transition to block-based themes.

Understanding the standards, tools, and processes used by the Themes Team is essential for any developer looking to distribute a theme on WordPress.org. This article explores the technical standards enforced by the team, the automated tooling available for local development, and how developers can participate in the team’s governance, including the upcoming community meeting on July 28, 2026.

1. The Core Mandate of the WordPress Themes Team

The WordPress Themes Team is a volunteer-led group tasked with reviewing and approving themes submitted to the official WordPress Theme Directory. The team’s primary objectives are divided into three core pillars:

• Security and Code Quality: Ensuring that themes do not introduce vulnerabilities (such as Cross-Site Scripting or SQL Injection) and adhere to modern PHP and WordPress coding standards.
• Licensing and Compliance: Verifying that all submitted themes are 100% compatible with the GNU General Public License (GPL) or compatible licenses, ensuring the freedom of end-users.
• Block Theme Transition: Helping theme authors migrate from legacy PHP-based hybrid/classic themes to modern block-based architectures that leverage the full site editing (FSE) capabilities of the WordPress block editor.

2. Enforcing Security and Licensing Requirements

Security is the most critical aspect of the theme review process. Because themes run with high privileges on a user’s server, a single vulnerability can compromise an entire site. The Themes Team enforces strict data sanitization, escaping, and validation requirements.

For example, any dynamic data outputted to the browser must be escaped at the late stage of execution. Developers are required to use specific WordPress escaping functions depending on the context:

• esc_html() for standard HTML output.
• esc_attr() for HTML attributes.
• esc_url() for URLs.
• wp_kses_post() or wp_kses() when safe HTML tags must be preserved in the output.

In addition to security, the team ensures that all assets included in a theme—such as web fonts, CSS frameworks, and JavaScript libraries—are licensed compatibly with the GPL. Third-party resources must be declared in the theme’s readme file, and hotlinking to external resources (excluding official web font APIs under specific conditions) is strictly prohibited to protect user privacy and performance.

3. Automating Code Quality with WPThemeReview and PHP_CodeSniffer

To scale the review process, the Themes Team maintains the WPThemeReview standard for PHP_CodeSniffer (PHPCS). This tool automates the detection of coding standard violations, deprecated functions, and security risks before a theme is submitted.

Developers can install and run the WPThemeReview standard locally using Composer. This ensures that code matches the exact standards used by the official directory reviewers.

Installation and Usage Example

To set up the testing environment in your theme’s root directory, run the following commands:

composer require --dev wp-coding-standards/wpcs dealerdirect/phpcodesniffer-composer-installer
composer require --dev wordpress/theme-upgrader-specials
vendor/bin/phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs,vendor/wordpress/theme-upgrader-specials

Once installed, you can analyze your theme by executing:

vendor/bin/phpcs --standard=WPThemeReview ./my-theme-folder

This sniffer checks for common issues such as missing text domains, direct database queries, improper use of global variables, and missing prefixing on custom functions and global variables.

4. Visual and Structural Validation with Theme Unit Test Data

Code quality is only one side of the coin; a theme must also render content correctly under various edge cases. To test this, the Themes Team maintains the Theme Unit Test Data, an XML file containing a wide variety of dummy content designed to stress-test a theme’s layout and styling.

The Unit Test Data includes:

• Posts with extremely long titles to test text wrapping and overflow.
• Nested comments up to ten levels deep to verify threaded comment layouts.
• Images of various alignments (left, right, center, wide, full) and aspect ratios.
• Pages with missing elements, such as posts without titles or empty categories, to ensure the theme handles empty states gracefully.

Developers import this data via the WordPress Importer plugin in a local development environment to visually inspect how their theme handles complex layout scenarios.

5. The Technical Shift to Block-Based Themes

The primary focus of the Themes Team is currently guiding the developer community toward block themes. Unlike classic themes that rely heavily on PHP template files (like single.php or archive.php), block themes use HTML templates containing block markup.

A standard block theme structure looks like this:

my-block-theme/
├── theme.json
├── style.css
├── functions.php
├── templates/
│   ├── index.html
│   └── single.html
└── parts/
    ├── header.html
    └── footer.html

The theme.json file acts as the central configuration engine, defining global styles and block settings. This file eliminates the need for complex CSS stylesheets and custom customizer controls, standardizing how themes declare color palettes, typography, and layout dimensions.

6. Technical Limitations of Automated Theme Auditing

While automated tools like PHP_CodeSniffer and the Theme Sniffer plugin are invaluable, they have distinct limitations that necessitate manual human reviews:

• Contextual Security Analysis: An automated tool can flag a raw database query, but it cannot easily determine if a custom data sanitization routine implemented by the developer is secure against SQL injection in a complex logical flow.
• User Experience (UX) and Design: Code sniffers cannot evaluate whether a theme is visually broken, has poor color contrast, or features overlapping text on mobile viewports.
• Accessibility (a11y): While tools can check for basic HTML structure, they cannot verify if keyboard navigation works correctly or if screen readers can navigate dynamic menus.

Because of these limitations, every theme submitted to the official directory undergoes a manual review by a member of the Themes Team after passing automated checks.

7. Community Governance: Joining the July 28, 2026 Meeting

The Themes Team operates transparently, holding bi-weekly meetings to discuss standards, review queues, and tooling updates. These meetings occur on the second and fourth Tuesdays of every month at 15:00 UTC.

Due to the cancellation of the second Tuesday meeting in July 2026, the upcoming meeting on Tuesday, July 28, 2026, at 15:00 UTC will serve as the first meeting of the month. The meeting will take place in the official WordPress Slack workspace within the #themes channel.

The agenda for this meeting includes:

• Weekly Updates: Progress reports on the review queue, updates on default themes, and status reports on tooling packages like WPThemeReview.
• Open Floor: An open session where developers can ask questions, raise concerns about specific review requirements, or share updates on their own theme projects.

To participate, you must have an active WordPress Slack account. Anyone interested in theme development, code standards, or contributing to the default themes is highly encouraged to attend and contribute to the discussion.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.