Preventing WP Super Cache from caching if no Slimstat in HTML

I was struggling with an occasional loss of reported traffic by SlimStat, due to my pages being cached by WP Super Cache (which is not active for logged in users) but not having SlimStatParams & the slimstat JS-file in it. I tried changing different settings in Slimstat, but the problem still occurred. As I was not able to pinpoint the exact root cause, I ended up using this code snippet to prevent pages being cached by WP Super Cache;

add_filter('wp_cache_ob_callback_filter','slimstat_checker');
function slimstat_checker($bufferIn) {
  if ( strpos($bufferIn, "<html") && strpos($bufferIn, "SlimStatParams") === false ) {
	define("DONOTCACHEPAGE","no slimstat no cache");
	error_log("no slimstat = no cache");
  }
  return $bufferIn;
}

Changing the condition on line 3 allow one to stop caching based on whatever (not) being present in the HTML.

Solve WP Super Cache + Autoptimize Internal Server Errors

Yesterday I noticed my autoptimized JS-files were returning an internal server error (CSS worked as that is inlined). My Apache error-log had this entry:

[Tue Oct 13 17:23:42 2015] [alert] [client 178.xx.xx.xx] /var/public_html/blog.futtta.be/wp-content/cache/.htaccess: Option Indexes not allowed here

/var/public_html/blog.futtta.be/wp-content/cache/.htaccess is created by WP Super Cache, which got updated recently, a.o. to disable indexes being created of directories, and the .htaccess indeed read;

# BEGIN INDEX
Options -Indexes
# END INDEX

The solution? I could have edited WPSC’s .htaccess, but my changes could get overwritten there whenever Donncha would feel like it, so in the end I edited my site’s config in Apache;

<directory /var/public_html/blog.futtta.be>
AllowOverride All
</directory>

And all is well now.

Autoptimize; JavaScript in head and some deprecated functionality

Autoptimize 1.6.5 got just pushed out, with one new feature and one notification. The new option configures Autoptimize to output the aggregated JavaScript in the head-section instead of at the bottom of the HTML. This can be useful when some of the JavaScript needs to be loaded asap and might prove useful to make jQuery plugins behave.
The notification might be less welcome for some users; YUI compression and the CDN options are marked as deprecated in this release. YUI compression was pretty exotic and required the installation of JAVA and the YUI compression jar, so I doubt anyone was actually using this. CDN options are deprecated as well; some people reported issue that I could not reproduce or fix. As I consider CDN not to be core functionality and as it can better be accomplished using e.g. WP Super Cache (which is a must-have companion of Autoptimize anyhow), CDN will indeed also be removed from Autoptimize. Expect the deprecated parts to be removed in 1.7.0 (which isn’t planned yet).

WP Caching plugin vulnerability debrief

Now that both WP Super Cache and W3 Total Cache developers have released a new version of their respective plugins (upgrade first, continue reading after) it seems time for a small “post mortem“.
The problem was in the interpretation of dynamic snippets, that are contained inside a number of specific HTML-comment tags. These snippets allow both plugins (and their predecessor WP Cache) to cache pages while keeping a limited amount of dynamic, PHP-generated content in them that can be executed on the fly. Think ESI in e.g. Varnish.
The vulnerability, which was originally discovered by kisscsaby and reported 3 weeks ago on the wordpress.org plugins support forum, had multiple causes:

  1. Unlike ESI’s, dynamic snippets can not only be includes (mclude) but also PHP-code (mfunc). Whereas one could consider includes of known files more or less safe, inclusion of PHP-code introduces a risk.
  2. As WP Super Cache & W3 Total Cache keep entire pages in cache and as pages can contain comments, that user generated content is parsed for dynamic snippets as well.
  3. WordPress core by default only allows a limited set of HTML in comments (“a blockquote code em strong ul ol li”), but it also leaves HTML comments in place.

