Add new cache clearing structure for option actions. This new structure will consolidate the handling when certain option-related hooks are fired. In addition, Cache Enabler will now clear the cache when certain core options are about to be updated or already have been. This should be one of the last cache clearing structures required to cover the core. Over the last few versions, primarily 1.5.0 and what will be 1.8.0, we have made a lot of progress towards a comprehensive, automatic cache clearing system. In other words, clear cached pages only when they should be cleared. If someone knows of other core-related actions that are not covered please let me know. What we cover now should provide a great base going forward. Additional automatic cache clearing for specific plugin actions can be added by extending the plugin. It is easy to add custom behavior to Cache Enabler, however, it will become much easier once the return handling and additional hooks are added in the next versions. At that point we may have extension/add-on support that will then allow specific plugin coverage.
This PR includes a reworked Cache_Enabler::each_site() method due to fixing a bug introduced in PR #271 and PR #260 for multisite networks that do not have Cache Enabler network activated. When the Cache_Enabler::update() method was added in PR #260 this was calling the Cache_Enabler::update_backend() on all sites. I forgot to ensure that this was only called on the sites with Cache Enabler active. Before #271 this would have added the option to the database, which would then trigger the settings file to be created. At that point the pages could have been cached even when Cache Enabler was not activated. Once #271 rolled in with the engine restart it would cause an infinite loop when switching to a site that did not have the cache_enabler option or if this value was outdated (from being previously activated). That would occur because when Cache_Enabler::get_settings() was called it would think the settings do not exist or are outdated, leading to Cache_Enabler::update() being called again. Oops. To fix that issue we will only run the callback and restart the engine in Cache_Enabler::each_site() when the plugin is active or if the original site calling Cache_Enabler::each_site() is inactive. When $skip_active_check is true that means the original site was inactive. That looks like the following:
Plugin being activated: $skip_active_check === true;
Currently active: $skip_active_check === false;
Plugin being uninstalled: $skip_active_check === true;
Must-use plugin: $skip_active_check === true;
The Cache_Enabler::is_cache_enabler_active() method was added because is_plugin_active() is not always available when we require it (it only loads in the admin and at a later point of time than when we need it).
This PR also fixes the update made to Cache_Enabler::requirements_check() in PR #260. When calling Cache_Enabler_Disk::create_advanced_cache_file() we need to check for false when displaying that notice. Otherwise the notice will be shown once even though the advanced cache file was just created.
Add new cache clearing structure for option actions. This new structure will consolidate the handling when certain option-related hooks are fired. In addition, Cache Enabler will now clear the cache when certain core options are about to be updated or already have been. This should be one of the last cache clearing structures required to cover the core. Over the last few versions, primarily 1.5.0 and what will be 1.8.0, we have made a lot of progress towards a comprehensive, automatic cache clearing system. In other words, clear cached pages only when they should be cleared. If someone knows of other core-related actions that are not covered please let me know. What we cover now should provide a great base going forward. Additional automatic cache clearing for specific plugin actions can be added by extending the plugin. It is easy to add custom behavior to Cache Enabler, however, it will become much easier once the return handling and additional hooks are added in the next versions. At that point we may have extension/add-on support that will then allow specific plugin coverage.
This PR includes a reworked
Cache_Enabler::each_site()method due to fixing a bug introduced in PR #271 and PR #260 for multisite networks that do not have Cache Enabler network activated. When theCache_Enabler::update()method was added in PR #260 this was calling theCache_Enabler::update_backend()on all sites. I forgot to ensure that this was only called on the sites with Cache Enabler active. Before #271 this would have added the option to the database, which would then trigger the settings file to be created. At that point the pages could have been cached even when Cache Enabler was not activated. Once #271 rolled in with the engine restart it would cause an infinite loop when switching to a site that did not have thecache_enableroption or if this value was outdated (from being previously activated). That would occur because whenCache_Enabler::get_settings()was called it would think the settings do not exist or are outdated, leading toCache_Enabler::update()being called again. Oops. To fix that issue we will only run the callback and restart the engine inCache_Enabler::each_site()when the plugin is active or if the original site callingCache_Enabler::each_site()is inactive. When$skip_active_checkistruethat means the original site was inactive. That looks like the following:$skip_active_check === true;$skip_active_check === false;$skip_active_check === true;$skip_active_check === true;The
Cache_Enabler::is_cache_enabler_active()method was added becauseis_plugin_active()is not always available when we require it (it only loads in the admin and at a later point of time than when we need it).This PR also fixes the update made to
Cache_Enabler::requirements_check()in PR #260. When callingCache_Enabler_Disk::create_advanced_cache_file()we need to check forfalsewhen displaying that notice. Otherwise the notice will be shown once even though the advanced cache file was just created.