Changing settings can result in erroneous notices regarding post types #1302
@westonruter Did you happen to notice which post types were selected? Was it just the default of
I was able to reproduce the notice blasting conditions when upgrading from 0.7 to 1.0-beta2 but only when the default post type of 'Posts` was selected (none of the others). Then upon upgrading and switching from Classic to Paired or Native, the notice blasts occurred.
Click on this GIF to watch the steps I went through to reproduce the problem upon upgrade:
When first switching from Classic to Paired or Native, notice that the
We should revisit what state we want that
Yes, just Posts was selected, and forcibly so since the checkbox is
Yes, the two options you've outlined seem perfect. If all post types were not selected when upgrading to 1.0, then
When the plugin's version changes and the options are empty (meaning no options were stored previously), then `set all_templates_supported` to `false`. Why? On version change and when: 1. no options were previously saved 2. switching from classic to either paired or native then the settings page was blasted with erroneous admin notices. See issue #1302. This commit fixes that edge case. Why not use `upgrader_process_complete` hook? This hook works when updating from the WordPress.org plugin directory. However, when working with bleeding edge, we need to validate during the options manager init cycle.
Upon deeper investigation, the notice blasts occur when:
It's not directly linked to upgrading, although it does occur when upgrading. At first I walked down that path to fix the upgrade process and setting
Now, I believe the root cause is in how or when we are validating the supported post types against the theme/plugin and what has been selected. There is a linkage between
Fixes #1302. In the `check_supported_post_type_update_errors()` method, when `all_templates_supported` option is selected, we want to use all of the eligible post types and not just the ones that are individually selected. In doing so, this commit fixes #1302 where it blasts erroneous notices about unable to deactivate supported post types.