As a result, blogs with WP Super Cache (before version 1.3) and W3 Total Cache (before version 0.9.2.9) were at risk of PHP code injection. Blog comments could contain dynamic snippets (in HTML-comments) and WordPress core did not them filter out. Upon a such a malicious comment having been submitted, a new cached version of the page was created that included the injected PHP-code. Upon the first request of the cached page, that code was successfully executed.
I stumbled on the vulnerability report about a week and a half ago, while researching why dynamic snippets weren’t executing when Autoptimize was active (simple really, Autoptimize by default removes HTML comments, the upcoming 1.6.3 will leave mfunc/mclude in place). As this seemed like a pretty severe security hole and as there was no feedback from developers in the support thread, I created a small “stopgap plugin” to mitigate the threat on April 10th, mailed security@wordpress.org and plugins@wordpress.org and requested WP Safer Cache being published on wordpress.org on the 11th. A couple of hours later WP Super Cache’s Donncha O Caoimh contacted me and the same day he released a version (1.3) that fixed this vulnerability by parsing out potential exploits from comments as they are posted and as they are rendered. On April 12th W3 Total Cache’s Frederick Townes confirmed they were working on a fix. Version 0.9.2.9 got released on April 17th, disabling dynamic snippets by default and when these are enabled, they require a secret alphanumeric key to be included in the snippet which is checked against one that is defined in wp-config.php.
Conclusions; The fact that this didn’t generate any fuss (as opposed to W3 Total Cache’s widely published information disclosure vulnerability in December 2012) is surprising. PHP Code injection clearly is a more severe security risk that must have been there for a long time already. The fact that this only got discovered recently is baffling. And why WordPress core doesn’t filter out HTML-comments from submitted blog comments, others seem to understand, but to me that remains the biggest mystery of all.

WP Safer Cache: stopgap for WordPress Cache plugins vulnerability

[UPDATE April 18th 2013: this vulnerability has been fixed in both WP Super Cache and W3 Total Cache. You can find more information in this “post mortem” blogpost]
[UPDATE April 11th to reflect that WP Super Cache version 1.3 fixed this issue]
There was a pretty severe vulnerability in WordPress installations that had WP Super Cache (until version 1.2, 1.3 fixed this issue) or W3 Total Cache (up until version 0.9.2.8) plugins activated. This security bug would, under certain circumstances, allow attackers to inject and execute arbitrary PHP code in comments.
The vulnerability could have been handled in WordPress core or in WP Super Cache and W3 Total Cache separately (with my preference being a fix in  comment sanitization in core). On April 11th WP Super Cache version 1.3 was released, fixing this issue and W3 Total Cache released a fix on April 18th. If you are on an older version of WP Super Cache or W3 Total Cache (do upgrade!), you might be interested in installing this little plugin that cleans out malicious … stuff from comments being posted.
As always; comments, bugs & improvements are welcome in the comment-field below or via the contact form.

CDN to the Max

It was time to put my money where my mouth is, or at least to give the use of a CDN a try. Based on previous tests MaxCDN seemed like a decent, dirt-cheap solution, so that’s what the js, css & images for this blog are served from now.
Setting this up was very easy:

  1. log into MaxCDN and set up a pull zone on static-cdn.blog.futtta.be with origin blog.futtta.be
  2. create static-cdn.blog.futtta.be in the web interface of my DNS-provider (as a CNAME to the domain-name provided)
  3. configure WP Super Cache to use static-cdn.blog.futtta.be instead of the non-cdn static.blog.futtta.be)

The speed difference can be huge, especially when routing to my origin VPS-server in Germany isn’t great. I’m sure my 2 overseas users and Google will approve!
Bandwidth-wise, with 10MB/day, I seem to be far from the 1TB/year I’m allowed, so if you’d like me to setup a (temporary) pull zone for your blog so you can check out if this would work for you then just drop me a line.

WordPress galore: plugin bugs, android app, json-api & wp 3.0

