Add constants.php file for new constant handling. This change will make it so the cache and settings directories can be customized (#226) in addition to now allowing the WordPress installation directory index file to be renamed. Renaming this file is uncommon; however, there are a few reasons that this may be done, like when WordPress is installed in another application directory where index.php is already taken (e.g. Magento). This is primarily checked to only start the output buffer on pages that we would actually cache and only get the settings from the disk on frontend pages. This adds support to a request that was made a really, really long time ago (https://wordpress.org/support/?p=9728185).
That means Cache_Enabler_Engine::is_index() will check if the script currently being executed is the WordPress installation directory file (by full file path) instead of only if that script is named index.php. This means the Cache_Enabler_Engine::is_index() method will no longer return true when other scripts with this name are being executed, such as /wp-admin/index.php. Even though this page would have never been cached due to the is_admin() check that follows, it is a good change as the output buffering will now no longer be started when this page or any other similar backend pages are requested.
The introduction of this new constant handling has led to changing how Cache Enabler handles the advanced-cache.php drop-in. If you have been reading my changes over the last year you will know by now that this file is what delivers cached pages or starts the caching of a page. It is included by WordPress when the WP_CACHE constant is truthy (and the enable_loading_advanced_cache_dropin filter hook also returns a truthy value). Instead of copying this file as is from the Cache Enabler directory as we have been doing, take the contents from the new sample file and update it according to the installation that Cache Enabler is installed on. This will improve the handling when Cache Enabler is used as a MU plugin as discussed in PR #195. This means the CACHE_ENABLER_DIR constant should no longer need to be defined when used as a MU plugin because once installed the advanced-cache.php will be created and it will contain the path to the constants.php file.
When the advanced-cache.php file does not exist and the plugin is activated (or if used as a MU plugin) then this file will be created when the admin_notices hook is fired and the current user can manage_options. That means hitting a frontend page will not create the advanced-cache.php file as of this commit; hitting a backend page is required. This will be updated in the future when our requirement handling is improved because Cache Enabler currently creates the settings file if it does not exist when a frontend page is requested (which allows the following request to cache the page). It would be good to have consistent file creations regardless of whether the frontend or backend is hit.
Ensuring the advanced-cache.php file is up to date is crucial as it is the initial script starting up the cache engine early. Keeping this file up to date in the current version (1.7.2) is done when the plugin is updated (initially introduced in version 1.2.3). That way relies on the upgrader_process_complete hook that calls Cache_Enabler::on_upgrade(). As explained in PR #166, the caveat with this in our use case is that it is running the old version of Cache Enabler. If the current handling was kept when upgrading to the next version (1.8.0) it would result in an error and the advanced-cache.php not being set up correctly. Furthermore, when used as a MU plugin that hook will never be fired because MU plugins have to be manually updated. That means relying on the upgrader_process_complete hook for updating the disk and backend requirements is not reliable going forward. Instead, let us do this in the Cache_Enabler::get_settings() and Cache_Enabler_Disk::get_settings() methods. That will allow Cache Enabler to update its disk and backend requirements if the version is different. Cache_Enabler::update() is being called in Cache_Enabler_Disk::get_settings() (instead of allowing Cache_Enabler::get_settings() to call it) because it will prevent calling the Cache_Enabler_Disk::create_settings_file() method twice (if the database is updated a new settings file is created).
That means Cache_Enabler::on_upgrade() will no longer look for when Cache Enabler is updated. Instead, if any plugin (including Cache Enabler) and/or theme is updated through WordPress the network or site cache will be cleared (updates what was added in PR #215). If Cache Enabler is updated by replacing its files, like through SFTP/FTPS or rsync, then the plugin will now update its requirements outside of the plugin directory due to this change. Overall, this change should really improve the update process after an upgrade, especially for old versions before 1.4.0.
Using the wp_opcache_invalidate() function in the Cache_Enabler_Disk::get_settings() method has made the new WordPress required version 5.5 instead of 5.1.
The Cache_Enabler::$fire_page_cache_cleared_hook property was added back (after being removed in PR #237). It is public and in the rare case that it was used in the wild let us just deprecate it. Cache_Enabler_Disk::$cache_dir is being deprecated as well, but it will not use the new CACHE_ENABLER_CACHE_DIR constant in the rare case this constant is not defined. Cache_Enabler_Disk::$settings_dir was private in version 1.7.2 (made public in PR #256) so it is being removed.
This is the last development change planned for version 1.8.0. All that is left is a little more polishing on what already exists, which means this new version is almost ready. Yay!
Add
constants.phpfile for new constant handling. This change will make it so the cache and settings directories can be customized (#226) in addition to now allowing the WordPress installation directory index file to be renamed. Renaming this file is uncommon; however, there are a few reasons that this may be done, like when WordPress is installed in another application directory whereindex.phpis already taken (e.g. Magento). This is primarily checked to only start the output buffer on pages that we would actually cache and only get the settings from the disk on frontend pages. This adds support to a request that was made a really, really long time ago (https://wordpress.org/support/?p=9728185).That means
Cache_Enabler_Engine::is_index()will check if the script currently being executed is the WordPress installation directory file (by full file path) instead of only if that script is namedindex.php. This means theCache_Enabler_Engine::is_index()method will no longer returntruewhen other scripts with this name are being executed, such as/wp-admin/index.php. Even though this page would have never been cached due to theis_admin()check that follows, it is a good change as the output buffering will now no longer be started when this page or any other similar backend pages are requested.The introduction of this new constant handling has led to changing how Cache Enabler handles the
advanced-cache.phpdrop-in. If you have been reading my changes over the last year you will know by now that this file is what delivers cached pages or starts the caching of a page. It is included by WordPress when theWP_CACHEconstant is truthy (and theenable_loading_advanced_cache_dropinfilter hook also returns a truthy value). Instead of copying this file as is from the Cache Enabler directory as we have been doing, take the contents from the new sample file and update it according to the installation that Cache Enabler is installed on. This will improve the handling when Cache Enabler is used as a MU plugin as discussed in PR #195. This means theCACHE_ENABLER_DIRconstant should no longer need to be defined when used as a MU plugin because once installed theadvanced-cache.phpwill be created and it will contain the path to theconstants.phpfile.When the
advanced-cache.phpfile does not exist and the plugin is activated (or if used as a MU plugin) then this file will be created when theadmin_noticeshook is fired and the current user canmanage_options. That means hitting a frontend page will not create theadvanced-cache.phpfile as of this commit; hitting a backend page is required. This will be updated in the future when our requirement handling is improved because Cache Enabler currently creates the settings file if it does not exist when a frontend page is requested (which allows the following request to cache the page). It would be good to have consistent file creations regardless of whether the frontend or backend is hit.Ensuring the
advanced-cache.phpfile is up to date is crucial as it is the initial script starting up the cache engine early. Keeping this file up to date in the current version (1.7.2) is done when the plugin is updated (initially introduced in version 1.2.3). That way relies on theupgrader_process_completehook that callsCache_Enabler::on_upgrade(). As explained in PR #166, the caveat with this in our use case is that it is running the old version of Cache Enabler. If the current handling was kept when upgrading to the next version (1.8.0) it would result in an error and theadvanced-cache.phpnot being set up correctly. Furthermore, when used as a MU plugin that hook will never be fired because MU plugins have to be manually updated. That means relying on theupgrader_process_completehook for updating the disk and backend requirements is not reliable going forward. Instead, let us do this in theCache_Enabler::get_settings()andCache_Enabler_Disk::get_settings()methods. That will allow Cache Enabler to update its disk and backend requirements if the version is different.Cache_Enabler::update()is being called inCache_Enabler_Disk::get_settings()(instead of allowingCache_Enabler::get_settings()to call it) because it will prevent calling theCache_Enabler_Disk::create_settings_file()method twice (if the database is updated a new settings file is created).That means
Cache_Enabler::on_upgrade()will no longer look for when Cache Enabler is updated. Instead, if any plugin (including Cache Enabler) and/or theme is updated through WordPress the network or site cache will be cleared (updates what was added in PR #215). If Cache Enabler is updated by replacing its files, like through SFTP/FTPS or rsync, then the plugin will now update its requirements outside of the plugin directory due to this change. Overall, this change should really improve the update process after an upgrade, especially for old versions before 1.4.0.Using the
wp_opcache_invalidate()function in theCache_Enabler_Disk::get_settings()method has made the new WordPress required version 5.5 instead of 5.1.The
Cache_Enabler::$fire_page_cache_cleared_hookproperty was added back (after being removed in PR #237). It is public and in the rare case that it was used in the wild let us just deprecate it.Cache_Enabler_Disk::$cache_diris being deprecated as well, but it will not use the newCACHE_ENABLER_CACHE_DIRconstant in the rare case this constant is not defined.Cache_Enabler_Disk::$settings_dirwas private in version 1.7.2 (made public in PR #256) so it is being removed.This is the last development change planned for version 1.8.0. All that is left is a little more polishing on what already exists, which means this new version is almost ready. Yay!
Closes #226