Pro Tip: Check It Yourself

Yesterday I was pushing a module of new code to the blog site of a moderately famous celebrity that is still creaking along on Movable Type (the site, not the celeb). I've not really had to work with Movable Type much before so it was a little bit interesting and I learnt a few bits and pieces.

The code module was working exactly as expected on the development site so I was a bit surprised when it failed on the production site, truncating the rendering of some posts.

Debugging code on a production server is a tricky business (especially when you can't find the error logs), but I tracked it down to this:

PHP Fatal error: Call to undefined function: file_put_contents() ...

The function file_put_contents() was introduced with PHP version 5, so this error indicated the production server was running some version of PHP4. This kind of disparity between production and development environments is certainly not the optimal configuration, but it's not entirely uncommon when working with legacy systems. The problem for me yesterday was that it took me a lot longer to identify and fix the problem because I was sure that the production site was on PHP5...

I'd asked the rest of the development team if the sites I was working on with this module were on PHP5, they were pretty sure they were, but recommended I checked with the ops team. A member of the ops team told me they were all on PHP5 too. I don't know if the error was due to a chat-window miscommunication, lack of familiarity with the site, or just a genuine mistake - it's not really a big deal. In reality, it probably would have been quicker to just check the phpversion() myself when I first thought to ask about it - I would have discovered it was on PHP4 and altered the module's code before I tried to push it to the production environment.

IE8 Ajax Caching/Session Issue

Today I spent a bit of time trying to track down an ajax problem the was only occuring in IE8.

The ajax funcionality was calling a static URL which returned a JSON result containing the html to display login buttons depending on the user's state. The call was made via jQuery.getJSON(), which is wrapper function for .ajax() and .parseJSON()

The problem was that IE8 was exhibiting fairly unpredictable behaviour, sometimes it seemed that call was not firing, other times it appeared to return the opposite result I was expecting.

Initially it looked like IE8 was not passing the user's session. A quick Google search returned a number of threads where developers had assumed this to be the case, but there were very few constructive suggestions in addressing the issue. Eventually I spotted something where the true issue had been identified as IE8 caching the ajax response.

I added a cache-busting parameter to my ajax URL using the following javascript and voila, everything starting working as expected.

"...&cachebuster="+Math.random()

Hopefully this short post will save you some IE8 related head-scratching.

Wordpress colorpicker.js

The Wordpress wp_enqueue_script reference page lists Colorpicker as one of the default scripts imstalled, but doesn't offer any clues on how to implement it. The link on that page (currently) points to http://mattkruse.com/ which has no details on how to use it either.

The best online reference I've found so far is Matt Kruse's JavaScript Toolbox - Color Picker Swatch Popup which suggests you look at http://www.javascripttoolbox.com/ which doesn't have any documentation about colorpicker.js. Here's a link to the cached version of the documentation page just in case the source page is taken down: http://webcache.googleusercontent.com/search?q=cache:nlxkcPxsepEJ:mattkruse.com/javascript/colorpicker/

The javascript file /wp-includes/js/colorpicker.js is minified and browsing it doesn't easily reveal anything. There's a lot more information in /wp-includes/js/colorpicker.dev.js but it's not as straightforward as it could be.

What you need to do:

Include the colorpicker javascript file:
wp_enqueue_script( 'colorpicker');

Create a colorpicker object and hidden div, preferably put this near the end of your page:
<SCRIPT LANGUAGE="JavaScript">
var cp = new ColorPicker(); cp.writeDiv();
</SCRIPT>

Set up the input field and picker anchor tag:
Color: <INPUT TYPE="text" id="color2" name="color2" SIZE="20" VALUE=""> <A HREF="#" onClick="jQuery('#color2').each(function(index){cp.select(this,'pick2');return false;});return false;" NAME="pick2" ID="pick2">Pick color</A>

Alternatively, you could also try this approach where you ditch the anchor tag and use some jQuery to handle the rest:

<INPUT TYPE="text" id="color2" name="color2" SIZE="20" VALUE="" class="jColorpicker" >

<SCRIPT LANGUAGE="JavaScript">
jQuery(".jColorpicker").bind("click", function(){cp.select(this,jQuery(this).attr(\'name\')); });
</SCRIPT>


Conclusion
This snippet of code is showing it's age and there are better options out there if you need a color picker. The more I try to use it the more I become frustrated with it.

jQuery UI doesn't have a native one (yet) but I am guessing that will come in time. For now, probably the best candidate is the jQuery plugin jPicker from Digital Magic Productions.

Firefox 3.6.6 redirect issue

Today I spent a chunk of time investigating an issue related to redirecting browser requests for media files to the CDN (content delivery network) for that domain. The redirect was being thrown into a redirection loop. The curious thing about the issue is that it only affected users using Firefox 3.6.6 on Microsoft Windows.

I tested the MP3 player in Opera, Chrome and even Internet Explorer and everything performed as expected, but when I used Firefox 3.6.6 it failed every time for any file. Then I checked it in Firefox 2.0 and Firefox 3.5.10 - both did not reproduce the issue. I checked it in Firefox 3.6.6 on an Apple Mac and the issue could not be reproduced. Neither could it be reproduced in Firefox 3.6.7(beta) on Windows.

Multiple Firefox Installations
I decided to grab Firefox 3.6.4 (the previous release - there was no 3.6.5) and install that to see if just this version was experiencing the issue. To do this I decided to set up another Firefox install - If you've not done this before, there's a great guide here: http://idizyn.com/development/installing-multiple-versions-of-firefox/ The post is pretty old, but what worked for Firefox 1.5 and 2.0 still works now.

Installing Firefox 3.6.4 confirmed my suspicion that this problem only occurred so predictably in Firefox 3.6.6.

What Caused This??
I recorded the headers for different browser versions using Live HTTP Headers. This highlighted that Firefox 3.6.6 was being thrown into redirection loop, but didn't explain why. I added timestamps to the redirection point and saw that the redirection was not reflecting any change in that, so some level of caching was involved - but this cached result did not occur for any other browser version (even on the same machine).

I disabled my Add-ons, flushed my cache, and restarted the browser multiple times to no avail - I could not isolate either a cause or a solution. At this point I can only suggest there is a problem with this release of Firefox causing the problem.

Firefox 3.6.7 is currently slated for release on 20 July 2010 (in 6 days). Hopefully this will address this issue and many users will quickly upgrade without us having to suggest it as a solution to this issue.

WordPress Broken Theme : Template is missing

I came across an interesting bug on a Wordpress development project I was working on this week. The issue was that the Wordpress Theme was reported as a Broken Theme because the "Template is missing" on the Appearances->Themes admin page.



In most cases the site was performing as expected using the allegedly broken theme, however the custom template selection was no longer available on the Pages admin page. (This is where I first spotted there was a problem and then discovered the Appearances->Themes admin page.)

After poking about for a bit, I traced the problem to a rather innocuous looking line the designer had added to the theme's style.css file.

/* UNIQUE CATEGORY TEMPLATE: VIDEO*/

It's just the "TEMPLATE:" portion that caused the style.css parser to fail. This line works just fine:

/* UNIQUE CATEGORY TEMPLATE : VIDEO*/

I doubt this error comes up often, but it took a few minutes to track down the problem so I thought I'd post something here to hopefully save somebody time in the future.

Google Buzz Button IE8 Error

Recently Google introduced their Buzz buttons to "Help people post your content on Google Buzz". Share buttons are not a new idea, but Google Buzz is new and kinda shiny. Here's a quick intro if you're not up to speed yet:



And here's a Buzz button:   

A few days ago I implemented the Buzz share buttons on a website at the clients request and it all seemed to be working great, until this morning I found that some pages were failing to load in Internet Explorer 8.

I pointed IE8 at the development site and confirmed there was a serious problem. The error I recieved was thus:

Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Timestamp: Thu, 22 Apr 2010 13:33:25 UTC
Message: HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917) Line: 0 Char: 0 Code: 0

I disabled the Buzz button to confirm it was part of the problem (which it was), and then checked my implementation against the documntation and other sites. Everything seemed to be OK. After a long period of debugging, and following up false leads it turned out to be that Internet Explorer was executing the Google Buzz button's javascript code too early - even when it was in the page footer.

The Solution:
Once again jQuery came to the rescue - I replaced this line:
<script type="text/javascript" src="http://www.google.com/buzz/api/button.js"></script>

with this line:
<script type="text/javascript">jQuery(document).ready(function(){jQuery.getScript('http://www.google.com/buzz/api/button.js');});</script>

Managing WordPress Filters

WordPress filters offer a great way to control many aspects of the way the WordPress engine processes or publishes information, without hacking any of the core code.

In recent projects I've found filters to be the easiest way to manage many of the functionality requests the client has made. Some examples of the are: RSS formatting, custom Avatars, auto rendering images/links in comments, controlling the Category used in permalinks, reformatting legacy data in posts, and even tweaking the behaviour of Admin pages.

All these changes can add up to quite a chunk of code and functions.php was getting quite large and difficult to maintain with all the other general functions in there. I decided to move all the filter functions and add_filter statements into a separate file called functions_filters.php and include it from functions.php. This made it much easier to add/maintain filters and localised the changes to that dedicated file.

It's an incredibly simple idea, but I highly recommend taking this approach if you are implementing filters to any degree.

If you've not used filters but want to learn more, you can find a good introduction here: http://codex.wordpress.org/Plugin_API/Filter_Reference