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.
After owning an Android phone for over an year, and using it on daily base, I thought it might be time to look into how easy it would be to start developing for the Android OS. As any good developer I first started reading a bit on how to develop for it, and what requirement’s I would have to meet.
Now I’m not going to be boring you with all kinds of tutorials on how to develop on Android, or give you any other clues on this subject. I just don’t know anything about Android development, well not yet anyhow. But some good reading material to get you on the right path might be:
The only thing I have learned so far is that I don’t really like the way of designing a UI for the Android. It’s just way to basic with XML files describing how the UI should look like. Feels like going back to 1990 when designing a UI was done in code rather then with a UI design tool.
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 greatest things about version control systems is the ability to keep track of changes. Or is it? Well Microsoft certainly has a unique look on this. Team Foundation Server (TFS), also known as the Team Failure Server, has a very unique way of keeping track of changes.
To be honest the tracking of changes works fine, for the most part. But what happens when you made a change sometime in the past, you know roughly what you did but not which files were affected or which branch was used. Yes I sometimes don’t know what version (branch) of the software a fix was made in. In any normal version control system you would open up the history log and start searching for a comment you entered. That would result in some result popping up, and with any luck the change-set you were looking for.
Alas Microsoft in all its wisdom decided that searching is overrated and not needed for a version control system. After all you can read through the entire history log to find the change-set can’t you. Ah you can’t, silly you!
Here is a quick work around for this ‘missing’ feature:
Voila now you can search. At least Excel offers a way to search your Team Foundation Server history.
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.