Update to HTML Minify for WordPress and WP Super Cache
No big news here, but I’ve got an updated patch if you want to use my mod to add Minify to WordPress and WP Super Cache. For more information, check out my original explanation and instructions post, which I’ve updated with links to the new files.
What’s changed? Well, nothing important. There have been some changes to WP Super Cache that caused parts of my patch not to apply automatically, so the patch is updated and tested against WP Super Cache 0.9. There’s also a tiny cosmetic change to the submit button on the WordPress configuration panel, so that it matches the WordPress 2.7+ backend.
Direct links to the new files:
- WPSCMinify 0.2, my standalone class and patch, which you can install into your existing Super Cache plugin
- wp-super-cache-with-WPSCMin-0.2.tar.gz, which is a complete modded WP Super Cache 0.9 plugin that you can use if you don’t want to fiddle with patches
And FYI
Be aware that recent versions of WP Super Cache fiddle with the advanced-cache.php file in wp-content, which previously you could just symlink to plugins/wp-super-cache/wp-cache-phase1.php (or you could copy the file if you don’t know what a symlink is). Now, instead of a symlink to wp-cache-phase1.php, it’s a PHP script that does a require_once of wp-cache-phase1.php. Whoop-de-do! I’m pretty sure the symlink is more efficient than doing a require in PHP, and it’s definitely annoying to have to copy and edit a file into a place outside the plugin directory, instead of a symlink that you could make once and leave alone forever, but whatever, it’s spaghetti code.
This doesn’t actually have anything to do with my mod, I just thought I’d mention it in case you’re upgrading WP Super Cache like I was — if so, be aware you’re going to have to manually shuffle this file around and edit it to look like this:
<?php
# WP SUPER CACHE 0.8.9.1
require_once( dirname(__FILE__).'/plugins/wp-super-cache/wp-cache-phase1.php' );
?>Don’t ask me why the dirname(__FILE__).'/plugins/wp-super-cache/ isn’t already in there by default instead of a random placeholder string that you have to fix yourself (or else the plugin dies). Hey, it’s more fun this way!
Donncha O Caoimh
March 4, 2009, 3:07 am
Unfortunately I couldn’t use something simple like the dirname() because the plugin dir doesn’t have to be in wp-content any more. :(
sticks
March 4, 2009, 5:16 am
Ah, thanks for the explanation!
It would be so nice if WordPress had a real configuration/registry system, instead of the hodgepodge of using PHP global constants and writing serialized PHP into the database. (Thus there’s no way for arbitrary PHP code to just do Settings::getSetting(‘plugin_dir’) without initializing most or all of the tightly coupled WP application, at which point it’s already game over if you’re under any kind of load.) It is ridiculous that a plugin like WP Super Cache has to implement and maintain its own configuration system, all the way down to the filesystem level, just to be able to maintain state between requests. Even if WP just had a singleton registry class that you could plug into any kind of key-value backend (memcached, APC, filesystem), it would be so nice.
I guess WP is committed to staying PHP4 for the time being, though, and wonder if they would be doing more to make the core loosely coupled, extensible, OO and sane if that weren’t the case? WP devs have created the most beautiful weblog admin interface the world has ever seen and I suppose that’s where most of their love is directed … but I’m not a real blogger, I’m the systems side, so I don’t care about that, I just want to see the frontend page/template render get much, much faster, and that core is pretty much the same now as it was 5 years ago or even as b2.
At the then top-20 blog I worked for, I wrote a caching wrapper that was interchangeable between using a front-end reverse proxy (Squid, now Varnish), memcached or filesystem (via PEAR::Cache_Lite) for storage, along with a WP plugin to manage the expiry of the caches based on various events like post edits, comments etc. It was nice and would fail over (i.e. if Squid or memcached was unreachable, it would start using the filesystem). Of course it was all PHP5 — and this now 3 years ago.
/sigh
dennis
March 15, 2009, 7:06 am
great mod, thanks. but i found a bug. your minify removes the information between adsense javascripts. so the ads are not/cant be shown.
original:
minified:
dennis
March 15, 2009, 7:12 am
the code is not shown :( send you an email.
sticks
March 15, 2009, 11:26 pm
Interesting … but didn’t get an email from you (yet). In case you couldn’t find it, my address is on the about page, but you have to fiddle with a recaptcha (sorry!).
I think your answer just got posted to the original Minify post, actually. See this comment by MrClay and this thread that he links to.
I’m going to reply to MrClay (he is the author of Minify) on that thread, so take a look over there. I’m running my mod with no Adsense problems, so I wouldn’t be surprised if it’s a PHP version/syntax issue.