I’m catching up on Daredevil on Netflix and this fight scene in series 2, episode 3 blew me away. The slow methodical way Daredevil ploughs through his enemies countering hits, disabling outstretched arms with guns pointed at him and smashing light bulbs that chain is mesmerising.
The next version of WP Super Cache will be one with some big changes! There are many small bug fixes and improvements but the one I’m most excited about is moving the legacy cache files into the supercache directory.
The legacy cache files were the files created by the old WP-Cache plugin upon which this plugin is based. They’re really useful as they store the headers sent from the server as well as the page contents. If you’re serving pages that aren’t regular html, such as JSON or XML you don’t want to tell the browser they’re text/html documents. This caching method is also used for anyone who is logged into your site, or left a comment.
There is a problem however. They’re stored in one directory. If you have many thousands of visitors interacting with your site you may end up with a directory containing thousands of files. The names of the cache files are a hash of the URL, gzip support and browser cookies so one file can match one user, or one file can be used by thousands of anonymous users. In the event that someone left a comment on a popular post the plugin has to search through all those files looking for the pages cached for other users who were also looking at that page. On a busy server that can cause problems.
So, in #177 I added code that moves the legacy cache files into the supercache directory. That means the files are stored in directories that reflect the URL of the page that was served which makes it very easy to delete the cached files belonging to that page as they’re all in the same directory!
The new code will look in the old location for legacy files first as some sites will have a large collection of cached files, but any new cache files will be created in the supercache directory.
Ian Dunn submitted code to cache the REST API. It’s not yet complete but we’ll be able to build on the changes to the legacy cache to make caching the API more efficient than it would have been before.
I really need people to help test this. The latest code is running on this site so I’m very confident in how well it works but just because it works on my odd little server doesn’t mean it will work right everywhere. If you want to give it a spin, visit the plugin Github repository and click on the “Clone or download” button. If you don’t know how to clone a Git respository just grab the zip file and install it on your server, overwriting the files in the plugins/wp-super-cache/ directory. If the changes to where cache files go doesn’t interest you, some of the changes in this list might:
- Don’t output broken warning in robots.txt>
- Use get_home_url() instead of siteurl because some sites have different homepages
- Remove most calls to get_all_supercache_filenames()
- Fix bottom border in admin
- Use plugins_url() so https links work
- Preload from the newest post
- Stop caching of wp-admin visits sooner
- Store legacy cache files in the supercache directories
- Make the headers more informative to tell how a page was served
- Properly serve 304 requests
- Apply realpath to filenames because of Windows oddities
- Don’t flush(), output buffers don’t like it
- Add more file checks around wp_cache_rebuild_or_delete()
- If HTTP_HOST is not defined then disable caching
- Only show html comments on html pages
- Fix caching of mobile requests
- Clear the cache for private posts
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!
Is it too late for Frank Kelly’s parody of 12 Days of Christmas?
Frank was probably best known as Father Jack on the show Fr. Ted, but I came across him first on an old vinyl record of his stories. He also produced many comedy sketches such as this one:
And he features in this clip of Yu Ming is Ainm Dom:
Watch the full short movie here:
A great talent who died earlier this year.
I’ll come back for you!!!
A version of Queen and David Bowie’s Under Pressure you might not have heard before.
You can hear some talking in the background. From the title I thought this was made during the recording of the song but comments on this video and another video say it’s from radio interviews. Anyone know?
Here’s a great article on the making of the song.
Though the band sounds lighthearted enough in the studio sessions, the songwriting, May remembers, was fraught with tension. “It was very hard,” he said in 2008, “because you already had four precocious boys and David, who was precocious enough for all of us.” Bowie, says May, “took over the song lyrically” and insisted on presiding over the final mix session, which “didn’t go well,” according to Queen engineer Reinhold Mack. For his part, May has said he would “love to sit down quietly on my own and re-mix it.”
X > Y >> Z
Where X is the population of developers who read this blog, Y is those that use Vim and Z is those that use vimdiff regularly. I guess this post will only be useful to a tiny minority of my readers, but to them it might be the best thing they’ve read all year. (Well, it is 2016, right? It’s been a weird year.)
Vimdiff allows you to open two files in Vim and side by side compare them, pushing changes from one file to another. I’ve been using it as long as I’ve been working on b2/WordPress and even before then too. It’s supremely useful.
Over the years I’ve used many different terminals, with various settings and colour configurations. My vim settings change over time too as I move from one machine to another. Sometimes the colours look ok in Vimdiff, sometimes they don’t. Sometimes the colours are ok for one file type while conflicting in others.
The problem is that Vimdiff has it’s own colours it uses to show what parts of the files are different or missing. Those colours can sometimes hide actual text in the files. I find myself highlighting those lines with SHIFT-V to see the text.
I could pick a different colour scheme but then there’s no guarantee that a different part of text will be hidden by Vimdiff’s colour scheme. The easiest way to fix this is by disabling syntax highlighting completely when in Vimdiff and you do it like this. Open up your ~/.vimrc and add these lines:
if &diff syntax off endif
With that in there Vimdiff goes from looking like this to the simplified appearance below.
Ironically, the theme I’m currently using in Vim in the screenshots above isn’t that problematic, but here are two screenshots that show the problem from another machine. In the second screenshot I have highlighted (with SHIFT-V) the line with the function name in the left side. As you can see, the text “function” is still invisible in the right side of the screenshot.
If you don’t want to edit your .vimrc for whatever reason you can also manually do
:set syntax=off from within the editor but you’ll have to do that for each of your files.
All the code above is GPLed WordPress code. Thanks to user hildred on Stackexchange for that one. Hopefully someone else will find this useful.