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

Suppressing Link URL In WP Media Library

UPDATE: You can now set the default action by adding the following code to your functions.php file.

update_option('image_default_link_type','none');


---

It's been a while since I've posted anything here (I've been pretty busy lately), so when I threw together a quick fix for a WordPress installation today, I thought I should put a quick note about it here.

The Problem:
When inserting or attaching an image to a post with WP's Media Library the Link URL is always pre-populated with the URL to the file. To remove this URL so that the image is not linking to the original file, users must go through the arduous process of remembering to click the "None" button before inserting the image.



OK, that was a little sarcastic, but that's pretty much what the feature request was saying. They wanted the field's behaviour to change so that the default was blank.

The Solution:
To create the desired behaviour, I created the following function and hooked it to the attachment_fields_to_edit filter to clear out the URL before it is displayed.


// hide the URL by default for people too lazy to click "None"
add_filter('attachment_fields_to_edit', 'suppress_linkURL');
function suppress_linkURL($fields) {
$img_url = $fields['image_url']['value'];
if(!empty($img_url)){
$html = $fields['url']['html'];
if(!empty($html)) {
$fields['url']['html'] = str_replace("value='$img_url'","value=''",$html);
}
}
return $fields;
}

I doubt there is going to be a lot of demand for this particular snippet of code, but hopefully somebody will find it helpful.