Updated output buffering to start even earlier on the advanced-cache.php drop-in instead of the init hook. This builds upon what was added in PR #137 and became possible with the cache engine introduced in PR #147. While the previous changes introduced increased the compatibility with other plugins (#78) it turns out starting on the init hook with the default priority still has compatibility issues with some plugins that start earlier (#120). Since delivering the cache requires the advanced-cache.php drop-in, which itself relies on the WP_CACHE constant being defined as true, as well as the settings file existing, it also makes sense for page caching to rely on both as well. This is the earliest Cache Enabler can start the output buffering, which should prevent any issues like this arising in the future.
The following updates to the caching process were updated because of this change:
The first attempt at trying to start the cache engine will now rely on whether or not the request script is the core WordPress index file instead of if the cached page exists. This will make it so if the settings file exists no database query will be made when getting the settings to cache a page. This became possible with the PHP settings file introduced in PR #147 because all settings are now available in this file. This updates #159 when creating the settings file if it does not exist in the late cache engine start. Instead, the first request would generate the settings file, the second request would cache the page, and the third request would deliver the cached page.
Update checking if the installation directory index received from $_SERVER['SCRIPT_NAME'] is /index.php instead of any index.php file as we want the actual installation directory index file. This will ensure Cache Enabler is only starting the cache engine on frontend pages that would end up being cached and delivered, and not pages like /wp-admin/index.php (which would bypass the cache by the is_admin() conditional tag).
Updated output buffering to start even earlier on the
advanced-cache.phpdrop-in instead of theinithook. This builds upon what was added in PR #137 and became possible with the cache engine introduced in PR #147. While the previous changes introduced increased the compatibility with other plugins (#78) it turns out starting on theinithook with the default priority still has compatibility issues with some plugins that start earlier (#120). Since delivering the cache requires theadvanced-cache.phpdrop-in, which itself relies on theWP_CACHEconstant being defined astrue, as well as the settings file existing, it also makes sense for page caching to rely on both as well. This is the earliest Cache Enabler can start the output buffering, which should prevent any issues like this arising in the future.The following updates to the caching process were updated because of this change:
The first attempt at trying to start the cache engine will now rely on whether or not the request script is the core WordPress index file instead of if the cached page exists. This will make it so if the settings file exists no database query will be made when getting the settings to cache a page. This became possible with the PHP settings file introduced in PR #147 because all settings are now available in this file. This updates #159 when creating the settings file if it does not exist in the late cache engine start. Instead, the first request would generate the settings file, the second request would cache the page, and the third request would deliver the cached page.
Update checking if the installation directory index received from
$_SERVER['SCRIPT_NAME']is/index.phpinstead of anyindex.phpfile as we want the actual installation directory index file. This will ensure Cache Enabler is only starting the cache engine on frontend pages that would end up being cached and delivered, and not pages like/wp-admin/index.php(which would bypass the cache by theis_admin()conditional tag).