Backport v1.30.1 - #1206
Conversation
Release v1.28.0
Release v1.29.0
Release v1.30.0
…ighter This is used alongside the other logged in check to determine if we show a button to rescan or clear issues to a given user
… the post in the id passed through request
…sues or clearing issues
…sults and issue clearing
This test verifies that a limited user can save scan results and clear issues for their own post. [PRO-165]
Enhance the API by ensuring that the 'id' argument is required and properly sanitized.
Ensure consistent code style by aligning closing braces for validation callbacks in the REST API.
Added assertions to check for 'success', 'id', and 'flushed' keys in the API response data for various test cases.
…ccessing scan stats
…accessing scan stats
…accessing scan stats
…r clearing cached scan stats
Updated the plugin version in multiple files to reflect the new release and added improvements to the changelog. [PRO-165]
WalkthroughVersion bump to 1.30.1 across plugin, package.json, and readme. Tightened permission checks in REST API with a new helper for per-post edit verification. Frontend enqueues and app now pass/use userCanEdit to gate Clear/Rescan buttons. Admin “Update Counts” button is capability-gated. New PHPUnit tests validate REST permissions. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant Browser as Frontend Highlighter
participant WP as WP Localize/Enqueue
Note over WP: Compute userCanEdit = current_user_can('edit_post', post_id)
WP->>Browser: edacFrontendHighlighterApp { loggedIn, userCanFix, userCanEdit }
Browser->>Browser: userCanEdit = app.userCanEdit && app.loggedIn
alt userCanEdit
Browser->>User: Show "Clear Issues" & "Rescan This Page"
else not userCanEdit
Browser->>User: Hide action buttons
end
sequenceDiagram
autonumber
actor Client
participant REST as REST API
participant Caps as WP Cap Check
Client->>REST: POST /post-scan-results { id }
REST->>REST: user_can_edit_passed_post_id(request)
alt id missing/invalid
REST-->>Client: 400/ WP_Error
else id present
REST->>Caps: current_user_can('edit_post', id)
alt can edit
REST-->>Client: 200 { success }
else cannot edit
REST-->>Client: 403
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Pull Request Overview
This is a backport of version 1.30.1 that improves permission handling for the frontend highlighter and REST API endpoints. The key focus is ensuring that users can only perform actions on posts they have edit permissions for, replacing generic capability checks with more specific post-level permission validation.
- Enhanced REST API permission callbacks to check edit capabilities for specific posts
- Updated frontend highlighter to show rescan/clear buttons only when users can edit the post
- Added comprehensive test coverage for the new permission model
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| accessibility-checker.php | Version number update to 1.30.1 |
| package.json | Package version bump to match plugin version |
| readme.txt | Changelog entry and stable tag update |
| includes/classes/class-rest-api.php | Enhanced permission callbacks with post-specific capability checks |
| includes/classes/class-enqueue-frontend.php | Added userCanEdit flag for frontend scripts |
| src/frontendHighlighterApp/index.js | Updated UI logic to use userCanEdit instead of generic logged-in check |
| admin/class-welcome-page.php | Added permission check for update counts button |
| tests/phpunit/includes/classes/RestApiEndpointsTest.php | New comprehensive test suite for REST API permission handling |
| * REST handler to clear issues results for a given post ID. | ||
| * | ||
| * @param WP_REST_Request $request The request passed from the REST call. | ||
| * @param \WP_REST_Request $request The request passed from the REST call. |
There was a problem hiding this comment.
The docblock parameter type should use the fully qualified class name \WP_REST_Request to match the pattern used elsewhere in the function (line 217 uses \WP_REST_Request).
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @pattonwebz, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request backports version 1.30.1 of the Accessibility Checker plugin, primarily focusing on enhancing user permission checks for various features. It refines when certain actions, like updating scan counts or clearing issues, are available to users, ensuring that capabilities are robustly enforced across both the administrative interface and frontend functionalities, including REST API endpoints. This update improves security and user experience by preventing unauthorized actions and dynamically adjusting the UI based on user permissions.
Highlights
- Version Update: The plugin version has been incremented to 1.30.1 across all relevant files, including the main plugin file, package.json, and readme.txt.
- Enhanced Permission Checks: Implemented more granular capability checks for actions such as updating scan counts in the admin dashboard and displaying "Clear Issues" and "Rescan" buttons in the frontend highlighter, ensuring these actions are only available to users with appropriate permissions.
- Robust REST API Security: Strengthened permission callbacks for several REST API endpoints related to accessibility scans, ensuring that actions like saving and clearing post scan results, and retrieving scan statistics, are properly restricted based on user capabilities. This includes the introduction of a new helper function for consistent post-specific edit permissions.
- New PHPUnit Tests: Dedicated PHPUnit tests have been introduced to validate the correctness and security of the updated REST API endpoint permissions, covering various user roles and post ownership scenarios.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request is a backport for version 1.30.1, primarily focused on enhancing security by tightening permissions on several REST API endpoints and ensuring these permissions are reflected on the frontend. The introduction of unit tests for the REST API endpoints is a significant improvement that will help maintain code quality and stability. The changes are well-implemented and consistent across the codebase. I've included a couple of minor suggestions to improve code clarity and remove redundancy.
| public function user_can_edit_passed_post_id( $request ) { | ||
| if ( ! isset( $request['id'] ) ) { | ||
| return new \WP_Error( 'rest_post_invalid_id', __( 'A required parameter is missing.', 'accessibility-checker' ), [ 'status' => 400 ] ); | ||
| } | ||
| $post_id = (int) $request['id']; | ||
| return current_user_can( 'edit_post', $post_id ); // able to edit the post. | ||
| } |
There was a problem hiding this comment.
The if ( ! isset( $request['id'] ) ) check is redundant. The REST API routes using this permission callback (/post-scan-results and /clear-issues) define the id parameter as required. WordPress's REST API automatically handles missing required parameters and returns an error before this callback is executed. Removing this check will make the code cleaner and rely on the framework's validation.
public function user_can_edit_passed_post_id( $request ) {
$post_id = (int) $request['id'];
return current_user_can( 'edit_post', $post_id ); // able to edit the post.
}| // Admin can POST results for the post. | ||
| wp_set_current_user( self::$admin_id ); | ||
| $request = new WP_REST_Request( 'POST', '/accessibility-checker/v1/post-scan-results/' . self::$post_id ); | ||
| $request->set_param( 'id', self::$post_id ); |
There was a problem hiding this comment.
This set_param() call is redundant. The id parameter is already part of the URL provided to the WP_REST_Request constructor on the previous line. The WordPress REST Server will parse the ID from the route pattern (/post-scan-results/(?P<id>\d+)). Removing this line will make the test code cleaner. This applies to similar set_param('id', ...) calls in this test file (lines 131, 148, 165, 189, 208).
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
admin/class-welcome-page.php (1)
43-47: Good gate on “Update Counts”; also lock it down server-side.Hiding the button unless the user can publish is the right move. Double-check that the AJAX/REST handler for clearing cached stats enforces the same capability so a direct call can’t bypass the UI.
If you want to make the capability adjustable without more code changes, you can filter it inline:
- <?php if ( current_user_can( 'publish_posts' ) ) : ?> + <?php if ( current_user_can( apply_filters( 'edac_filter_welcome_update_counts_cap', 'publish_posts' ) ) ) : ?>Follow-up:
- Verify the corresponding endpoint/action checks current_user_can('publish_posts') (or the filtered cap).
- If this button triggers admin-ajax, consider passing a nonce via a data attribute and validating it server-side.
readme.txt (1)
214-217: Changelog reads clearly; consider naming the exact caps for clarity.Optional polish: mention the specific capabilities (edit_post for per-post actions, publish_posts for Update Counts) so site owners instantly know who sees what.
includes/classes/class-enqueue-frontend.php (1)
96-113: New userCanEdit flag is the right call; tighten a couple of edges.
- Exposing userCanEdit keeps the frontend honest about who sees “Clear/Rescan.” Good.
- When visibility is forced via the filter for non-editors, editorLink may be false. Guard it to avoid odd UI states.
- Minor: cast postID to int before localizing.
Apply this small tweak:
wp_localize_script( 'edac-frontend-highlighter-app', 'edacFrontendHighlighterApp', [ - 'postID' => $post_id, + 'postID' => absint( $post_id ), 'nonce' => wp_create_nonce( 'ajax-nonce' ), 'restNonce' => wp_create_nonce( 'wp_rest' ), 'userCanFix' => current_user_can( apply_filters( 'edac_filter_settings_capability', 'manage_options' ) ), - 'userCanEdit' => current_user_can( 'edit_post', $post_id ), + 'userCanEdit' => current_user_can( 'edit_post', $post_id ), 'edacUrl' => esc_url_raw( get_site_url() ), 'ajaxurl' => admin_url( 'admin-ajax.php' ), 'loggedIn' => is_user_logged_in(), 'appCssUrl' => EDAC_PLUGIN_URL . 'build/css/frontendHighlighterApp.css?ver=' . EDAC_VERSION, - 'editorLink' => get_edit_post_link( $post_id ), + 'editorLink' => current_user_can( 'edit_post', $post_id ) ? get_edit_post_link( $post_id ) : '', 'scannerBundleUrl' => plugin_dir_url( EDAC_PLUGIN_FILE ) . 'build/pageScanner.bundle.js', ] );Confirm the REST endpoints backing “Rescan” and “Clear” enforce per-post edit checks (permission_callback) so UI and server stay in lockstep.
src/frontendHighlighterApp/index.js (1)
397-405: Gate Clear/Rescan on edit permission: solid hardening. Minor polish to ensure strict boolean.Nice job hiding destructive actions unless the user can actually edit. I pity the bug that tries to click what ain’t there.
You can simplify and make the check explicitly boolean (avoids accidental truthy surprises) like so:
-const userCanEdit = edacFrontendHighlighterApp && edacFrontendHighlighterApp?.userCanEdit && edacFrontendHighlighterApp?.loggedIn; +const userCanEdit = Boolean(edacFrontendHighlighterApp?.userCanEdit && edacFrontendHighlighterApp?.loggedIn);includes/classes/class-rest-api.php (1)
210-227: Add typehint and early invalid-ID guard in helper.Permission callbacks run before arg validation/sanitation. You already cast, which is good. Typehinting the request parameter helps IDEs and static analyzers; also return a 400 when id casts to 0.
- public function user_can_edit_passed_post_id( $request ) { + public function user_can_edit_passed_post_id( \WP_REST_Request $request ) { if ( ! isset( $request['id'] ) ) { return new \WP_Error( 'rest_post_invalid_id', __( 'A required parameter is missing.', 'accessibility-checker' ), [ 'status' => 400 ] ); } $post_id = (int) $request['id']; + if ( $post_id <= 0 ) { + return new \WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.', 'accessibility-checker' ), [ 'status' => 400 ] ); + } return current_user_can( 'edit_post', $post_id ); // able to edit the post. }tests/phpunit/includes/classes/RestApiEndpointsTest.php (1)
177-217: Ownership path verified. Consider adding coverage for tightened stats endpoints.Great that authors can manage their own drafts. To round it out, add small tests for the capability changes on stats endpoints to prevent regressions.
Here are ready-to-drop tests you can append to this class:
public function test_scans_stats_requires_edit_posts() { $this->assertNotNull( $this->server ); // Anonymous should be forbidden. wp_set_current_user( 0 ); $respAnon = $this->server->dispatch( new WP_REST_Request( 'GET', '/accessibility-checker/v1/scans-stats' ) ); $this->assertSame( 401, $respAnon->get_status() ); // Limited user (subscriber + edit_posts) allowed. wp_set_current_user( self::$limited_id ); $respUser = $this->server->dispatch( new WP_REST_Request( 'GET', '/accessibility-checker/v1/scans-stats' ) ); $this->assertSame( 200, $respUser->get_status() ); } public function test_clear_cached_scans_stats_requires_publish_posts() { $this->assertNotNull( $this->server ); // Limited user lacks publish_posts. wp_set_current_user( self::$limited_id ); $respDenied = $this->server->dispatch( new WP_REST_Request( 'POST', '/accessibility-checker/v1/clear-cached-scans-stats' ) ); $this->assertSame( 403, $respDenied->get_status() ); // Admin allowed. wp_set_current_user( self::$admin_id ); $respOk = $this->server->dispatch( new WP_REST_Request( 'POST', '/accessibility-checker/v1/clear-cached-scans-stats' ) ); $this->assertSame( 200, $respOk->get_status() ); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (8)
accessibility-checker.php(3 hunks)admin/class-welcome-page.php(1 hunks)includes/classes/class-enqueue-frontend.php(1 hunks)includes/classes/class-rest-api.php(7 hunks)package.json(1 hunks)readme.txt(2 hunks)src/frontendHighlighterApp/index.js(2 hunks)tests/phpunit/includes/classes/RestApiEndpointsTest.php(1 hunks)
🧰 Additional context used
📓 Path-based instructions (12)
**/*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.php: Follow WordPress coding standards (WPCS) in all PHP files
Use PSR-4 autoloading with EqualizeDigital\AccessibilityChecker namespace for new classes
Use WordPress hooks and filters appropriately
Use edac_ prefix for custom hooks and filters
Minimum PHP 7.4 compatibility
Use type hints where appropriate in PHP code
Follow WordPress security best practices (sanitization, validation, nonces)
Use WordPress database API (wpdb) for database operations
Prefix all functions and classes with edac_ when in global namespace
Use WordPress hooks (actions/filters) for extensibility
Use WordPress transients for caching
Sanitize all user inputs
Validate and escape all outputs
Use WordPress nonces for form submissions
Implement proper capability checks
Provide appropriate hooks for extensibility when adding new functionality
Use descriptive hook names with edac_ prefix
Document all custom hooks in docblocks
Document custom hooks and filters with clear descriptions and parameter types
Use PHPDoc for all public classes, methods, and properties
Escape all output, especially in admin screens and user-generated content
Use WordPress error handling functions (e.g., WP_Error) for PHP errors
Files:
includes/classes/class-enqueue-frontend.phpadmin/class-welcome-page.phptests/phpunit/includes/classes/RestApiEndpointsTest.phpaccessibility-checker.phpincludes/classes/class-rest-api.php
**/class-*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/class-*.php: Legacy files are autoloaded using EDAC namespace
Legacy class names use WordPress style (Class_Name_Convention)
Legacy file names use class-class-name.php (WordPress style)
Legacy Classes: class-class-name.php
Deprecate legacy code with clear docblocks and migration notes
Files:
includes/classes/class-enqueue-frontend.phpadmin/class-welcome-page.phpincludes/classes/class-rest-api.php
**/*.{php,js}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{php,js}: Follow WordPress internationalization (i18n) practices and use accessibility-checker text domain
All user-facing text must be translatable
Add inline comments for complex accessibility logic or non-obvious code
Use semantic HTML structure
ARIA attributes used correctly
Keyboard navigation supported
Images have descriptive alt text
Heading hierarchy logical
Screen reader compatibility
Forms are accessible and labeled
Files:
includes/classes/class-enqueue-frontend.phpadmin/class-welcome-page.phpsrc/frontendHighlighterApp/index.jstests/phpunit/includes/classes/RestApiEndpointsTest.phpaccessibility-checker.phpincludes/classes/class-rest-api.php
includes/**/*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
includes/**/*.php: Validate all AJAX requests and REST endpoints with nonces and capability checks
Avoid blocking queries in PHP, especially during scans
Files:
includes/classes/class-enqueue-frontend.phpincludes/classes/class-rest-api.php
**/*.js
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.js: Strings in JavaScript also need translation support using wp.i18n functions
Gracefully handle JavaScript errors to avoid breaking accessibility features
Files:
src/frontendHighlighterApp/index.js
**/*.{css,js}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Support RTL languages where applicable
Files:
src/frontendHighlighterApp/index.js
src/**/*.js
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
src/**/*.js: Focus management implemented
Minimize DOM operations in JavaScript for frontend scanning
Files:
src/frontendHighlighterApp/index.js
**/[a-z]*.js
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
JavaScript Utilities: utilityName.js
Files:
src/frontendHighlighterApp/index.js
**/[A-Z]*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/[A-Z]*.php: Class names use CamelCase (ClassNameConvention) for new classes
File names use ClassNameConvention.php for new classes (CamelCase)
Classes: ClassName.php
Files:
tests/phpunit/includes/classes/RestApiEndpointsTest.php
tests/phpunit/**/*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
tests/phpunit/**/*.php: Write unit tests for new PHP functions and classes
Add integration tests for major features and accessibility rules
Files:
tests/phpunit/includes/classes/RestApiEndpointsTest.php
{changelog.txt,readme.txt}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Update changelog.txt and readme.txt for each release
Files:
readme.txt
accessibility-checker.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Implement proper activation/deactivation hooks
Files:
accessibility-checker.php
🧠 Learnings (3)
📚 Learning: 2025-08-04T16:46:23.515Z
Learnt from: CR
PR: equalizedigital/accessibility-checker#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-04T16:46:23.515Z
Learning: Applies to tests/phpunit/**/*.php : Add integration tests for major features and accessibility rules
Applied to files:
tests/phpunit/includes/classes/RestApiEndpointsTest.php
📚 Learning: 2025-07-18T01:29:35.548Z
Learnt from: SteveJonesDev
PR: equalizedigital/accessibility-checker#1088
File: includes/classes/Rules/Rule/EmptyParagraphTagRule.php:50-50
Timestamp: 2025-07-18T01:29:35.548Z
Learning: In the Accessibility Checker plugin, the 'wcag' field can use custom values like '0.1' to represent best practice rules and manual testing requirements that don't map directly to specific WCAG success criteria but are still important for accessibility compliance.
Applied to files:
accessibility-checker.php
📚 Learning: 2025-07-18T01:18:27.812Z
Learnt from: SteveJonesDev
PR: equalizedigital/accessibility-checker#1088
File: includes/classes/Rules/Rule/VideoPresentRule.php:41-42
Timestamp: 2025-07-18T01:18:27.812Z
Learning: In the Accessibility Checker plugin, the 'wcag' field can use custom values like '0.3' to represent best practice rules and manual testing requirements that don't map directly to specific WCAG success criteria but are still important for accessibility compliance.
Applied to files:
accessibility-checker.php
🧬 Code graph analysis (1)
tests/phpunit/includes/classes/RestApiEndpointsTest.php (1)
admin/class-update-database.php (2)
Update_Database(16-82)edac_update_database(36-81)
🪛 LanguageTool
readme.txt
[grammar] ~6-~6: There might be a mistake here.
Context: ...6.6 Tested up to: 6.8 Stable tag: 1.30.1 License: GPLv2 or later License URI: htt...
(QB_NEW_EN)
🔇 Additional comments (11)
accessibility-checker.php (1)
13-13: Versions updated correctly; ship it.Header Version and EDAC_VERSION constant both read 1.30.1. Nice and tight.
Run the version sync script I dropped on package.json to confirm everything matches across files.
Also applies to: 39-39
readme.txt (1)
6-6: Stable tag synced to 1.30.1—on point.This matches the plugin header and constant updates. Keep those numbers marching together every release.
src/frontendHighlighterApp/index.js (1)
419-419: Class toggle for single-button state looks good.The conditional class injection based on edit capability reads clean and pairs correctly with the new gating.
includes/classes/class-rest-api.php (4)
82-87: Route args hardened: required + absint.Good tightening on path params. Required + sanitize at the route layer reduces downstream footguns.
Also applies to: 176-181
89-91: Centralized per-post permission check is the right move.Delegating to a single helper keeps permission logic consistent across endpoints.
Also applies to: 183-185
232-232: Docblock cleanup is accurate.Using fully-qualified WP_REST_Request in the docblock aligns with the rest of the file.
107-107: Stats endpoints: admin‐only consumers confirmed, safe to bump capabilitiesI’ve verified that all calls to
/scans-stats*and/clear-cached-scans-statsoriginate exclusively from the admin-bundled script (admin.bundle.jsviaedacScriptVars.edacApiUrl). No front-end or public-facing bundles reference these endpoints. Raising the permission toedit_posts/publish_poststherefore only affects users with access to the admin UI and will not break any public or third-party integrations.Action items:
- Add a note in CHANGELOG.md about the increased capability requirement.
- Update documentation to reflect the new
edit_posts/publish_postsprerequisites.tests/phpunit/includes/classes/RestApiEndpointsTest.php (4)
72-94: Fixture setup is pragmatic and stable.Enabling scannable post types and ensuring the plugin table exists avoids flaky tests. Good hustle.
101-135: Admin vs limited user on post-scan-results: on point.Nice minimal payload and clear assertions on 200 vs 403. This covers the new permission helper well.
142-170: Clear-issues permissions test is crisp.Good use of JSON body and headers; assertions map cleanly to the REST behavior.
47-53: Routes are properly registered in the plugin bootstrap
I’ve confirmed that the plugin’s main initialization instantiatesREST_Apiand immediately calls itsinit_hooks()method, ensuring all REST routes are hooked intorest_api_initbefore any dispatch occurs. The test’s calls todo_action( 'init' ); do_action( 'rest_api_init' ); $this->server = rest_get_server();therefore correctly register your routes in the test context. No further changes are needed.
| { | ||
| "name": "accessibility-checker", | ||
| "version": "1.30.0", | ||
| "version": "1.30.1", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Version bump looks clean; keep the release numbers in lockstep.
1.30.1 here matches the PR intent. Make sure the plugin header, EDAC_VERSION, and readme stable tag all say 1.30.1 so no one gets tripped up by mismatched versions.
Run this to verify all the version surfaces are in sync (expected: 1.30.1):
🏁 Script executed:
#!/bin/bash
set -euo pipefail
expected="1.30.1"
echo "Checking versions…"
pkg=$(jq -r .version package.json)
php_header=$(rg -nP '^\s*\*\s*Version:\s*([0-9.]+)' -or '$1' accessibility-checker.php | head -n1)
php_const=$(rg -nP "define\(\s*'EDAC_VERSION'\s*,\s*'([^']+)'\s*\)" -or '$1' accessibility-checker.php | head -n1)
readme=$(rg -nP '^Stable tag:\s*([0-9.]+)' -or '$1' readme.txt | head -n1)
printf "package.json: %s\nplugin header: %s\nEDAC_VERSION: %s\nreadme stable tag: %s\n" \
"$pkg" "$php_header" "$php_const" "$readme"
test "$pkg" = "$expected" && test "$php_header" = "$expected" && test "$php_const" = "$expected" && test "$readme" = "$expected" \
&& echo "OK: versions match $expected" || { echo "Mismatch detected"; exit 1; }Length of output: 797
Update version-check script to strip line numbers
The actual version strings in package.json, the plugin header (accessibility-checker.php), the EDAC_VERSION constant, and the readme.txt stable tag are all set to 1.30.1, but the verification script is pulling in line-number prefixes (e.g. 13:1.30.1), causing a false “Mismatch detected.”
• Remove the -n flag from each rg invocation so it only emits the captured group. For example:
- php_header=$(rg -nP '^\s*\*\s*Version:\s*([0-9.]+)' -or '$1' accessibility-checker.php | head -n1)
+ php_header=$(rg -P '^\s*\*\s*Version:\s*([0-9.]+)' -or '$1' accessibility-checker.php | head -n1)
- php_const=$(rg -nP "define\(\s*'EDAC_VERSION'\s*,\s*'([^']+)'\s*\)" -or '$1' accessibility-checker.php | head -n1)
+ php_const=$(rg -P "define\(\s*'EDAC_VERSION'\s*,\s*'([^']+)'\s*\)" -or '$1' accessibility-checker.php | head -n1)
- readme=$(rg -nP '^Stable tag:\s*([0-9.]+)' -or '$1' readme.txt | head -n1)
+ readme=$(rg -P '^Stable tag:\s*([0-9.]+)' -or '$1' readme.txt | head -n1)• After this change, re-run the script to confirm you get:
OK: versions match 1.30.1
With that tweak, your version bump verification will be rock-solid, fool!
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "version": "1.30.1", | |
| # In your version-check script, replace these lines: | |
| - php_header=$(rg -nP '^\s*\*\s*Version:\s*([0-9.]+)' -or '$1' accessibility-checker.php | head -n1) | |
| - php_const=$(rg -nP "define\(\s*'EDAC_VERSION'\s*,\s*'([^']+)'\s*\)" -or '$1' accessibility-checker.php | head -n1) | |
| - readme=$(rg -nP '^Stable tag:\s*([0-9.]+)' -or '$1' readme.txt | head -n1) | |
| # with these lines: | |
| php_header=$(rg -P '^\s*\*\s*Version:\s*([0-9.]+)' -or '$1' accessibility-checker.php | head -n1) | |
| php_const=$(rg -P "define\(\s*'EDAC_VERSION'\s*,\s*'([^']+)'\s*\)" -or '$1' accessibility-checker.php | head -n1) | |
| readme=$(rg -P '^Stable tag:\s*([0-9.]+)' -or '$1' readme.txt | head -n1) |
🤖 Prompt for AI Agents
In package.json around line 3, the version-check script is failing because
ripgrep (rg) is invoked with the -n flag which prefixes results with line
numbers (e.g. "13:1.30.1") causing false mismatches; edit the script(s) that
extract versions to remove the -n flag from each rg invocation so rg outputs
only the captured group (the version string), then re-run the verification to
confirm it reports "OK: versions match 1.30.1".
Checklist
Summary by CodeRabbit
Bug Fixes
Tests
Documentation
Chores