dokan-code-review

name: dokan-code-review description: Review Dokan code changes and pull requests for coding standards, security, and architectural compliance. Use when reviewing PRs, performing code audits, or checking code quality.

Dokan Code Review

Review code changes against Dokan coding standards and project conventions. Consult the other dokan-* skills for detailed standards.

Critical Violations to Flag

Backend PHP

Architecture & Structure:

• Wrong base class for REST controllers — Must extend the appropriate Dokan base controller (DokanBaseAdminController, DokanBaseVendorController, or DokanBaseController), not WP_REST_Controller directly. See dokan-backend-dev skill.
• Missing prepare_item_for_response() — Every REST controller must transform data through this method, not return raw arrays.
• Missing pagination headers — Collection endpoints must call format_collection_response() to set X-WP-Total and X-WP-TotalPages.
• Missing prepare_links() — REST responses must include self and collection HATEOAS links.
• Missing extensibility filters — REST responses must apply dokan_rest_prepare_{resource}_object filter. Query args must be filterable.
• Direct instantiation instead of DI — Use dokan()->service_name or container, not new ClassName() for registered services.
• Hooks outside Hookable pattern — New hook registrations should go in a dedicated Hooks class implementing Hookable interface, registered in CommonServiceProvider.
• Service not registered — New services must be added to the appropriate ServiceProvider in includes/DependencyManagement/Providers/.

Naming & Conventions:

• camelCase methods — Must use snake_case for methods, variables, and hooks (WordPress convention).
• Wrong namespace — Must follow WeDevs\Dokan\{Domain}\{Class} pattern with matching file path.
• Wrong text domain — Must use dokan-lite for all translatable strings.
• Missing dokan prefix on hooks — All apply_filters() and do_action() hook names must start with dokan_ (e.g., dokan_order_created, dokan_vendor_updated). Never use unprefixed or generic hook names to avoid conflicts with other plugins.

Security:

• Missing permission callbacks — Every REST route must have a permission_callback (never omit it).
• Loose comparisons — Must use strict comparisons (===, !==). in_array() must pass true as third argument.
• Unsanitized input — All $request params must be sanitized (sanitize_text_field(), absint(), wc_clean(), etc.).
• Unescaped output — All output must be escaped (esc_html(), esc_attr(), wp_kses_post(), etc.).
• Direct SQL without $wpdb->prepare() — All dynamic SQL values must use prepared statements.

Documentation:

• Missing @since tag — Required for new public/protected methods and hooks.
• Missing PHPDoc — Required for all class methods, hooks, and filters.

Frontend (React/TypeScript)

• Class components — Must use functional components only.
• Direct UI library usage — Should wrap @getdokan/dokan-ui components through src/components/ wrappers.
• Missing TypeScript types — Strict mode is enabled; no any types without justification.
• Inline styles instead of Tailwind — Use Tailwind classes with twMerge() for conditional composition.
• Direct state mutation — Use @wordpress/data store actions, not direct state changes.
• Missing hook exports — New hooks in src/hooks/ must be exported from src/hooks/index.tsx.
• Missing dokan prefix on JS hooks — All @wordpress/hooks hook names (addFilter, applyFilters, addAction, doAction) must start with dokan_ (e.g., dokan_order_list_columns, dokan_dashboard_init). Never use unprefixed or generic hook names to avoid conflicts with other plugins.

Testing

• Not extending DokanTestCase — PHP tests must extend DokanTestCase, not WP_UnitTestCase directly.
• Missing test group — Tests should have @group annotations.
• Manual user/order creation — Use test factories ($this->factory()->seller->create(), $this->factory()->order->create()).
• Direct REST calls in tests — Use helper methods ($this->get_request(), $this->post_request()).
• Missing E2E tags — Playwright tests must have tags (@lite, @pro, @admin).

PR Checklist Verification

Verify against the PR template (.github/pull_request_template.md):

1. Code follows WordPress coding standards — Run composer phpcs on changed files
2. PHPCS tests pass — No coding standard violations
3. Inline documentation present — PHPDoc for new methods/hooks
4. Proper labels assigned — Bug fix, feature, enhancement, etc.
5. Changelog entry — Before/after description included
6. Screenshots — Required for visual changes
7. Test instructions — Steps to reproduce/verify the change

PR Labels

Apply the correct labels during review. Labels drive workflow state and help the team triage.

Review State Labels

Type Labels

Priority Labels

Scope Labels (apply all that match)

Focus areas: focus: order, focus: product management, focus: vendor management, focus: payments, focus: shipping, focus: customer management, focus: reporting, focus: security, focus: ux, focus: integration, focus: localization, focus: customization, focus: promotions, focus: subscription

Module areas: [Orders], [Products], [Store], [Vendor Dashboard], [Withdraw], [Social], [Geolocation], [Suggestions]

Other Labels

Label Transitions During Review

Typical flow:

Review Needed → (reviewing) → Needs: Author Reply → (author updates) → Review Needed
Review Needed → (approved) → Dev Review Done → QA In Progress → QA Approved → Ready to Merge

When requesting changes:

1. Remove Review Needed
2. Add Needs: Author Reply
3. Leave clear comments explaining what needs to change

When author addresses feedback:

1. Remove Needs: Author Reply
2. Add Review Needed

When approving:

1. Remove Review Needed
2. Add Dev Review Done
3. Approve the PR via GitHub review

Review Approach

1. Scan for critical violations listed above
2. Check the PR checklist items are satisfied
3. Verify REST patterns — schema, pagination, links, filters, error handling
4. Check security — permissions, sanitization, escaping, SQL safety
5. Review extensibility — are appropriate filters/actions in place for pro plugin extension?
6. Assess test coverage — are new features/fixes covered by tests?

Output Format

For each violation found:

[severity]: [Specific problem]
Location: [File path and line number]
Standard: [Reference to relevant dokan-* skill section]
Fix: [Brief explanation or correct example]

Severity levels:

• CRITICAL — Security issues, data loss risk, broken functionality
• ERROR — Standards violation, missing required patterns
• WARNING — Suboptimal approach, missing best practice
• SUGGESTION — Improvement opportunity, not a violation

Reviewer Principles

From the PR template:

Correct — Does the change do what it's supposed to? Code 100% fulfilling the requirements? Secure — Would a nefarious party find some way to exploit this change? Everything sanitized/escaped appropriately? Readable — Will your future self be able to understand this change months down the road? Elegant — Does the change fit aesthetically within the overall style and architecture?