[rahultank-spaceo]

Fixes #687.

wp option set-autoload refreshed the caches the way update_option() does for a value change. So after the autoload value changed, the option stayed in, or out of, the cached alloptions. With a persistent object cache, an option set to off kept loading on every request, and a later delete_option() left its old value behind.

The command now refreshes the cache the same way core's wp_set_option_autoload_values() does:

• to on or yes: it deletes the option's own cache and alloptions, so alloptions is rebuilt on the next load;
• to off or no: it removes the option from the cached alloptions.

I kept the command's own query instead of calling wp_set_option_autoload(). That way there is no version check or fallback for WordPress before 6.4 (see the comment on the issue), and yes/no are still stored as given, as the existing scenarios expect. Core would store on/off.

Testing

The new scenario reproduces the bug without a persistent object cache. It runs the command in the same process with WP_CLI::runcommand( ..., array( 'launch' => false ) ), so the in-memory cache keeps alloptions between the two calls. With SQLite and WordPress 7.1.4, features/option-set-autoload.feature passes on this branch (4 scenarios). With the old src/Option_Command.php, the new scenario fails: the first var_dump() prints bool(true). PHPCS and the linter pass on the change.

I also ran the old and new set_autoload() code on WordPress 7.2-beta4, in one request, with the option cached first:

Change	Before	After
on → off	still in cached alloptions	removed
off → on	missing from cached alloptions	added
yes → no	still in cached alloptions	removed
no → yes	missing from cached alloptions	added
delete_option() after off	get_option() returns the old value	returns the default

AI assistance: Yes. An AI assistant helped write the change and this description. I reviewed the code and the test results.

Summary by CodeRabbit

• Bug Fixes
  • Updating an option’s autoload setting now keeps the cached options in sync during the same request. Options switched off autoloading are removed from the autoloaded cache, while options switched on are reflected there, preventing stale cache contents after the change.

[github-actions]

Hello! 👋

Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project.

Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Here are some useful Composer commands to get you started:

• composer install: Install dependencies.
• composer test: Run the full test suite.
• composer phpcs: Check for code style violations.
• composer phpcbf: Automatically fix code style violations.
• composer phpunit: Run unit tests.
• composer behat: Run behavior-driven tests.

To run a single Behat test, you can use the following command:

# Run all tests in a single file
composer behat features/some-feature.feature

# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123

You can find a list of all available Behat steps in our handbook.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

option set-autoload now updates option caches according to the new autoload value. A WordPress 6.6+ scenario checks that switching foo off removes it from alloptions, and switching baz on adds it.

Changes: Option autoload cache

Layer / File(s)	Summary
Refresh and verify option caches src/Option_Command.php, features/option-set-autoload.feature	When WP_INSTALLING is undefined, autoload values on and yes cause the command to delete the option-specific cache entry and alloptions. Other values cause it to reload alloptions and remove the option if present. The WordPress 6.6+ scenario checks both transitions.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested labels: bug, scope:testing

Suggested reviewers: mrsdizzie, danielbachhuber

Merge Risk: Minimal · up to c659e

No actionable issue remains in the supplied review; the change is mergeable after normal checks.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly describes the main change to the alloptions cache in wp option set-autoload.
Linked Issues check		[#687] set_autoload() removes an option from alloptions for off or no. For on or yes, it deletes the individual cache entry and invalidates alloptions for the next load. The new same-req…
Out of Scope Changes check		[#687] The cache changes and regression scenario address the linked issue. The PR does not change the separate option list --autoload behavior in #670.
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…

Full details: Linked Issues check

Explanation

[#687] set_autoload() removes an option from alloptions for off or no. For on or yes, it deletes the individual cache entry and invalidates alloptions for the next load. The new same-request scenario tests both cache transitions. The command retains its existing database query and stores the supplied value.

Full details: Docstring Coverage

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.)

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Tip

🎯 Customize your risk assessments

Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.

✅ Automatic approvals, with your rules

Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 018a481f-3618-4092-81ba-8d109c4fcaad

Commits

Reviewing files that changed from the base of the PR and between 47ff5a1 and c659e1e.

Files selected for processing: 2

• features/option-set-autoload.feature
• src/Option_Command.php

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!