websharks/quick-cache — pull request #351 by jaswsinc (2014-10-10 10:52:59+00:00)
Title: Refactor Clear/Purge/Wipe

See also: websharks/quick-cache#288

#### Summary of New Class Members

- New constants...
- `\quick_cache\share::CACHE_PATH_REGEX_DEFAULT_SUFFIX_FRAG`

- New properties...
- `\quick_cache\share::$name` = (string)`Quick Cache`
- `\quick_cache\share::$short_name` = (string)`QC`
- `\quick_cache\share::$slug` (moved into the share class, was in the plugin class).

- New methods for network-side clearing/purging/wiping.
- `\quick_cache\share::build_cache_path_regex()` - utility.
- `\quick_cache\share::clear_files_from_cache_dir()` - simple wrapper.
- `\quick_cache\share::purge_files_from_cache_dir()` - simple wrapper.
- `\quick_cache\share::delete_files_from_cache_dir()` - a meaty routine.

- New methods for host/blog-specific clearing/purging/wiping.
- `\quick_cache\share::build_host_cache_path_regex()` - utility.
- `\quick_cache\share::build_host_cache_path_regex_frags_from_wc_uris()` - utility.
- `\quick_cache\share::clear_files_from_host_cache_dir()` - simple wrapper.
- `\quick_cache\share::purge_files_from_host_cache_dir()` - simple wrapper.
- `\quick_cache\share::delete_files_from_host_cache_dir()` - a meaty routine.

- New method for recursively deleting a directory.
- `\quick_cache\share::delete_all_files_dirs_in()` - a meaty routine.

- New methods to assist in translations.
- `\quick_cache\share::i18n_files()` - utility.
- `\quick_cache\share::i18n_dirs()` - utility.
- `\quick_cache\share::i18n_files_dirs()` - utility.

- New string utilities.
- `\quick_cache\share::str_replace_once()` - utility.
- `\quick_cache\share::str_ireplace_once()` - utility.
- `\quick_cache\share::add_tmp_suffix()` - utility.

- New version-specific upgrader.
- `\quick_cache\version_specific_upgrade::from_lt_v141009()` - handles option key changes.

#### Summary of Changes

- Refactored all `\quick_cache\plugin::auto_purge_*()` methods. These now take advantage of the new methods in the `\quick_cache\share` class. Clearing/purging/wiping is now atomic in all scenarios.

- Renamed all `\quick_cache\plugin::auto_purge_*` methods, giving them the proper prefix of `auto_clear_*` instead. Along with this, all of the `auto_purge_` option keys have been renamed as well. In addition, the UI, descriptions, internal coments, docBlocks, etc. have been updated to the correct terminology.

- Refactored `\quick_cache\advanced_cache\maybe_invalidate_when_logged_in_postload()` to take advantage of new methods in the `\quick_cache\share` class. Clearing (i.e. invalidation) is now atomic here as well.

- All URI and Referrer exclusion patterns are now caSe insensitive. This was part of the refactoring here as well. WordPress v4 will serve URIs w/o cAse sensitivity. s2Member was updated just recently to support this too. With this PR for QC, all of the Quick Cache codebase has now been updated to support caSe insensitive clearing/purging/wiping; along with caSe insensitive pattern matching against URIs. The UI and instructions were updated for URIs exclusions patterns, and for Referrer exclusion patterns.

- I also fixed a newly-discovered bug. The `auto_purge_author_page_cache()` method (now `auto_clear_author_page_cache()`) was presenting dashboard notices in the pro version, even when `change_notifications_enable` was off.

- I also fixed a newly-discovered bug. The `auto_purge_custom_post_type_archive_cache()` method (now `auto_clear_custom_post_type_archive_cache()`) was not checking for the `$post_id` in `$this->static[__FUNCTION__]`. Should be `$this->static[__FUNCTION__][$post_id]`.

- A new class file (`/includes/utils-feed.php`) was added while I was working to refactor the XML feed clearing routine. With these utilities in place, the `auto_clear_xml_feeds_cache()` method is now MUCH easier to deal with and comprehend.

- All dashboard notices will now include the number of files cleared for each notice.

- I left a couple of `@TODO @raamdev` notes in the source code for review at a later date.

- Refactored `\quick_cache\plugin::wipe_*()` and `\quick_cache\plugin::clear_*()` methods. These now take advantage of new methods in the `\quick_cache\share` class. As mentioned previously, all clearing/purging/wiping is atomic, and that includes these methods too. This work was actually done together with other changes to the `auto_*()` methods.

---

#### Performance Enhancements

- With these changes, QC is now capable of doing atomic clearing/purging/wiping. In addition, on a MS network this is now accomplished on a blog-specific basis, without needing to scan the entire network-wide cache directory like before. This should improve performance considerably on large networks (i.e. those with VERY large cache directories).

- There is one exception to this however. If user-specific caching is enabled, an automatic invalidation of the cache for a particular user is always done network-wide, because a user can be logged into a single child site in the network, but have data that is shared across all blogs. This requires QC to do a full network-wide scan whenever it clears the cache for a particular user. For this reason, it is suggested that VERY large networks with a HUGE cache directory, do NOT enable user-specific caching.

- With these changes, each `scheme` sub-directory; i.e. `/http/` and `/https/` is scanned separately to help break apart what was previously a much larger directory scan for sites that serve pages over both schemes. QC now does two scans, which in itself is a bit slower, but should actually work to improve performance overall. In short, we don't need to look at both variations of a site at the same time any longer, we now deal with clearing/purging for each scheme separately. This will improve performance on both standard and MS network installs.

---

#### Tests Performed

- I tested each of the newly-refactored `auto_clear_*()` methods, along with various other things in both a standard WP install, and also on a MS network running sub-directories. Found a few minor issues and those were corrected in the last commit on this PR. Not seeing any remaining problems. I feel like this is ready to review; i.e. ready to merge and be tested further.