Fix plugin upgrade process when the disk settings are outdated and a frontend page is requested. Update Cache_Enabler_Disk::get_settings() to return an empty array when the disk and backend requirements are updated instead of trying to get the newly created settings file contents. This does not affect the caching behavior as the following will still occur when the disk settings are outdated and a frontend page is requested:
First frontend page request finds the settings are outdated so the disk and backend requirements are updated. No cached page is delivered. If this occurs on a multisite network then each site that has Cache Enabler installed will be updated.
Second frontend page request pulls the settings from the newly created settings file and creates the cached page. No cached page is delivered.
Third frontend page request pulls the settings from the newly created settings file again and delivers the cached page.
It appears this plugin upgrade process occurs in the backend most of the time, which means the above does not happen often. In that case I do not think it is worth adding more complexity to have this method return the disk settings after an update as it will actually not improve the caching behavior. The only thing I know this will affect is the event scheduling because the cache engine will not be started in the first frontend page request shown above. That means Cache_Enabler::schedule_events() will not be completed until the second frontend page request when the cache engine is started after the disk and backend requirements were updated.
This lowers the WordPress required version back to 5.1.
This fixes #294 and what was originally introduced in PR #260.
Fix plugin upgrade process when the disk settings are outdated and a frontend page is requested. Update
Cache_Enabler_Disk::get_settings()to return an empty array when the disk and backend requirements are updated instead of trying to get the newly created settings file contents. This does not affect the caching behavior as the following will still occur when the disk settings are outdated and a frontend page is requested:First frontend page request finds the settings are outdated so the disk and backend requirements are updated. No cached page is delivered. If this occurs on a multisite network then each site that has Cache Enabler installed will be updated.
Second frontend page request pulls the settings from the newly created settings file and creates the cached page. No cached page is delivered.
Third frontend page request pulls the settings from the newly created settings file again and delivers the cached page.
It appears this plugin upgrade process occurs in the backend most of the time, which means the above does not happen often. In that case I do not think it is worth adding more complexity to have this method return the disk settings after an update as it will actually not improve the caching behavior. The only thing I know this will affect is the event scheduling because the cache engine will not be started in the first frontend page request shown above. That means
Cache_Enabler::schedule_events()will not be completed until the second frontend page request when the cache engine is started after the disk and backend requirements were updated.This lowers the WordPress required version back to 5.1.
This fixes #294 and what was originally introduced in PR #260.