Some random WordPress-related thingies I’ve been looking into;

  • I bumped into a weird bug in css-js-booster which caused error-messages like
    <!-- Booster had a problems finding wp-content/
    plugins/css-js-booster/../../../../../../
    3f540bbd99f8ebecb73880a685db76ae_plain.css -->
    

    to appear in the html-source, although all CSS seemed to be processed. The problem was caused by PHP’s safe_mode and got fixed in 0.2.2, thanks der Schepp!

  • A few days ago my entire WordPress-blog returned empty pages, the admin-section included. Turns out that this “white screen of death” is a known issue with the WP super-cache plugin when combined with PHP APC (2 of the main components of my “Speed up WordPress“-post). As this only occurs rarely, I’ll stick to restarting Apache for now (I don’t want to switch back to eAccelerator) but I hope the APC and WP Super-Cache teams will look into this further.
  • After ditching Google Analytics, I looked into how WordPress stats are collected. Indeed, the script is sourced at the end of the HTML, thus slowing down the rendering of the page.  Let’s hope someone at Auttomatic reads Steve Soulders’ very interesting blogposts on “Performance of 3rd Party Content” and decides it indeed is time follow Google Analytics’ example and switch to asynchronous loading of the WordPress stats Javascript.
  • I installed the WordPress Android application and played around with it a bit. I don’t think I’ll be posting with it any time soon; writing on a small touch-device is a hassle, there’s no such thing as a rich HTML editor and  updating pages and especially posts or comments is very slow (because of the incredible overhead and complexity of the xml-rpc API?). Still, nice to see the WordPress-icon on my HTC Hero 😉
  • Thinking about that clumsy WordPress xml-rpc API (which I experimented with approx. 1 year ago), I started looking for a plugin that provides a rest/json api. JSON API does just that and it has great potential, but it might not be suited for public-facing WordPress installations just yet, as it allows unauthenticated users to create new posts. So you might want to wait for authentication to be added to JSON API before installing it?
  • And I just read that the first beta of WordPress 3.0 was released; wordpress and wordpress.MU get merged, menu management and a new theme are but a few of the new features. Wouldn’t is be great if functionality/ ideas from wp-super-cache, css-js-booster and json-api would be added as well?

Speed up your (WordPress-)site!

Google likes fast! Visitors like fast! So why don’t you go make your site really fast?
Suppose you just bought yourself hosting and you just installed WordPress for blogging or lightweight-CMS-purposes, how can you improve your site’s performance in that case? Easy!
  1. speed up PHP: use a caching optimizer (I use APC) to significantly speed up PHP performance (don’t bother  signing up for shared hosting with a company that doesn’t offer PHP with acceleration).
  2. cache dynamic output: install the “WP Super Cache” WordPress plugin. Configure and then forget about it; if you create/edit a blogpost, impacted pages are automatically removed from cache.
  3. optimize CSS and JS: install the “CSS JS booster” WordPress plugin, which (amongst other things) grabs all CSS and JS from WordPress and Plugins and outputs it in one CSS- and one JS-file (some plugins, e.g. Sociable and WordPress Mobile Pack, might need tweaking of the css media-attribute though) UPDATE: CSS JS booster has not been updated since 2010 and I switched to (and later even took over development of) Autoptimize for JS, CSS & HTML optimization.
  4. avoid calling 3rd party javascript: tracking (e.g. Google Analytics, which I removed), widgets (e.g. Twitter badges) or other 3rd party gadgets (e.g. AddToAny, which I removed) can slow down your site’s performance significantly
  5. optimize images: fire up your favorite photo editor and make that image just a bit smaller, use an acceptable level of compression (I end up between 70 and 80% for JPEG’s, depending on the image) and upload to smushit.com to squeeze out the last optimization-drop (example; I used a 20KB picture from Flickr, resized it to 80%, saved it with 77% compression and smushed it to end up with a mere 6KB).

The impact of a number of these steps can be measured easily; below are the response times of my blog’s homepage (the  html including css, js and images) as measured by Pingdom Tool’s Full Page Test.

  1. default WordPress (on a Linux VPS with 320Mb RAM memory): 6.5 seconds
  2. (1)  with PHP APC activated: 4.1 seconds
  3. (2) with WP Super Cache: 3.1 seconds
  4. (3) with CSS JS Booster: 1.3 seconds

So there you have it, from 6.5 to 1.3 seconds in only 5 easy steps! WordPress specific, but easily applicable to other platforms as well. Now go and make your site fast! And then go and make it even faster!

blog.futtta.be going mobile with WPtouch

blog.futtta.be goes mobileAfter reading how wordpress.com implemented not one but two mobile versions for all of their 4.5 million hosted blogs, I decided to install the same WPtouch-plugin on this very blog as well.
Installation and activation of a new plugin is very straightforward from within the wordpress admin-screens. In the case of WPtouch (and every other plugin that produces alternatives views of the same content on the same URL) however, there is a conflict with the WP super cache plugin which needs to be resolved by basically telling the cache-plugin to not handle request from browsers with “mobile” useragent-strings.
After that WP super cache config hack, your blog has a mobile section which you can tailor to your needs in the WPtouch config screen. These are some of the settings I changed:
  • removed categories and tags from the header (didn’t seem to work anyhow)
  • added most of my pages to the dropdown menu in the header
  • excluded my lifestream-digest posts from being displayed
  • removed author from and added excerpt to individual posts

If anyone visits this site with their mobile browser and stuff doesn’t work, your feedback is welcome!