Repository navigation
Prevent maintenance mode from changing front page setting - #565
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
The new override ignores existing bot and system-request bypass rules, potentially serving maintenance content to exempt requests.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Prevents maintenance mode from permanently modifying WordPress’s front-page setting.
Changes:
- Replaces persisted
show_on_frontchanges with a request-time filter. - Adds regression coverage for visitor/admin option behavior.
File summaries
| File | Description |
|---|---|
includes/classes/wp-maintenance-mode.php |
Adds conditional front-page override. |
tests/page-state-test.php |
Tests preservation of Reading settings. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 2
- Review effort level: Balanced (auto)
Note
Copilot is running an experiment and ran this review at Balanced.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| add_filter( | ||
| 'pre_option_show_on_front', | ||
| function ( $value ) { | ||
| if ( ( ! $this->check_user_role() && ! $this->check_exclude() ) && isset( $this->plugin_settings['design']['page_id'] ) && get_option( 'wpmm_new_look' ) ) { |
| wp_set_current_user( 0 ); | ||
| $this->boot_plugin( $this->make_settings( 1, $page_id ) ); | ||
|
|
||
| $this->assertSame( 'page', get_option( 'show_on_front' ) ); |
|
One or more custom setup steps configured for this repository failed during this Copilot code review run: Setup steps run before each review. If the review above is missing context, or no review was posted at all, the failing step above may be the cause. See the workflow run for failure details, fix your setup steps configuration, and re-request a review. Note You can configure setup steps for Copilot code review separately from Copilot cloud agent with a |
|
I think is better to store the initial value in a new option and use that on deactivation. |
There was a problem hiding this comment.
🟢 Approved
The change records show_on_front once, restores it on disable and deactivation, and the shipped tests verify both paths.
Validation details
- Files reviewed: 4/4 changed files.
- PHPUnit on HEAD:
vendor/bin/phpunit --filter 'Test_Page_State::'on PHP 8.3.33 with the WordPress 7.1.1 test library. Result:OK (25 tests, 71 assertions). - Tests against the base tree: both changed tests fail on
pr-basewithFailed asserting that false is identical to 'posts'. They test the change. - Security pass: no new trust boundary. The recorded value comes from the core option, and the branch depends on the admin-only
wpmm_settingsoption. - Callers:
single_deactivate()runs from the deactivation hook, including the multisite loop.helpers.phploads before the hook.
Untested areas
- Upgrade with maintenance mode already active: the base code already set
show_on_fronttopage. The new code recordspageon such sites, so disabling keepspage. This matches the base behavior and is not a regression. - Multisite deactivation: not executed. The test library ran in single-site mode.
- No browser check: the change is options-only logic.
🤖 Automated review · run code-review-agent_6ab0bb683dbdf8.14783870
🤖 Review agent — review posted ✅ on 1d0856e6 · approved · 0 findings · 8 min
Run code-review-agent_6ab0bb683dbdf8.14783870 · trail
|
@copilot resolve the merge conflicts in this pull request |
…ve-show-on-front # Conflicts: # includes/functions/helpers.php Co-authored-by: pirate-bot <58979018+pirate-bot@users.noreply.github.com>
Merged |
Summary
Testing
Fixes #564