There’s a new release of WP Super Cache out and it’s a security release to fix XSS problems in the settings pages. Those pages are only accessible by admin users so an anonymous visitor to your site can’t come along and enable it to steal your login cookies but along with those fixes come many bug fixes so it’s worth upgrading if you’re using an old version.
From the Changelog:
- Fixed bug when not running sem_remove after sem_release. See https://github.com/Automattic/wp-super-cache/issues/85
- Fixed a PHP error impacting PHP 7.1.
- Fixed a bug where we cached PUT and DELETE requests. We’re treating them like POST requests now.
- Delete supercache cache files, even when supercache is disabled, because mod_rewrite rules might still be active.
- Updated the settings page, moving things around. #173
- Make file locking less attractive on the settings page and fixed the WPSC_DISABLE_LOCKING constant so it really disables file locking even if the user has enabled it already.
- Added a WPSC_REMOVE_SEMAPHORE constant that must be defined if sem_remove() is to be used as it may cause problems. #174
- Added a “wpsc_delete_related_pages_on_edit” filter that on returning 0 will disable deletion of pages outside of page being edited. #175
- Fixed plugin deleting all cached pages when a site had a static homepage. #175
- Make sure $cache_path has a trailing slash #177
- Remove flush() #127 but also check if headers are empty and flush and get headers again. #179
- Add fix for customizer #161 and don’t cache PUT AND DELETE requests #178
- Check for superglobals before using them. #131
You can click through to each of the Github pull requests above to see discussion around each bug fix.
If you’re hosting many sites that use WP Super Cache and you’re seeing issues with semaphores it may mean that your users are using file locking. It’s really not needed and in #174 there’s a fix that went into this release. You can disable file locking completely by setting the constant “WPSC_DISABLE_LOCKING” in a global configuration file. The file locking simply slowed down how fast cache files were created and is a hold-over from WP Cache when that plugin used to write directly to the cache files. This plugin writes to temporary files before moving to the final cache files so that locking isn’t really needed, but some sites still use it which is why it’s still around.
I’ve already been working on the next release with efforts to move the legacy cache files into the supercache directories. This will make it easier to maintain them and improve performance. We really need to find a better name for this caching method however. It caches everything – page contents and http headers so it’s quite useful!
If you’re going to test that PR, try #176 too. The plugin only deletes index.html type files right now but this chunk of code cleans up various for loops in the plugin and also deletes any file in the named directory. There are some restrictions on it so it won’t delete anything outside the cache directory.
Thanks to everyone who contributed to this release!
