Fix: use correct post ID when site homepage is set to latest posts (PRO-726)#1727
Conversation
When show_on_front=posts, WordPress sets the global $post to the first blog post rather than a page object. Both the frontend highlighter and the admin editor app were passing that post's ID to scan storage, attributing homepage issues to the wrong entry. Frontend: pass null (not the first post's ID) to edac_filter_frontend_highlight_post_id when is_home() && is_front_page() && show_on_front=posts, so the free plugin bails cleanly and Pro can supply a virtual-page ID via the filter. Admin: add edac_filter_admin_post_id so extensions can correct the post ID when the FSE site editor sets $post to the first blog post. Add edac_filter_post_is_latest_posts_home so Pro can flag a virtual homepage page and trigger use of get_home_url() for the scanner iframe instead of an invalid preview URL. Fixes PRO-726 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdmin/editor and frontend enqueue logic now filter computed post IDs, handle latest-posts homepage context, recompute editor activation from the filtered post type, and generate home-URL-based scan targets. PHPUnit tests cover these behaviors. ChangesHomepage Post ID Attribution and Scan URL Filtering
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fcd70333da
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces filters and logic to correctly handle post IDs and scan URLs when the homepage is configured to display the latest posts, along with corresponding PHPUnit tests. The reviewer identified two critical issues with the conditional checks used to detect the latest posts homepage: first, checking page_for_posts strictly against 0 can fail due to leftover database values and bypasses fallback scenarios; second, checking 'posts' === get_option( 'show_on_front' ) alongside is_home() && is_front_page() is redundant and fails when WordPress falls back to latest posts under a 'page' configuration. Robust code suggestions were provided to address these edge cases.
- Remove redundant show_on_front check in frontend highlighter; rely on is_home() && is_front_page() to cover both the explicit "latest posts" setting and the fallback where show_on_front=page with no page_on_front - Broaden $is_latest_posts_home condition in admin enqueue to include the same fallback case (show_on_front=page but page_on_front is empty) - Recompute $active from the filtered $post_id's post type so extensions that override the post ID via edac_filter_admin_post_id get a correct active flag rather than one based on the pre-filter global $post - Add tests covering the fallback homepage case and the $active recomputation Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/phpunit/Admin/EnqueueAdminTest.php (1)
427-432:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd WordPress version handling for slash escaping compatibility.
The assertion at line 431 checks for the unescaped home URL in the localized data. In WordPress < 6.9,
wp_json_encode()escapes forward slashes (/becomes\/), so this assertion will fail. Existing tests at lines 170–174 and 202–206 handle this by checking the WordPress version and conditionally escaping slashes.🔧 Proposed fix
$localized_data = $wp_scripts->get_data( 'edac-editor-app', 'data' ); $this->assertStringContainsString( 'edac_pageScanner', $localized_data ); $this->assertStringNotContainsString( 'preview=true', $localized_data ); - // The scan URL should be based on the home URL, not a preview link. - $this->assertStringContainsString( trailingslashit( get_home_url() ), $localized_data ); + // The scan URL should be based on the home URL, not a preview link. + // In WP 6.9 there were changes to the flags passed to wp_json_encode() that made slashes no longer get escaped by default. + // We should check for both possibilities here to ensure compatibility across versions. + // See: https://github.com/WordPress/wordpress-develop/pull/9557 for more details. + if ( version_compare( get_bloginfo( 'version' ), '6.9', '>=' ) ) { + $this->assertStringContainsString( trailingslashit( get_home_url() ), $localized_data ); + } else { + $this->assertStringContainsString( str_replace( '/', '\\/', trailingslashit( get_home_url() ) ), $localized_data ); + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/phpunit/Admin/EnqueueAdminTest.php` around lines 427 - 432, The assertion expecting the raw home URL in $localized_data fails on WP < 6.9 because wp_json_encode() escapes forward slashes; update the test to mirror other checks by detecting the WP version and using an escaped home URL when needed: compute $expected_home = trailingslashit( get_home_url() ) and if the WP version is less than 6.9 (use function_exists('wp_version') or global $wp_version comparison) replace '/' with '\/' in $expected_home, then assertStringContainsString($expected_home, $localized_data) instead of asserting the unescaped value directly.
🧹 Nitpick comments (1)
tests/phpunit/Admin/EnqueueAdminTest.php (1)
460-461: 💤 Low valueConsider adding
page_on_frontto cleanup for consistency.Although
page_on_frontwas deleted at line 451 and doesn't need restoration, explicitly includingdelete_option( 'page_on_front' )in the cleanup section would mirror the pattern used intestScanUrlUsesHomeUrlWhenLatestPostsHomeFilterReturnsTrue()(lines 424–425) and make the cleanup intent clearer.♻️ Proposed cleanup addition
remove_filter( 'edac_filter_post_is_latest_posts_home', $filter_callback ); delete_option( 'show_on_front' ); + delete_option( 'page_on_front' ); $localized_data = $wp_scripts->get_data( 'edac-editor-app', 'data' );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/phpunit/Admin/EnqueueAdminTest.php` around lines 460 - 461, Add an explicit deletion of the page_on_front option in the test cleanup to mirror the existing pattern: after remove_filter('edac_filter_post_is_latest_posts_home', $filter_callback) and delete_option('show_on_front'), also call delete_option('page_on_front') so the test's teardown mirrors testScanUrlUsesHomeUrlWhenLatestPostsHomeFilterReturnsTrue() and makes intent explicit.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/phpunit/Admin/EnqueueAdminTest.php`:
- Around line 463-468: Update the failing assertion to handle WP <6.9
slash-escaping by checking for either the raw home URL or its JSON-encoded
(slash-escaped) form in $localized_data: compute the home URL via
trailingslashit(get_home_url()), compute the JSON-encoded variant via
wp_json_encode(...), and replace the single assertStringContainsString(...) call
with an assertion that passes if $localized_data contains either the raw home
URL or the wp_json_encode() result (use strpos/boolean assertion or two
assertStringContainsString checks combined with assertTrue/|| to accept both
formats).
---
Outside diff comments:
In `@tests/phpunit/Admin/EnqueueAdminTest.php`:
- Around line 427-432: The assertion expecting the raw home URL in
$localized_data fails on WP < 6.9 because wp_json_encode() escapes forward
slashes; update the test to mirror other checks by detecting the WP version and
using an escaped home URL when needed: compute $expected_home = trailingslashit(
get_home_url() ) and if the WP version is less than 6.9 (use
function_exists('wp_version') or global $wp_version comparison) replace '/' with
'\/' in $expected_home, then assertStringContainsString($expected_home,
$localized_data) instead of asserting the unescaped value directly.
---
Nitpick comments:
In `@tests/phpunit/Admin/EnqueueAdminTest.php`:
- Around line 460-461: Add an explicit deletion of the page_on_front option in
the test cleanup to mirror the existing pattern: after
remove_filter('edac_filter_post_is_latest_posts_home', $filter_callback) and
delete_option('show_on_front'), also call delete_option('page_on_front') so the
test's teardown mirrors
testScanUrlUsesHomeUrlWhenLatestPostsHomeFilterReturnsTrue() and makes intent
explicit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d4705e25-34ec-4aca-9388-e8bfb55fb1cd
📒 Files selected for processing (3)
admin/class-enqueue-admin.phpincludes/classes/class-enqueue-frontend.phptests/phpunit/Admin/EnqueueAdminTest.php
🚧 Files skipped from review as they are similar to previous changes (2)
- includes/classes/class-enqueue-frontend.php
- admin/class-enqueue-admin.php
wp_localize_script serializes PHP false as an empty string ("") rather
than JSON false in current WP versions, so match either form in the
regex to keep the test passing across WP releases.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
WP < 6.9 escapes forward slashes as \/ in json_encode output, so asserting the literal home URL string fails on those builds. Apply the same version-conditional str_replace pattern already used by the existing permalink tests. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
✅ Accessibility Checker build (primary only)
|
Reduce the added inline comments and test docblocks to 1-2 sentences, drop the ephemeral "Before Fix 3" reference, and restore the pull/9557 URL that had a stray period inserted. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…/pro-726-when-site-has-latest-posts-set-as-the-home-location-the-scan # Conflicts: # tests/phpunit/includes/classes/EnqueueFrontendTest.php
2 participants
Fixes the bug where scanning the homepage (when configured as "latest posts") attributed scan results to the first blog post instead of the homepage.
What changed and why
Root cause: When
show_on_front=posts, WordPress populates the global\$postwith the first blog post from the main query — not a page object. Both the frontend highlighter and the admin editor app read\$post->IDand passed it on as the page identifier, so scan results were stored under the first post's ID rather than the homepage.includes/classes/class-enqueue-frontend.phpBefore calling
edac_filter_frontend_highlight_post_id, the code now detects the "latest posts" homepage viais_home() && is_front_page() && show_on_front=postsand passesnullinstead of the first post's ID. For the free plugin this causes a clean bail (highlighter doesn't load on the homepage). Pro can hook the existing filter and return a virtual-page ID to restore the correct behaviour.admin/class-enqueue-admin.phpTwo additions:
edac_filter_admin_post_id— applied right after\$post_idis read so extensions (e.g. Pro) can supply the correct ID when the FSE site editor sets\$postto the first blog post while previewing the home template.edac_filter_post_is_latest_posts_home— in the scan-URL logic: whenshow_on_front=posts,page_for_posts=0, and the filter returnstrue, the scanner iframe usesget_home_url()instead of an invalid preview URL. This gives Pro a clean extension point for its virtual homepage page.Reviewer notes
testScanUrlUsesPermalinkForFrontpage,testScanUrlUsesPermalinkForPostsPage,testScanUrlUsesPreviewLinkForRegularPost) are unaffected.Checklist
Summary by CodeRabbit