Add [--sites=<site>] as an associative argument to allow the site cache in a multisite network to be cleared.
Update success messages to better describe what was performed. Not using the _n() function for plurals because one comma separator means there are two pages or sites to be cleared. Currently success messages will always be returned, even if there was not a cache that was actually cleared.
Update Cache_Enabler::clear_page_cache_by_post_id() to not check if $post_id is empty because this will be done when validating the parameter as an integer.
Update Cache_Enabler::clear_page_cache_by_url():
Validate the URL now that a full URL is required (due to the Cache_Enabler_Disk::_file_path() updates below). Simple check to ensure the URL at least has a scheme and host.
Do not check if $clear_url is empty because this will be done when validating the parameter as a string and/or URL.
Update Cache_Enabler::clear_home_page_cache() to have an optional $blog_id parameter. This will allow the correct home page URL to be cleared when clearing a site cache in a subdirectory multisite network with WP-CLI. No parameter validation was added because this is currently handled beforehand.
Update Cache_Enabler::clear_blog_id_cache():
Check if the blog ID exists to avoid database errors when attempting to clear the site cache for a site that does not exist in a multisite network with WP-CLI.
Pass $blog_id to self::clear_home_page_cache() to ensure the correct home page cache is cleared when clearing a site cache in a subdirectory multisite network with WP-CLI.
Update Cache_Enabler_Disk::_file_path():
Update the parameter to be $url instead of $path because when this parameter is provided it will be a URL. Currently this parameter is only passed when clearing a page cache by URL, however, $url was chosen instead of $clear_url as other cases beyond clearing the cache may arise in the future when needing the server file path through a provided URL.
Update the $path variable name to $file_path instead as we move to more specific variable naming. Update this variable to use the passed $url parameter value instead of get_site_url() when getting the host. This is required to ensure the correct file path is returned when clearing a URL in a multisite network with WP-CLI. This actually makes more sense as we are already setting the correct URL when sending it to be cleared. No reason to generate the host in the file path again when getting the file path to clear. This change means the provided URL will need to be full and not relative. As far as I know this would only affect the WP-CLI clear subcommand if a relative URL was provided (e.g. wp cache-enabler clear --urls=/about-us). This functionality is not documented so I am unsure if it is being used out in the wild. If it turns out that it is we can add support for clearing relative URLs with WP-CLI by getting the current site URL and appending the relative URL if the URL validation fails. This would only work for single installations, subdirectory multisite networks, and the main site in a subdomain multisite network (unless a blog ID variable was passed for subsites in a subdomain multisite network, which I would not want to add as the full URL should just be used in that case).
Update the is_file() check to return a 404 error if the path is in fact a file and not a directory (as we do in advanced-cache.php).
Update Cache_Enabler_Disk::_get_settings() variables to be $blog_path instead of $path as we move to more specific variable naming.
Update WP-CLI
clearsubcommand:Add
[--sites=<site>]as an associative argument to allow the site cache in a multisite network to be cleared.Update success messages to better describe what was performed. Not using the
_n()function for plurals because one comma separator means there are two pages or sites to be cleared. Currently success messages will always be returned, even if there was not a cache that was actually cleared.Update
Cache_Enabler::clear_page_cache_by_post_id()to not check if$post_idis empty because this will be done when validating the parameter as an integer.Update
Cache_Enabler::clear_page_cache_by_url():Validate the URL now that a full URL is required (due to the
Cache_Enabler_Disk::_file_path()updates below). Simple check to ensure the URL at least has a scheme and host.Do not check if
$clear_urlis empty because this will be done when validating the parameter as a string and/or URL.Update
Cache_Enabler::clear_home_page_cache()to have an optional$blog_idparameter. This will allow the correct home page URL to be cleared when clearing a site cache in a subdirectory multisite network with WP-CLI. No parameter validation was added because this is currently handled beforehand.Update
Cache_Enabler::clear_blog_id_cache():Check if the blog ID exists to avoid database errors when attempting to clear the site cache for a site that does not exist in a multisite network with WP-CLI.
Pass
$blog_idtoself::clear_home_page_cache()to ensure the correct home page cache is cleared when clearing a site cache in a subdirectory multisite network with WP-CLI.Update
Cache_Enabler_Disk::_file_path():Update the parameter to be
$urlinstead of$pathbecause when this parameter is provided it will be a URL. Currently this parameter is only passed when clearing a page cache by URL, however,$urlwas chosen instead of$clear_urlas other cases beyond clearing the cache may arise in the future when needing the server file path through a provided URL.Update the
$pathvariable name to$file_pathinstead as we move to more specific variable naming. Update this variable to use the passed$urlparameter value instead ofget_site_url()when getting the host. This is required to ensure the correct file path is returned when clearing a URL in a multisite network with WP-CLI. This actually makes more sense as we are already setting the correct URL when sending it to be cleared. No reason to generate the host in the file path again when getting the file path to clear. This change means the provided URL will need to be full and not relative. As far as I know this would only affect the WP-CLIclearsubcommand if a relative URL was provided (e.g.wp cache-enabler clear --urls=/about-us). This functionality is not documented so I am unsure if it is being used out in the wild. If it turns out that it is we can add support for clearing relative URLs with WP-CLI by getting the current site URL and appending the relative URL if the URL validation fails. This would only work for single installations, subdirectory multisite networks, and the main site in a subdomain multisite network (unless a blog ID variable was passed for subsites in a subdomain multisite network, which I would not want to add as the full URL should just be used in that case).Update the
is_file()check to return a404error if the path is in fact a file and not a directory (as we do inadvanced-cache.php).Update
Cache_Enabler_Disk::_get_settings()variables to be$blog_pathinstead of$pathas we move to more specific variable naming.