As part of the new theme I’ve been developing I’m including some richer user features. Like on the spot loading of comments and better mobile device support. One of the things I need to figure out during the development is how to use Ajax in WordPress, preferably native support. I know it should be possible, but have yet been unsuccessful to get it working.
So what I’ve been doing is setting up a new action using add_action for the following two action types:
According to the documentation that should generate a hook to support both registered users (wp_ajax_<myaction>) and unregistered users (wp_ajax_nopriv_<myaction>). Which sounds great, since my theme should work for both type of users
.
On the front-end I’ve created a Javascript method that should call the ajax command using the ‘wp-admin/admin-ajax.php’. With as action parameter the name of my ajax method. So in theory I should be setup correctly to handle ajax, but this is where the theory and actual situation start to differ.
To test my new theme I’ve been using the preview mode of WordPress, after all I don’t want to kill any existing feature or activate the theme before it is done. But for some reason my nicely setup Ajax hooks aren’t working as advertised.
About a month ago I wrote something on creating a new UI for this blog. One that would be lightweight and a lot quicker then the current one. It might seem that I’ve given up on this new UI, but the opposite is true.
It’s been a rather busy couple of weeks since my last update, but work is slowly progressing. So far I designed most of the UI elements, but I ended up in some trouble with the browser compatibility. As any web developer will know it’s a hell to make a website compatible with older browsers, especially the older Internet Explorer versions. And as this is supposed to be a lightweight theme it means I’ll have to rely on as much of CSS3 as possible. Which also means making separate sylesheets for the older browsers to display the content the same way.
So far I’ve built the following features in the new WordPress Theme:
Now I still have a long way to go before the new theme is ready for deployment, but I’m slowly continuing the work on the new theme. Just to give you some insight on how the final version of the theme will look I’ve included some screen-shots of the latest development release.
Even when all the design stuff is done I’ll still have to do some integration of analytics software and the capabilities to show ads. As well as hooking back in all the various plug-ins I’ve been using for WordPress for the past couple of years.
One of the things you might encounter as a web developer is detection of the browser that a visitor is using. In my specific case this was needed since I wanted to use some CSS3 styling, but only if the browser was capable. In all other cases the visitor had to see the CSS2 optimized page.
So I started looking into a way to let my web application determine what browser was visiting and what capabilities it had. Since this was for the new WordPress theme I’m developing it had to be in PHP and be sorta light-weight.
First thing was to figure out the basic browser that was visiting. This can be done by doing a simple strpos call in PHP on the user agent property. Having a list of the various user agents helped, I found just such a list at UserAgentString. A brief summary for some common browsers is below.
$user_agent = $_SERVER['HTTP_USER_AGENT']; $IE = strpos($this->_user_agent, 'MSIE') > -1; $IPad = strpos($this->_user_agent, 'iPad') > -1; $Firefox = strpos($this->_user_agent, 'Firefox/') > -1; $Chrome = strpos($this->_user_agent, 'Chrome/') > -1; $Opera = strpos($this->_user_agent, 'Opera/') > -1; $Android = strpos($this->_user_agent, 'Android') > -1;
As you can see determining the basic browser type is pretty simple. But to be able to determine if CSS3 is supported you will also need to locate the version of the browser. Keeping in mind that IE9+, Firefox 4+, Opera 10+ and Chrome are the only versions that support CSS3. The check for this is slightly different for each version. But you can do it easily with a regular expresion.
// For all non IE browsers
$locator;
if ($Firefox) $locator = "Firefox\/";
if ($Android) $locator = "Android\s";
if ($Chrome) $locator = "Chrome\/";
if ($Opera) $locator = "Version\/";
preg_match('/'.$locator.'([0-9]{1,4}(.[0-9]{1,3})+)/', $user_agent, $version);
// For IE
preg_match('/MSIE\s([0-9]{1,2}.[0-9]{1,2})/', $user_agent, $version);
if (count($version) > 1) $version = $version[1];
else $version = 0;
Having the version and the type of browser allows us to do all kinds of fancy browser specific stuff. Mostly introduce hacks for IE7 (yes many are needed), or add CSS3 support.
As a major remodeling of this blog is on the way I’m going to try to build it more dynamic and more up to the Web 2.0 standards. So that includes usage of Ajax, JQuery and a more dynamically filled website. But how to build this and keep the Google Analytics working, as well as the search engine indexing. This will be one of my biggest challenges I’m afraid.
Developing a website with JQuery / Ajax and advanced JavaScript prototypes isn’t anything new to me. But having all of these features and still make the site indexable is! So far I’m stuck at the simple point that crawlers don’t support JavaScript, so no go for that part. It looks like I will have to create a module for the WordPress plugin to detect what type of user is visiting the website. Serving the search engines a version that will not use any of the advanced features that normal browsers will support.
Besides the issue with the indexing there is still the task of getting all the pages on the website to be tracked with Google Analytics. Currently that is easy, though the website is dynamic each page is a new request to the server. But using advanced features like Ajax stops that in its tracks. Currently I don’t even know if it is possible to track pages when the actual URL doesn’t change, just the content of the page. If it is possible to do this I would have to build a module to do so.
So after just ranting and brain storming for a few seconds I already found to nice features that would have to be build. Another person might call them serious issues, but I prefer good challenges. At least for the moment I do. Not even mentioning the fact that I have to build a complete new template for WordPress too.
It was recently brought to my attention that the WordPress plugin I use for posting images on this website was not working properly anymore, thanks for warning me of this issue. Well not working properly in the sense that images would get opened in the same window, with no options to navigate back to the post.
Initially I thought that this was caused by the plugin I use for this called NextGen Gallery. After all this plugin failed to do its job properly, but unfortunately that was a bit stupid thinking on my part. I should have realised that the plugin stopped working after an upgrade of the WordPress blog powering the website. For some reason the thickbox JQuery extension produced JavaScript exceptions.
I don’t know exactly why it doesn’t work like expected and I don’t really care either. Suffice it to say that changing a small piece of code in the ‘wp-includes/js/thickbox/thickbox.js’ fixed the issue. All I had to do is modify the tb_init function into the following:
function tb_init(domChunk)
{
jQuery(domChunk).bind("click", tb_click);
}
I think it must have been some conflict in the JQuery versions or something, since it used to call the ‘.live‘ method on JQuery. But this was what was causing the exceptions. If anyone knows a more permanent fix for this issue please let me know.