Add the ability to restart the engine, allowing the engine settings to be updated in addition to reinitializing the rewrite rules. This will allow the original site rewrite rules to be picked up after restore_current_blog() is called. This cannot be completely handled in the cache iterator because there are cases where we switch the site before calling the cache iterator. We only switch the site in the cache iterator itself if it was not switched beforehand, like when using WP-CLI. This change will allow the engine settings stored in the Cache_Enabler_Engine::$settings class property to be updated when switching between blogs. I have only had a few cases where this was necessary in the past but came up with different solutions instead as restarting the engine was not worth it at the time. That is no longer the case. Having this property be updated is not something Cache Enabler requires as of this commit, but we will likely need this in the future. For now it is primarily used to ensure the current WP_Rewrite instance is from the current site and not the original site before the switch.
This addition started with the issue of potentially pulling the wrong pagination bases in the Cache_Enabler::clear_page_cache_by_url() method. To ensure we are always getting the correct data this has been moved to the Cache_Enabler_Disk::get_cache_iterator_args() method (along with the wildcard path handling added in PR #246). Cache_Enabler_Disk::get_cache_iterator_args() will only be called after the rewrite instance has been potentially reinitialized, which will ensure the correct pagination bases are used. (It is highly unlikely these are different between sites but you never know.) Since we may restore the current blog after the cache iterator that resulted in the need for restarting the cache engine. This will fix the issue brought in PR #251 where the rewrite rules reinitialized could have been from the last blog switched to before calling the cache iterator. For example, if site 1, 2, and 3 were cleared using Cache_Enabler::clear_complete_cache() that would result in the WP_Rewrite instance from site 3 after switching back to site 1. Now, whether the blog is switched beforehand or in the cache iterator, the WP_Rewrite instance will be as it was before we caused it to be updated.
The change made in PR #263 will remain for now as I still do not think it is worth restarting the engine for the one option that would require this engine restart (use_trailing_slashes).
Add the ability to restart the engine, allowing the engine settings to be updated in addition to reinitializing the rewrite rules. This will allow the original site rewrite rules to be picked up after
restore_current_blog()is called. This cannot be completely handled in the cache iterator because there are cases where we switch the site before calling the cache iterator. We only switch the site in the cache iterator itself if it was not switched beforehand, like when using WP-CLI. This change will allow the engine settings stored in theCache_Enabler_Engine::$settingsclass property to be updated when switching between blogs. I have only had a few cases where this was necessary in the past but came up with different solutions instead as restarting the engine was not worth it at the time. That is no longer the case. Having this property be updated is not something Cache Enabler requires as of this commit, but we will likely need this in the future. For now it is primarily used to ensure the currentWP_Rewriteinstance is from the current site and not the original site before the switch.This addition started with the issue of potentially pulling the wrong pagination bases in the
Cache_Enabler::clear_page_cache_by_url()method. To ensure we are always getting the correct data this has been moved to theCache_Enabler_Disk::get_cache_iterator_args()method (along with the wildcard path handling added in PR #246).Cache_Enabler_Disk::get_cache_iterator_args()will only be called after the rewrite instance has been potentially reinitialized, which will ensure the correct pagination bases are used. (It is highly unlikely these are different between sites but you never know.) Since we may restore the current blog after the cache iterator that resulted in the need for restarting the cache engine. This will fix the issue brought in PR #251 where the rewrite rules reinitialized could have been from the last blog switched to before calling the cache iterator. For example, if site 1, 2, and 3 were cleared usingCache_Enabler::clear_complete_cache()that would result in theWP_Rewriteinstance from site 3 after switching back to site 1. Now, whether the blog is switched beforehand or in the cache iterator, theWP_Rewriteinstance will be as it was before we caused it to be updated.The change made in PR #263 will remain for now as I still do not think it is worth restarting the engine for the one option that would require this engine restart (
use_trailing_slashes).