WP-Cache 2.1 revisited: Have x-gzip and gzip compression share same cache slot

Posted on April 10th, 2007 by Reiner.
Categories: English, Computers.

While working on the 304 not modified case that causes excessive traffic for RSS feeds, I encountered a mild weakness within the compression code, that causes both gzip and x-gzip variants of a particular page to use separate cache slots (i.e. two separate files). That’s quite redundant, as x-gzip is just a lagacy term to invoke gzip processing and both x-gzip and gzip produce identical contents. 

Now, only a single cache slot is being used for both and the value of the Content-Encoding header (either gzip or x-gzip) is no longer cached, but instead derived from the current request being served. 

There’s no code here, as it will be included within the 304 not modified version.

0 comments.

How to prevent Search Everything from returning duplicate hits with WordPress 2.1

Posted on February 19th, 2007 by Reiner.
Categories: English, Computers.

After upgrading to WordPress 2.1 Search Everything often returns the same pages multiple times. 

22-Feb-07 Update: The information below has been superceeded, as Dan has just released version 3.01 of the plugin that includes code to prevent duplicate hits.

One of a my friends runs a property management agency, where WordPress is used as an internal knowledge base to document internal procedures and the like. Quite often, valuable information is not contained within the main post, but added later as a comment. Search Everything makes sure that this information can be searched and retrieved.

After upgrading to WordPress 2.1 and installing Search Everything Version 2.6, searches will quite often return the very same pages multiple times.

I had a look at both Search Everything and WordPress Code and found that WordPress 2.1 does not use the distinct option when querying the databse, but provides a filter instead that may, at its discretion, return the magic ‘DISTINCT’ to cancel duplicate entries. The distinct option may need additional resources within the database, so I believe, it’s off by default for performance reasons.

Here’s my fix (the bolded lines below), which will cause WordPress to cancel duplicate results. It should be applied to the search_everything2.php file and requires WordPress 2.1+ to work (but won’t harm older WordPress releases) :

if ("true" == get_option('SE2_use_metadata_search')) {
  add_filter('posts_where', 'SE2_search_metadata');
  add_filter('posts_join', 'SE2_search_metadata_join');
  SE2_log("searching metadata");
  }            

// http://blog.saddey.net/?p=167
add_filter(’posts_distinct’, SE2_search_distinct);              

// http://blog.saddey.net/?p=167
function SE2_search_distinct($distinct) {
  if($distinct == ”) {
    return ‘DISTINCT’;
  }
  return $distinct;
}              

//search pages
function SE2_search_pages($where) {
  global $wp_query;

The fix is very basic and may apply the distinct clause, even when it might not be required as dictated by your Search Everything options. But I don’t think, there’ll be any problem with this and would like to leave the final inclusion to the author of Search Everything. Thanks to Dan Cameron for this great plugin! 

After having implemented the fix, I found, that the concept for the fix has already been outlined at WordPress Hackers - Getting double/triple posts listed on some blogs ten days ago.

Aditya has posted a fix as well, which was taken from Google Code, but I believe that my version more closely adheres to WordPress 2.1 standards (the ‘posts_distinct’ just returns a keyword for the tasks it’s supposed to instead of modifying the whole query).

1 comment.

How to prevent WP-Cache from changing a Feed’s Content-Type to text/html

Posted on February 18th, 2007 by Reiner.
Categories: English, Computers.

After upgrading to WP 2.1, Kelson had to downgrade WP-Cache 2.1 to a tweaked 2.0.17, because with RSS feeds WP-Cache 2.1 would,  when serving a request from its cache, always return Content-Type text/html instead of Content-Type text/xml.

Why does WP-Cache not reproduce the original Content-Type text/xml?

I had a look at wp_cache_shutdown_callback within wp-cache-phase2.php and found that all and everything should work perfectly.

Disabling WP-Cache’s code that forcibly sends a Content-Type text/html header if there is none, led me to the mazes ob flush(), ob_flush(), ob_end_flush(), headers_sent() and the like. And to the interesting fact, that…

WP-Cache does not see at least some of the http response headers, that have been output by WordPress code. Why?

If WP-Cache misses some headers, the reason must be located somewhere in the way it tries to retrieve them.  wp_cache_get_response_headers() first interrogates apache_response_headers() and, if this function does not exist, reverts to headers_list().

headers_list() docs clearly state, that it returns both, headers that have already been sent and those that have not yet been sent, i.e. are about to be sent. That might be the ones, that WP-Cache is missing after all. headers_list() requires PHP >= 5, but even then, headers_list() may not work at all due to Bug #29683 headers_list() func. return empty array.

apache_response_headers() requires PHP >= 4.3 (>= 4.3.3 with NSAPI)  and its docs are a little bit vague on platform requirements. There are some  hints on how to have it “working good”.

  • For apache_response_headers() working good, you need to set up output_buffering = Off in php.ini. Ok, I’ve checken on that one, it’s still set to its default = off.
  • If apache_response_headers() returns an empty array, try calling flush() before and it’ll get filled.  Bingo :-)   At least on my system using the Vistered Little Theme. Strange though, that it was just the Content-Type header, that was missing, the other ones were included even without the flush()…

