cache_enabler_clear_complete_cache action hook will replace deprecated ce_clear_cache and when fired will clear the complete cache.
cache_enabler_clear_site_cache is a new action hook that when fired will clear the current site cache (supports both single and multisites).
cache_enabler_clear_site_cache_by_blog_id is a new action hook that when fired will clear the site cache of the given $blog_id.
cache_enabler_clear_page_cache_by_post_id action hook will replace deprecated ce_clear_post_cache and when fired will clear the page cache of the given $post_id.
cache_enabler_clear_page_cache_by_url is a new action hook that when fired will clear the page cache of the given $clear_url.
cache_enabler_user_can_clear_cache filter hook will replace deprecated user_can_clear_cache and will allow the required user permissions to clear the cache through the admin bar buttons be changed.
cache_enabler_exclude_search filter hook is new and will allow disabling the default behavior of excluding search pages from the cache (#83). For search pages to currently be cached it would require the search URL to be changed from ?s=query to something like /search/query/. Automatically clearing the search cache has not been added at this time.
cache_enabler_bypass_cache filter hook will replace deprecated bypass_cache and will allow the cache to be bypassed.
cache_enabler_page_contents_before_store filter hook will replace deprecated cache_enabler_before_store and will allow the page contents to be filtered before trying to store the cached page.
cache_enabler_page_contents_after_webp_conversion filter hook will replace deprecated cache_enabler_disk_webp_converted_data and will allow the page contents to be filtered after inline image URLs have maybe been converted. Now that nearly all inline image URLs are rewritten, including those invoked with inline CSS, it is likely this hook is not needed as often as before.
cache_enabler_minify_html_ignore_tags filter hook will replace deprecated cache_minify_ignore_tags and will allow the HTML tags that are ignored during HTML minification to be filtered. From when the now deprecated hook was introduced there has needed to be at least one ignore tag, however, this will be investigated and if not required will be updated to allow complete control.
cache_enabler_complete_cache_cleared action hook will replace deprecated ce_action_cache_cleared and will now only fire when the complete cache has actually been cleared (instead of whenever the clear complete cache method is called). In a multisite environment this will fire if only one site is cached and then cleared, otherwise it will only be fired when the network cache is cleared. This completes what was mentioned in PR #167.
cache_enabler_site_cache_cleared is a new action hook and will be fired when a site cache has been cleared. This will be fired whenever the site cache is cleared, even in addition to when cache_enabler_complete_cache_cleared is fired, and will pass along the $site_cleared_url (without a trailing slash) and $site_cleared_id.
cache_enabler_page_cache_cleared action hook will replace ce_action_cache_by_url_cleared and will now only fire when the page cache has actually been cleared too. This will now also fire for any subpages that may have been cleared and will pass along the $page_cleared_url (without a trailing slash) and $page_cleared_id. The post ID passed in $page_cleared_id may at times be empty (i.e. 0), like when the home page is the latest posts and does not have a post ID.
Clear site cache when permalink settings are changed instead of the complete cache because each site in a multisite network can have their own permalink structure, which means clearing the complete cache would be unnecessary. Even though it has similar behavior, clearing the complete cache when the theme is switched will remain until the handling of this behavior can be improved in the future.
Always register wp_initialize_site and wp_uninitialize_site multisite hooks and not only in the admin interface because sites can be created when outside this interface. This fixes the issue where the new site would not be initially setup when using WP-CLI to add the site (e.g. wp site create). Another case would be if using the API, which currently appears to only be possible with a custom endpoint. Though, in both cases the site would be setup on the first request to any page.
A known issue from the changes made above is that not all cache cleared hooks will be fired when using the WP-CLI clear subcommand in a multisite environment. Further, some passed data will be empty in the same environment even if the data is available. This will be fixed in the near future by switching to each blog beforehand so the correct values can be obtained. (That would mean switching blogs when deleting the cache size transient when clearing the site cache would no longer be needed.) This will be the last place that this change will be required to have the same clearing behavior across the entire plugin. Yay!
In addition to the hooks being updated, the following changes have been made:
Move URL validation from Cache_Enabler::clear_page_cache_by_url() to Cache_Enabler_Disk::cache_file_dir_path() because this is where all URLs are currently passed. This is possible now that firing the cache cleared hooks has been updated and doing this will prevent validating the URL in more than one location.
Update Cache_Enabler::requirements_check() to bail if the user permissions do not allow managing the Cache Enabler settings. This will fix requirement notices being shown to unwanted users.
Remove is_admin_bar_showing() checks because they are not required. The admin_bar_menu hook is not fired unless the admin bar is showing (see wp_admin_bar_render() in wp-includes/admin-bar.php). That means the admin bar buttons will not be added unless the admin bar is showing.
Update setting the clear URL when processing a clear cache request. This change updates PR #127. Instead, parse the home_url() for both the scheme and host, and then concatenate the received $_SERVER['REQUEST_URI']. This avoids having to check for the installation directory and uses the same behavior introduced in this PR when firing the cache cleared hooks.
Revert change made to Cache_Enabler_Engine::is_index() in PR #168. This is actually required for installations in a subdirectory. This was originally changed to prevent a new edge case that could arise from changes made in that same PR if the settings file did not exist and any index.php page was loaded (e.g. https://www.example.com/wp-admin/index.php). To fix this, return the settings file created and get the settings from this new settings file instead. This means if the settings file does not exist it will now be created not only in the frontend, but when any index.php file is loaded, such as /wp-admin/index.php.
Revert change made to Cache_Enabler_Disk::get_settings_file_name() statement in PR #164. Even though is_subdomain_install() is available when creating/deleting the settings file, where it is not available when getting settings from the settings file, it will be best to continue using the exact same logic in both places.
Update action and filter hooks:
cache_enabler_clear_complete_cache
action hook will replace deprecatedce_clear_cache
and when fired will clear the complete cache.cache_enabler_clear_site_cache
is a new action hook that when fired will clear the current site cache (supports both single and multisites).cache_enabler_clear_site_cache_by_blog_id
is a new action hook that when fired will clear the site cache of the given$blog_id
.cache_enabler_clear_page_cache_by_post_id
action hook will replace deprecatedce_clear_post_cache
and when fired will clear the page cache of the given$post_id
.cache_enabler_clear_page_cache_by_url
is a new action hook that when fired will clear the page cache of the given$clear_url
.cache_enabler_user_can_clear_cache
filter hook will replace deprecateduser_can_clear_cache
and will allow the required user permissions to clear the cache through the admin bar buttons be changed.cache_enabler_exclude_search
filter hook is new and will allow disabling the default behavior of excluding search pages from the cache (#83). For search pages to currently be cached it would require the search URL to be changed from?s=query
to something like/search/query/
. Automatically clearing the search cache has not been added at this time.cache_enabler_bypass_cache
filter hook will replace deprecatedbypass_cache
and will allow the cache to be bypassed.cache_enabler_page_contents_before_store
filter hook will replace deprecatedcache_enabler_before_store
and will allow the page contents to be filtered before trying to store the cached page.cache_enabler_page_contents_after_webp_conversion
filter hook will replace deprecatedcache_enabler_disk_webp_converted_data
and will allow the page contents to be filtered after inline image URLs have maybe been converted. Now that nearly all inline image URLs are rewritten, including those invoked with inline CSS, it is likely this hook is not needed as often as before.cache_enabler_minify_html_ignore_tags
filter hook will replace deprecatedcache_minify_ignore_tags
and will allow the HTML tags that are ignored during HTML minification to be filtered. From when the now deprecated hook was introduced there has needed to be at least one ignore tag, however, this will be investigated and if not required will be updated to allow complete control.cache_enabler_complete_cache_cleared
action hook will replace deprecatedce_action_cache_cleared
and will now only fire when the complete cache has actually been cleared (instead of whenever the clear complete cache method is called). In a multisite environment this will fire if only one site is cached and then cleared, otherwise it will only be fired when the network cache is cleared. This completes what was mentioned in PR #167.cache_enabler_site_cache_cleared
is a new action hook and will be fired when a site cache has been cleared. This will be fired whenever the site cache is cleared, even in addition to whencache_enabler_complete_cache_cleared
is fired, and will pass along the$site_cleared_url
(without a trailing slash) and$site_cleared_id
.cache_enabler_page_cache_cleared
action hook will replacece_action_cache_by_url_cleared
and will now only fire when the page cache has actually been cleared too. This will now also fire for any subpages that may have been cleared and will pass along the$page_cleared_url
(without a trailing slash) and$page_cleared_id
. The post ID passed in$page_cleared_id
may at times be empty (i.e.0
), like when the home page is the latest posts and does not have a post ID.Clear site cache when permalink settings are changed instead of the complete cache because each site in a multisite network can have their own permalink structure, which means clearing the complete cache would be unnecessary. Even though it has similar behavior, clearing the complete cache when the theme is switched will remain until the handling of this behavior can be improved in the future.
Always register
wp_initialize_site
andwp_uninitialize_site
multisite hooks and not only in the admin interface because sites can be created when outside this interface. This fixes the issue where the new site would not be initially setup when using WP-CLI to add the site (e.g.wp site create
). Another case would be if using the API, which currently appears to only be possible with a custom endpoint. Though, in both cases the site would be setup on the first request to any page.A known issue from the changes made above is that not all cache cleared hooks will be fired when using the WP-CLI
clear
subcommand in a multisite environment. Further, some passed data will be empty in the same environment even if the data is available. This will be fixed in the near future by switching to each blog beforehand so the correct values can be obtained. (That would mean switching blogs when deleting the cache size transient when clearing the site cache would no longer be needed.) This will be the last place that this change will be required to have the same clearing behavior across the entire plugin. Yay!In addition to the hooks being updated, the following changes have been made:
Move URL validation from
Cache_Enabler::clear_page_cache_by_url()
toCache_Enabler_Disk::cache_file_dir_path()
because this is where all URLs are currently passed. This is possible now that firing the cache cleared hooks has been updated and doing this will prevent validating the URL in more than one location.Update
Cache_Enabler::requirements_check()
to bail if the user permissions do not allow managing the Cache Enabler settings. This will fix requirement notices being shown to unwanted users.Remove
is_admin_bar_showing()
checks because they are not required. Theadmin_bar_menu
hook is not fired unless the admin bar is showing (seewp_admin_bar_render()
inwp-includes/admin-bar.php
). That means the admin bar buttons will not be added unless the admin bar is showing.Update setting the clear URL when processing a clear cache request. This change updates PR #127. Instead, parse the
home_url()
for both the scheme and host, and then concatenate the received$_SERVER['REQUEST_URI']
. This avoids having to check for the installation directory and uses the same behavior introduced in this PR when firing the cache cleared hooks.Revert change made to
Cache_Enabler_Engine::is_index()
in PR #168. This is actually required for installations in a subdirectory. This was originally changed to prevent a new edge case that could arise from changes made in that same PR if the settings file did not exist and anyindex.php
page was loaded (e.g.https://www.example.com/wp-admin/index.php
). To fix this, return the settings file created and get the settings from this new settings file instead. This means if the settings file does not exist it will now be created not only in the frontend, but when anyindex.php
file is loaded, such as/wp-admin/index.php
.Revert change made to
Cache_Enabler_Disk::get_settings_file_name()
statement in PR #164. Even thoughis_subdomain_install()
is available when creating/deleting the settings file, where it is not available when getting settings from the settings file, it will be best to continue using the exact same logic in both places.Closes #83