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

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.

jQuery image roll-overs

On the site I am currently working on I needed to implement hover/roll-over states for a number of image tags. Other elements in the site use the CSS based x:hover{background:y} approach, but that was not an appropriate solution for these instances - background images were not going to used, so I came up with a nice jQuery based solution that keeps my page-source pretty uncluttered too.

I added a class value of "hover" to the image tags I wanted to exhibit this behaviour. The replacement images all had the suffix _hover added (e.g. theimage_hover.png )

<img src="/images/theimage.png" class="hover">

Then in my main javascript file I added this little snippet:

function imghover_on(img){if(img.src.indexOf('_hover.')==-1){img.src=img.src.substr(0,img.src.length-4)+'_hover'+img.src.substr(img.src.length-4)}}

function imghover_off(img){img.src = img.src.replace('_hover.','.');}

jQuery(document).ready(function(){
jQuery("img.hover").mouseenter(function(e){ imghover_on(this);});
jQuery("img.hover").mouseleave(function(e){ imghover_off(this);});
});


This code declares two functions which add or remove the "_hover" suffix to the image tag's source, while not needing to know if the image is .png .gif or .jpg.

The jQuery statement waits for the page to load and then finds all img tags in the document with the hover class set and binds the function calls to the mouseenter and mouseleave. This saves me from having to add these events to every single image tag manually like this:

<img src="/images/theimage.png" onmouseover="imghover_on(this);" onmouseout="imghover_off(this)">

Notes:

• I used mouseenter/mouseleave as they fire a lot less than mouseover/mouseout (see: http://docs.jquery.com/Events/mouseenter )
  
• It's not infallable, a .jpeg file extension would fail, but it's working nicely for first cut.

WordPress Theme URL Tip

Lately I've been putting a lot of hours into developing a couple of sites using the WordPress and WPMU platforms. These platforms are a solid starting point for pulling a content/post based site together relatively quickly - the wealth of useful plugins also helps reduce the chance of you having to re-invent the wheel.

Having said that there is still a lot to do to create a professional website that has it's own look and feel - much of this can be achieved by creating a custom theme.

If you are creating a custom theme you will probably need to link to multiple elements within that theme's directory structure. The most common approach to do this is somthing like this:

<img src="<?php bloginfo('stylesheet_directory'); ?>/images/myimage.png">

<?php
echo '<img src="'.get_bloginfo('stylesheet_directory').'/images/myimage.png">';
?>

I've certainly been using a lot of the latter style, until today.

I decided to clean up my code a bit and put the following line at the top of my theme's functions.php file:

<?php
if(!defined('WP_THEME_URL')) {
define( 'WP_THEME_URL', get_bloginfo('stylesheet_directory'));
}
?>

Then I replaced all the get_bloginfo('stylesheet_directory') instances with the constant WP_THEME_URL. Now my code is a lot more readable and there is less typing.


<img src="<?php echo WP_THEME_URL; ?>/images/myimage.png">

<?php
echo '<img src="'.WP_THEME_URL.'/images/myimage.png">';
?>

Using a constant like this should provide a slight performance increase here too - I haven't done any performance tests, but the current get_bloginfo() process is a fairly convoluted chain of function calls.

Note: Just in case the WP platform does start using this constant in the future, the constant's value is not set if it is already defined.

UPDATE: After this post was made I discovered WordPress defines a TEMPLATEPATH constant, but no constant currently exists for the TEMPLATEURL.

Animated "Loading" Image Generator

Yesterday somebody sent me an email introducing me to http://www.ajaxload.info/ and it's such a handy tool I thought I should share it here.

Generate a customised animated gif by choosing the style you want, the background and foreground colors and whether the background should be transparent.

Here are some quick examples...