Fix for wp_cache_get_response_headers within wp-cache-phase2.php:

function wp_cache_get_response_headers() {
  if(function_exists('apache_response_headers')) {
    flush(); // fix text/html on feeds
    $headers = apache_response_headers();
  } else if(function_exists(’headers_list’)) {
    $headers = array();
    foreach(headers_list() as $hdr) {
      list($header_name, $header_value) = explode(’: ‘, $hdr, 2);
      $headers[$header_name] = $header_value;
    }
  } else
    $headers = null;              

  return $headers;
}

Last-not-least an honorable mention of ieHTTPHeaders , that made it possible to spy on both the actual http request and response headers and much more. Thanks to Jonas!

There’s another interesting area as to when a page needs refreshing. It’s the If-Modified-Since header. Do WordPress and WP-Cache support this technique, and why not? I’ll try to cope with that one in a future post…

14 comments.

Why WP-Cache and Spam Preventers like Spam Karma 2.2 will never work in harmony

Posted on February 15th, 2007 by Reiner.
Categories: English, Computers.

WP-Cache and Spam Karma both implement strategies that are contradictory by their very nature. Let’s see why.  

In the past, I got along with a remarkably short comment blacklist (hand**b, pi**ing, tran****ual, b**bs) , that was able to block over 5000 spam attempts during the last year, but still allowed too many false nagatives to slip through for manual approval to be avoided. Personally, I don’t like having to approve - or being approved, for that matter :-)

When upgrading to WordPress 2.1, I was looking for a better way to prevent spam. I soon ruled out Akismet, because Akismet requires a key and I was unable to find the right kind of key within a reasonable amount of time. My blog is both a private one and non-commercial, but still runs on my own server (10 feet from my bed, see Small is beautiful - WordPress in a Handbag).

When leaving a comment at Kelson’s Updated to WordPress 2.1, I was quite impressed by a challenge popup, that I could trace back to Spam Karma 2.2. Wow, that’s cool - I must have this.

Within minutes, I downloaded, installed - and donated to - Spam Karma 2.2.

Due to my CPU’s inferior processing power, I’m using WP-Cache (with expire time set to 60 days) in order to speed up page display. To my dismay, WP-Cache caused new comments not to be displayed at all. Everton’s article at How To Fix WP-Cache And Spam Karma 2 (SK2) Issues led me to Priv’s SK2-WP-Cache-Compatibility plugin which sucessfully fixed the case of the missing comments. So far, so good.

Everything ought to be in perfect harmony by now.
But is it really?

The answer may be no, and here’s why:

WP-Cache works very much like a camera. It lets WordPress generate the HTML for a page, which is then captured and resent by WP-Cache on all subsequent request for the same page. That’s the secret to its stunning performance. A page, once cached, is returned just as fast as if it were plain static HTML. WP-Cache is quite smart about building the key for a cached page. Keys include your WordPress cookies so as to avoid disclosure of private pages. There’s even a hack that enables WP-Cache to properly snapshot gzipped pages as well, thus avoiding the computational expense of compressing identical contents more than once (see WP-Cache 2.1 revisited: Compression)

Spam Karma contains quite a number of advanced features, some of which can easily be revealed by looking the HTML of a page. Three of those may not work as designed when used in conjunction with WP-Cache: 

  • The stopwatch plugin injects the current time when the page was requested into the HTML of the page and then monitors the time, it takes a visitor to read your article before hitting the comment button.
  • The encrypted payload plugin injects unique data into the HTML that is checked for by Spam Karma when hitting the comment button. The actual data changes on a regular interval schedule so as not to be avoided by smart spamming applets.

These two techniques very much rely on Spam Karma being able to prepare individual output for each and every particular page request. This is defeated by WP-Cache returning static content that may have been prepared hours or days ago in response to another request for the same page, eventually causing Spam Karma to no longer accept or misinterpret the values returned.

It’ll be an interesting challenge as to how these conflicting goals can be met at the same time:

  • Always return the same static image for a particular page. 
  • Return different contents for each request.

7 comments.

WP-Cache 2.1 revisited: Compression

Posted on February 11th, 2007 by Reiner.
Categories: English, Computers.

Speeding up WordPress appears to be the play of the month, see 5 Ways to Speed Up Your Site. I ran into an interesting post from Nick Georgakis in which he presents both an in-depth discussion and working code to properly enable compression with WP-Cache. The main idea is, that in order to support compression, WP-Cache must keep compressed cached files separate from uncompressed ones. This is achieved by appending the compression method to the url when allocating and retrieving cache entries. That way, browsers will always be returned a version of the content they will be able to handle - depending on whether they requested compressed contents or not in the first place. 

