Drupal Review

Drupal Code Review

You are reviewing Drupal code against this team's established coding standards. The goal is to catch issues before they reach production — security holes, stale cache metadata, outdated PHP patterns, and architectural problems are all fair game.

References library: references/

Start by reading README.md in that directory for a quick map, then read only the reference files relevant to what you're reviewing. Don't load all 15 files — be surgical.

Step 1: Understand what to review

If $ARGUMENTS contains file paths, read those files. If the user pasted code inline, work with that. If neither, ask: "What file or directory should I review?"

Scan the code quickly to identify which categories apply before loading reference files.

Step 2: Load relevant references

Always read 15-modern-php.md when reviewing any PHP code — PHP 8.4/8.5 patterns apply everywhere. Always read 10-security.md when there is user input, file handling, or permission checks.

Step 3: Produce the review

Structure your output exactly like this:

Drupal Code Review: [filename or module name]

Critical Issues

Security vulnerabilities, broken access control, data loss risks. Must fix before merge.

Standards Violations

Deviations from Drupal 11 / PHP 8.5 coding standards. Should fix.

Recommendations

Improvements that follow best practices but aren't blocking.

Confirmed Good Practices

Patterns done correctly — acknowledge briefly so the developer knows what to keep.

For each finding:

• Cite the reference (e.g., "→ 10-security.md: Never concatenate user input into SQL")
• Show the problematic snippet
• Show a corrected version

If there are no issues in a section, write "None found." — don't omit the section.

High-value checks to run on every review

These catch the most common Drupal 11 mistakes — worth checking even before reading the full reference files:

PHP / OOP patterns

• No \Drupal:: static calls inside service classes (use constructor injection instead — statics break testability and the service container)
• PHP native attributes used, not Doctrine annotations: #[Block(...)] not /** @Block(...) */
• Constructor property promotion: public function __construct(private readonly FooService $foo) — the verbose property-then-assign pattern is outdated
• All parameters, return types, and properties have type declarations

Hooks

• Hooks implemented as #[Hook] classes in src/Hook/ (Drupal 11.1+), not as procedural functions in .module
• hooks_converted: true set in *.info.yml if all hooks are OOP

Caching

• Every render array has #cache with tags and contexts — missing cache metadata causes stale content for users
• Cache context is user.roles not user for role-based variations (the user context disables page caching)

Security

• No user input concatenated into SQL strings (use DB API placeholders)
• No |raw in Twig on user-supplied content (Twig auto-escapes; |raw bypasses it entirely)
• Routes have explicit requirements: keys

Config

• Config schemas defined in config/schema/ for every key the module introduces