In theory a clean head should make parsing easier for search engines. Search engines don’t really care what CSS files you use or where you are pulling your Javascript from but they obviously care about your content.

Head Cleaner also allows you to combine and compress your Javascript and CSS. It also enables you to move Javascript to the bottom of the page. This method is appropriate for unobtrusive Javascript files that run after the page has loaded. You can also select Javascript files you don’t want to include on the page. Sometimes you might have an older plugin that includes an additional version of jQuery. I’ve seen some sites that are loaded with tons of Javascript files that could be helped greatly by the functionality of Head Cleaner.

Another nice feature is the ability to remove filters that run in the head. Sometimes your plugins may include a filter that you might not want to run due to incompatibilities with other plugins you are using.

There are many more features and I encourage everyone to try it out on their WordPress site. Some features work better if you have caching enabled on your WordPress installation.

The developer, who can be found @wokamoto on Twitter,  is going to be speaking at WordCamp Yokohama and was also responsible for putting the site together. He has a nice series of posts on his site that detailed his development process and what plugins he used. Unfortunately it is in Japanese but the lists are in English.

Another tutorial came out on the 22nd and cleared up some things for me. I’ll probably end up writing something explaining my code in the near future. The current version of it has a lot of comments in there.

Check out the plugin at the code page.

I’ll be updating the plugin based on feedback. This is the initial release but I have been using this plugin personally for quite a while and I am happy with the functionality.

You can read it about it here or download it directly.

When you want your data to be accessible from a different domain you must take your JSON and turn it into a callback function in order to let the data be read inside the browser. The easiest way to do this is by reading the callback value from the get and putting it around the JSON output.

<?php
$arr = array ('a'=>1,'b'=>2,'c'=>3,'d'=>4,'e'=>5);
$json = json_encode($arr);
$callback = $_GET[callback];
echo $callback . '(' . $json . ')';
?>

If you do this you’ll have no problems interacting with jQuery’s getJSON function and you’ll be publishing your data in a very portable format.

<script type="text/javascript" src="<?php bloginfo('stylesheet_directory'); ?>/js/jquery.js"></script>
<script type="text/javascript" src="<?php bloginfo('stylesheet_directory'); ?>/js/1080d.js"></script>

Unfortunately this method isn’t compatible with some plugins. If you have a plugin that wants to use jQuery it has no way of knowing you have already included it on the page.

The proper way to add your Javascript is to use the wp_enqueue_script function. This is how I add it now.

wp_enqueue_script('jquery');
wp_enqueue_script('1080djs', get_bloginfo('stylesheet_directory') . '/js/1080d.js', array('jquery'), '20091014' );

If you want to be really fancy and put your Javascript at the bottom of the page in order to make YSlow happy, you can set it up like this:

wp_enqueue_script('jquery', '', '', '', '', TRUE);
wp_enqueue_script('1080djs', get_bloginfo('stylesheet_directory') . '/js/1080d.js', array('jquery'), '20091014', TRUE);

Then your Javascript files will be included when the wp_footer(); function is called. Otherwise they are included when wp_head(); is called.

CSS files can also be managed the same way with the wp_enqueue_style function. Using both of these methods will help you make sure your themes more portable and compatible with plugins.

One of the reasons I am such a fan of WordPress is the ubiquity of the platform it runs on. The large majority of hosting providers have low cost PHP hosting. The LAMP stack is most widely supported platform on the web. While this may mean a greater chance of running into an exploit, a solid provider should keep their environment properly maintained with the most stable and secure versions of each application.

Because there are no license fees involved with WordPress you only have to worry about relationships with two vendors – Your developer and your hosting company. If you use a cpanel based hosting solution then picking up your entire site and moving it to another hosting provider that supports cpanel is incredibly easy. If your relationship with your developer turns sour there are many competent WordPress developers out there.

A ubiquitous platform leads to choices and freedom. You don’t have to worry about paying for expensive “enterprise” software. You just hit the ground running and customize your platform and focus on making it the perfect fit for organizations of any size.

These types of apartments should sell well. People can be quite comfortable in smaller apartments if they are designed well. Computers and technology a small apartment convenient and entertaining.

You can see how they retrieve events from the Google Calendar API. This code uses Google’s code for making the request and parsing the result.

jQuery makes it much nicer:

$.getJSON("http://www.google.com/calendar/feeds/developer-calendar%40google.com/public/full?alt=json-in-script&callback=?",

function(json){

var html = '<p>Total of ' + json.feed.entry.length + ' event(s)</p>';

html += '<ul>';

$.each(json.feed.entry,function(i,entry) {

html += '<li><strong>Event title:</strong> ' + entry.title.$t + '</li>';

})

html += '</ul>';

$('#outputDiv').html(html);

});

The important bits are attaching “?alt=json-in-script&callback=?” to the end of the uri of the calendar and using jQuery’s each function to loop through the result.

It is also quite easy to turn PHP arrays into JSON. The json_encode function worked quite well for me.

We had some initial difficulty handling the traffic. It was hosted on a development server which didn’t have as much RAM as an actual production server. We were able to move the site quite easily because it is a WordPress installation inside of cPanel. There was a small mod_rewrite issue that caused some urls to redirect but we were able to resolve it and the site seems to be well situated for future traffic.

Digg traffic has been largely non-existent despite 88 people pushing the Digg button. Only 79 visitors have come from Digg.com. I have seen a couple of hits from their new URL shortening service. I would be interested to see if the Digg Toolbar leads to increased traffic.

Developing themes for different resolutions is becoming more and more important.