I’ve adopted Nick’s code to the current 2.1 version of the WP-Cache and applied some minor amendments, e.g. replaced the somewhat complicated gzcompress call with the more up-to-date gzencode. Be warned though, that it requires at least PHP 4.2.

What it comes down to: WP-Cache is a very effective plugin that lets WordPress serve content just as if it were plain static html. Why not have WP-Cache take a snapshot of the compressed image as well?

21 comments.

Vistered Little revisited

Posted on February 10th, 2007 by Reiner.
Categories: English, Computers.

After having added some wallpapers to Vistered Little, I learnt that they will all be downloaded, regardless whether they are actually shown or not. That sums up quite a bit… The reason is, that the background selection does not display real thumbnails, but just tiny squares taken from the center of the wallpaper images instead.

That was easy - I thought. Thus I modified Vistered Little so that the menu would fetch its images from a separate directory (wallpapers/thumbs) and then prepared real tiny thumbnails (20×20 px). All and everything appeared to be great, even my Nokia E61 now showed the site without a glitch (it used to choke on the multi megabytes before), but… IE 6 would no longer refresh its background on a selection change :-(

The problem only occurs with Internet Explorer 6. IE 7 is ok, as is Firefox. I’m currently working on this bug… In the meantime, press F5 to refresh.

It appears as though programming real world browsers is a preview of living hell. IE 6 completely refuses to load images when requested by setting document.style.background, but happilly displays them if - by chance -  they have been loaded at least once before. Changing the background image within the onload event of an Image object did not work with Firefox 1.5, but works as advertised with both IE 6 & 7.

So here’s a code snippet that appears to work for FireFox (1.5), IE (6&7) and the Nokia E61 alike - the background is set both, immediately and within the onload event, if required :-) 

function setBackgroundWP(bgNumber,bgUrl) {
  var im = new Image();
  im.bgSty = "url('" + bgUrl + "') top center fixed";
  im.setBackgroundWPOnLoad = function() {
    if (document.body.style.background != this.bgSty) {
      document.body.style.background = this.bgSty;
    };
  };
  im.onload = im.setBackgroundWPOnLoad;
  im.src = bgUrl;
  document.body.style.background = im.bgSty;
  createCookie('wpcookie',bgNumber,7);
}

Disabling JavaScript reveals a tiny bug within Vistered Little: The initial background style refers to the wrong directory within functions.php.spitOutWallpaperCSS() :

// nono print "/images/" . $wallpaper . "') top center fixed; }n";
print "/wallpapers/" . $wallpaper . "') top center fixed; }n";

0 comments.

Editieren in WordPress 2.1 - Versteckte Schätze

Posted on February 8th, 2007 by Reiner.
Categories: Deutsch, Computers.

tinymce-advanced_toolbar_2.gif

Wie kann ich Text aus der Zwischenablage ohne Formatierung einfügen? Wie kann ich eine Formatierung löschen? Dies und noch mehr ist gut im Advanced Toolbar des Editors versteckt, der sich mit <Alt>+v oder <Alt>+<Umsch>+v (je nach Browser) ein- und auschalten lässt.

Gefunden bei WordPress 2.1 - More Editor Options.

0 comments.

New Theme: Vistered Little is Great

Posted on February 6th, 2007 by Reiner.
Categories: English, Computers.

I always wanted to have it, because it’s just hilarious: Vistered Little.

It appears to work properly with WP 2.1 and even with WP-Cache 2.1, as far as my requirements are concerned.

Points to keep in mind:

  1. Switching backgrounds requires JavaScript
  2. There’s a tiny ommision within the file vistered-little-1/index.php, which prevents the footer to display properly, only if your web server’s scripting default is not set to PHP.  Look for “<?” at “<?php } else { ?><p class=”footertext”>” and change it to “<?php”, so that your web server knows precisely, which script processor should be called.
  3. I didn’t find any admin link, so just navigate to <your blog url>/wp-admin

Many Thanks to Ricardo Galli for creating the most-wanted WordPress theme in the world!

0 comments.

Problems with WordPress 2.1 and IIS and TinyMCE

Posted on February 5th, 2007 by Reiner.
Categories: English, at other Locations, Computers.

After upgrading to WordPress 2.1 strange things cropped up: Editing posts was unacceptably slow (after 2 minutes browser still showing xx left), icons were missing from the visual editor, and other weirdnesses made it virtually impossible to create or revise posts.

It took some time to identify the cause: With WP 2.1 running under Microsoft Internet Information Server (IIS) ISAPI, TinyMCE tries to access the webserver using https seemingly at random :-( This is caused by tiny_mce_config.php trying to determine whether the original request used https in a way that does not work with IIS and ISAPI. (more…)

0 comments.

Upgraded to WordPress 2.1 and WP-Cache 2.1

Posted on February 4th, 2007 by Reiner.
Categories: English, at Home.

The upgrade was quite painless but still took me 2 houres to complete, because (more…)

0 comments.

Older » « Newer