code-review

name	code-review
description	Security and WordPress coding standards code review for PHP, JavaScript/TypeScript, or CSS.

WordPress Code Review

Review the specified WordPress code against this project's standards, WordPress best practices, and security requirements.

What to review

If the user specifies files or a PR, review those. Otherwise, review the current uncommitted changes.

PHP Checklist

Standards

• declare( strict_types=1 ); present in every PHP file.
• Namespace declaration is correct and consistent with the package and composer.json PSR-4 map.
• No var_dump, print_r, or debug output left in.

Security

• All $_GET / $_POST / $_REQUEST reads sanitised with sanitize_text_field(), absint(), sanitize_email(), etc.
• Nonces verified before processing form/AJAX submissions (check_ajax_referer or wp_verify_nonce).
• All output escaped with the right function for its context (esc_html, esc_attr, esc_url, wp_kses_post).
• No direct SQL string concatenation — $wpdb->prepare() used for all queries with user data.
• File uploads validated with wp_check_filetype_and_ext().
• No eval(), system(), exec(), shell_exec() or equivalent.

WordPress Patterns

• add_action / add_filter calls are in a hooks() method, not scattered across constructors or global scope.
• Named methods used for hook callbacks (not anonymous closures) so they can be removed.
• register_activation_hook / register_deactivation_hook called in the plugin bootstrap file (not inside a hooked callback).
• Textdomain matches plugin-slug / theme-slug declared in the file header.
• All user-facing strings wrapped in __(), _e(), esc_html__(), or similar.
• No direct echo of untrusted data — even inside esc_* calls check if the source is trustworthy.
• wp_safe_redirect() used over header('Location: ...').
• wp_die() used over die() / exit() in WP context.

Code Style

• Yoda conditions: 'value' === $variable.
• Tab indentation (not spaces) in PHP.
• One class per file; file name matches class name.
• PSR-4 namespace matches directory structure and composer.json autoload map.
• No trailing whitespace; blank line at end of file.

Performance

• No uncached queries inside loops (get_post_meta in a loop without pre-fetching).
• wp_cache_get / wp_cache_set used for expensive or repeated queries.
• posts_per_page never set to -1 in production queries — cap at a reasonable number.
• Assets enqueued conditionally where possible (not loaded on every page).

JavaScript / Block Editor Checklist

• No import { ... } from 'react' — must use @wordpress/element.
• No __experimental or __unstable WordPress API imports — @wordpress/no-unsafe-wp-apis is enforced.
• No window.wp global — always import from @wordpress/* packages.
• Import groups ordered correctly: external (@wordpress/*) before internal (./, ../).
• Block save() function is pure and deterministic.
• useBlockProps() applied to the root element in both Edit and save.
• InspectorControls / BlockControls used for settings, not custom sidebars.
• @wordpress/api-fetch used for REST calls, not fetch() directly.
• Nonce passed via apiFetch middleware, not as a query string.
• block.json asset manifest (.asset.php) used for enqueue dependencies.
• No console.log left in production code.
• All user-visible strings use __() from @wordpress/i18n.

Accessibility Checklist

• Interactive elements are keyboard accessible.
• Images have meaningful alt text (or alt="" if decorative).
• ARIA attributes used correctly — prefer semantic HTML over ARIA roles.
• Colour contrast meets WCAG AA (4.5:1 for text, 3:1 for UI components).
• Form inputs have associated <label> elements.

i18n Checklist

• All user-facing PHP strings wrapped in __(), _e(), _n(), _x() with correct text domain.
• No string concatenation for translated sentences — use sprintf().
• JS strings use @wordpress/i18n (__, _n, _x, sprintf).

SCSS / CSS Checklist

• No ID selectors.
• No hardcoded colour values — uses CSS custom properties from theme.json or _variables.scss.
• BEM naming convention followed.
• Breakpoints use the project breakpoint() mixin.
• No !important except in explicit utility classes.

Output format

Report issues grouped by severity:

Critical (must fix before merge — security or data loss risk) Major (should fix — bugs, missing WP patterns, accessibility) Minor (nice to fix — style, performance hints) Praise (note what is done well)

For each issue, include: file path, line number (if known), description, and a suggested fix.