Repository navigation
Conversation
The settings endpoint cached the current user's WordPress.com email subscription in a single site option, so every admin read whichever value was saved last. Key the local copy by user ID, as Post by Email already does, and stop caching a failed lookup.
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 2 files.
|
Neither lookup leaves an error or null in the value now, so Phan flagged the comparison as impossible.
Fixes JETPACK-2962
Proposed changes
jetpack/v4/settingsreturnsmonitor_receive_notificationsfrom a local copy of the user's WordPress.com email subscription. That copy was a single site option, so every admin read whichever value was saved last. It is now keyed by user ID, the same waypost_by_email_addressalready is.1/0.update_option()won't create an option whose value isfalse, which meant an "off" answer was never saved and was fetched again on every settings request.Nothing in trunk binds a toggle to this value today (Settings → Security only has the module toggle), so this is inherited rather than new. The Monitor card in PR 53194 is the first UI to show it, and it needs no change: it already reads this setting.
The old shared
monitor_receive_notificationsoption is no longer read or written. I left it in place, and left the name in the Sync options list.Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
You need a site connected to WordPress.com with two admins, each connected to their own WordPress.com account, and Monitor active. Check out PR 53194 with this branch merged in to use the Monitor card, or use the API directly as below.
POST /wp-json/jetpack/v4/settingswith{ "monitor_receive_notifications": true }.GET /wp-json/jetpack/v4/settingsand checkmonitor_receive_notifications. A seestrue, B seesfalse. On trunk both seefalse.false, andwp option get monitor_receive_notifications<their user ID>shows nothing was saved for them.