This PR focuses on updating the cache clearing structure to be built around the WordPress objects that are reflected on frontend pages that Cache Enabler caches (e.g. site, post, comment, term, and user). It is built upon the foundation setup in PR #234 for term actions. This PR adds the cache clearing structure for user actions. This means the cache can now be cleared when a user is added, updated, or deleted. By default Cache Enabler will clear the user cache, which currently is any post that the user the author or has commented on, and the user author archive. If posts are reassigned to a new user upon a user being deleted, the reassigned user cache will also be cleared. If the new setting is enabled the site cache will be cleared instead.
The following methods will clear all of the cache associated with the current global object (if it is set) or of a given object:
These methods directly relate with the updated cache clearing settings (two new cache clearing settings will be introduced in version 1.8.0):
The site, post, comment, term, or user cache in this context is the cache that Cache Enabler considers to be associated with that object. For example, Cache_Enabler::clear_post_cache( $post ) would first clear the page cache of the post itself. This includes the pagination of that page, which has been updated to also clear the comment pagination (e.g. /post/comment-page-1/, /post/comment-page-2/, etc.). (Clearing the comment pagination was made possible due to what was added in PR #245. It was originally going to use what followed in PR #246, but it turns out how it was implemented in this PR works a little better and is cleaner. The wildcard cache clearing added in PR #246 will stay because it is useful and may be needed in the future.) Cache Enabler would also include the post type archive, post terms archives, and maybe the post author archive and post date archives. The idea behind this type of clearing is to automatically clear what needs to be when certain actions take place on a website.
Once the methods return handling is improved across the code base we will add hooks to most of the Cache_Enabler::clear_*_cache() methods above to allow an easy tap. This will allow custom behavior to easily be added when those methods are called.
This PR improves the standardization and increase the flexibility, like allowing the cache clearing methods to receive the object itself or an ID of the object (integer or numerical string). The following methods will clear the page cache of the posts associated with the given object (and allow the cache iterator arguments to be passed):
PR #234 started an update on the cache clearing structure for post actions that was added in PR #129. This PR added to that with the following methods:
The get_post(), get_comment(), get_term(), and get_userdata()/wp_get_current_user() functions are used to get the class instance needed. Many of these functions allow a null value to be provided (checked as empty). This directs the function to try and get the current related global value if set. Many of the methods added or updated in this PR allow this due to how those functions work.
Query string checks were added where certain URLs are obtained through a WordPress function. This was done in several methods, including Cache_Enabler::clear_term_archive_cache() despite what I said in my later reply in PR #234. This decision was made due to the fact that a query string URL can still be returned depending on the permalink structure and other edge cases. The permalink structure does not matter as caching is disabled in that event, however, there are likely other cases that this can occur that I am not aware of. Let us be strict and only send the clear cache request when the URL does not have a query string. What happens if a query string is returned and sent to be cleared? It would clear the wrong page (e.g. https://example.com?p=99 would clear https://example.com).
The cache_enabler_clear_site_cache_by_blog_id hooks is being deprecated as the cache_enabler_clear_site_cache hook can now be used instead due to the updates made to Cache_Enabler::clear_site_cache().
This PR focuses on updating the cache clearing structure to be built around the WordPress objects that are reflected on frontend pages that Cache Enabler caches (e.g. site, post, comment, term, and user). It is built upon the foundation setup in PR #234 for term actions. This PR adds the cache clearing structure for user actions. This means the cache can now be cleared when a user is added, updated, or deleted. By default Cache Enabler will clear the user cache, which currently is any post that the user the author or has commented on, and the user author archive. If posts are reassigned to a new user upon a user being deleted, the reassigned user cache will also be cleared. If the new setting is enabled the site cache will be cleared instead.
The following methods will clear all of the cache associated with the current global object (if it is set) or of a given object:
Cache_Enabler::clear_site_cache( $site = null )[updated]Cache_Enabler::clear_post_cache( $post = null )[new]Cache_Enabler::clear_comment_cache( $comment = null )[new]Cache_Enabler::clear_term_cache( $term, $taxonomy = '' )[updated, added in PR #234]Cache_Enabler::clear_user_cache( $user = null )[new]These methods directly relate with the updated cache clearing settings (two new cache clearing settings will be introduced in version 1.8.0):
The site, post, comment, term, or user cache in this context is the cache that Cache Enabler considers to be associated with that object. For example,
Cache_Enabler::clear_post_cache( $post )would first clear the page cache of the post itself. This includes the pagination of that page, which has been updated to also clear the comment pagination (e.g./post/comment-page-1/,/post/comment-page-2/, etc.). (Clearing the comment pagination was made possible due to what was added in PR #245. It was originally going to use what followed in PR #246, but it turns out how it was implemented in this PR works a little better and is cleaner. The wildcard cache clearing added in PR #246 will stay because it is useful and may be needed in the future.) Cache Enabler would also include the post type archive, post terms archives, and maybe the post author archive and post date archives. The idea behind this type of clearing is to automatically clear what needs to be when certain actions take place on a website.Once the methods return handling is improved across the code base we will add hooks to most of the
Cache_Enabler::clear_*_cache()methods above to allow an easy tap. This will allow custom behavior to easily be added when those methods are called.This PR improves the standardization and increase the flexibility, like allowing the cache clearing methods to receive the object itself or an ID of the object (integer or numerical string). The following methods will clear the page cache of the posts associated with the given object (and allow the cache iterator arguments to be passed):
Cache_Enabler::clear_page_cache_by_site( $site, $args = array() )[new]Cache_Enabler::clear_site_cache_by_blog_id( $blog_id, $args = array() )[deprecated]Cache_Enabler::clear_page_cache_by_post( $post, $args = array() )[new]Cache_Enabler::clear_page_cache_by_post_id( $post_id, $args = array() )[deprecated]Cache_Enabler::clear_page_cache_by_comment( $comment, $args = array() )[new]Cache_Enabler::clear_page_cache_by_term( $term, $args = array() )[updated, added in PR #234]Cache_Enabler::clear_page_cache_by_user( $user, $args = array() )[new]Cache_Enabler::clear_page_cache_by_url( $url, $args = array() )[updated]PR #234 started an update on the cache clearing structure for post actions that was added in PR #129. This PR added to that with the following methods:
Cache_Enabler::clear_post_type_archive_cache()[new]Cache_Enabler::clear_post_type_archives_cache()[deprecated]Cache_Enabler::clear_post_terms_archives_cache()[updated]Cache_Enabler::clear_taxonomies_archives_cache_by_post_id()[deprecated]Cache_Enabler::clear_post_author_archive_cache()[new]Cache_Enabler::clear_post_date_archives_cache()[new]Cache_Enabler::clear_date_archives_cache_by_post_id()[deprecated]Cache_Enabler::clear_author_archive_cache()[new]Cache_Enabler::clear_author_archives_cache_by_user_id()[deprecated]The
get_post(),get_comment(),get_term(), andget_userdata()/wp_get_current_user()functions are used to get the class instance needed. Many of these functions allow anullvalue to be provided (checked as empty). This directs the function to try and get the current related global value if set. Many of the methods added or updated in this PR allow this due to how those functions work.Query string checks were added where certain URLs are obtained through a WordPress function. This was done in several methods, including
Cache_Enabler::clear_term_archive_cache()despite what I said in my later reply in PR #234. This decision was made due to the fact that a query string URL can still be returned depending on the permalink structure and other edge cases. The permalink structure does not matter as caching is disabled in that event, however, there are likely other cases that this can occur that I am not aware of. Let us be strict and only send the clear cache request when the URL does not have a query string. What happens if a query string is returned and sent to be cleared? It would clear the wrong page (e.g.https://example.com?p=99would clearhttps://example.com).The
cache_enabler_clear_site_cache_by_blog_idhooks is being deprecated as thecache_enabler_clear_site_cachehook can now be used instead due to the updates made toCache_Enabler::clear_site_cache().As always, any feedback is welcome.