It just so happens that I’ve had a request for a customisable header image on an future project, so decided to have a play and see how difficult it is to implement. Well it isn’t difficult at all, very simple in fact.

First you will need to edit your functions.php located in your theme directory. Go ahead and create one if it isn’t in the directory. Now copy and paste the code below into the file. I’ve commented the code but it’s all quite self explanatory. Change the height and width of the image and change the directories where needed.

By adding the code above you will now see a new option under “Appearance” in the admin panel called “Header”. From there you should be able to see all the images and options we just set in the functions.php file. The only thing left to do now is add the header image to the theme.

Where you place the following code will be depend on your theme setup; I’ve decided to place it in the header.php file as I want the image to appear on every page. You may only want the image to appear on specific templates e.g. pages, archive, category (you could also use WordPress conditional tags to do this).

And there you have it, one header image that you can customise via the WordPress admin panel. An ID is attached to the image for CSS styling where needed.

The example above is quite a simplified version of the header image functionality. It is possible to place text over the image and even have a different image per blog post by using the custom thumbnail functionality, but these are beyond the scope of this blog post. Copy & paste and enjoy!

So anyway here are a few things I learnt along the way:

• There are some very simple yet powerful templating rules you can use to style your website. Learning how they work will really help you style specific pages and blocks.
• Looking for some functionality that is missing by default? I bet there’s already a module that does the job. Check out Drupal modules, this excellent website lists and rates thousands of Drupal modules which you can install and use.
• If you do find a module that adds the functionality you need, double check that there aren’t other modules about that do it better. Since Drupal has been around for some time, many modules haven’t been updated in quite a while so they may just be occupying the name space. It’s always best to check before you dive into using one particular module as it may not always be the best route to take.
• Learn how to use the Content Construction Kit (CCK). If you are missing a type of CCK field, look for an additional module; I’m sure there will be one you can install that does the job. You really can make content types do anything you want with CCK.
• Learn how to use the Views module. I really can’t express this point enough. The Views module is without a doubt one of the most powerful additions to any CMS I’ve ever come across. With it you can take any content and display it however you like on a page. The layout is a little intimidating at first, but once you get your head round it you will have a dynamic site up and running in no time at all.
• Install the ImageCache module. It ties in with both CCK and Views allowing you to upload and display images on your site however you need to. If you add a new image preset the module will automatically iterate over old images so you never have to go in and manually adjust images if you change your site design / functionality.
• One thing I missed from Drupal was the ability to add parent / child nodes. Luckily theres a module called Node Hierarchy that will add this functionality. It even handles the breadcrumbs and Views for you. Note: Make sure you don’t have ‘Taxonomy breadcrumb’ enabled with Node Hierarchy as the breadcrumbs won’t work. I learnt that the hard way!

Hopefully other budding Drupal users found the tips helpful. I’m still a Drupal novice, but now I know the basics the site possibilities are endless.

Back when Snipplr was young, Tyler Hall wrote a WordPress plug-in for Snipplr that allowed you to embed your snippets directly into your posts. What a great idea; unfortunately it hasn’t been updated since 2006 and much has changed in the world of WordPress. Enabling the plug-in in it’s current state is a little flakey; so I’ve decided to update it for WordPress 3.0+.

The plug-in is called ‘Snipplr Snippets’ and is available to download from the WordPress plug-in repository. I’ve used many of the functions that were in the old plug-in so it isn’t a complete rewrite but much of the structure has changed (big thank you to Marcin Dominas helped with a couple of issues i was having at first).

Snipplr Snippets sidebar widget in action.

The administrator area has been updated and there are a couple of new features available which hopefully are self explanatory. I’ve also updated to the latest version of GeSHi for the syntax highlighting, if you don’t like the look a feel of the outputted code simply disable the plug-in CSS in the site header (admin panel), copy to your style.css and modify as needed. For the plug-in to work you will need a Snipplr account and an API key (available from the settings page).

Once you’ve installed the plug-in and enabled it, it’s dead simple to include a snippet into your blog post like so:

Where the ## is the ID of the snippet you wish to include in the post (you can get this from the snippet URL). The code below is pulling in a snippet directly from Snipplr using the plug-in:

I’ve tested the plug-in and it seems to work fine, there was a warning from the CodeColorer plug-in because it also uses GeSHi for syntax highlighting but I haven’t noticed anything break because of it. If it does please let me know and I’ll fix it. If you have any suggestions / bugs leave a comment and I’ll see what look into implementing / fixing them. Download here.

Luckily there are already many plug-ins available for WordPress that can get you started on your way, one that really grabbed my attention was ‘WordPress Mobile Pack‘ by MobiForge. The plug-in contains a mobile optimised theme that you can adapt for your needs and the ‘mobile switcher’ functionality. Mobile switcher detects if a user is browsing from a desktop or a mobile phone and switched the theme accordingly. Great, we’re already half way there!

One of the specifications for the site was that it must work on a set of 4 different screen widths (480px, 320px, 240px and 176px) and this is where the DeviceAtlas API comes in very useful. Device Atlas keep a huge database of mobile phone user agent strings plus specifications associated with a particular mobile phone that you can tap into and use in your web application.

Now one thing I must mention is that according to the mobiForge page listed above, WordPress Mobile Pack includes DeviceAtlas integration. This turns out not to be the case. I couldn’t find any settings regarding DeviceAtlas in the plug-in admin area and very little mentioned on the forums. I assume the page hasn’t been updated for a while and the functionality has been removed. This isn’t a problem though as it’s fairly simple to integrate the DeviceAtlas API into your PHP application i.e. WordPress. Here’s how you do it.

First you must register with DeviceAtlas and order a developer licence (there’s a free option available here). Once registered grab a copy of the PHP API and the latest Device JSON file (under ‘My account’). Unpack the API into the root of your web application (or wherever you like, just make sure the includes are set correctly) and copy the JSON file into the json directory along side it. You are now ready to include the API into the base WordPress Mobile Pack theme. Copy and paste the following into your header.php above the doctype:

Great now we know the user agent that the user is using to view the website (well it may not be 100% accurate but better than nothing). So now you want to query the JSON file and pick out the relevant phone specifications you need. I’m just looking for the width of the device, so I included this in the head tag:

All this code does is find the display width of the phone viewing the website and add a CSS file with relevant site tweaks, allowing you to optimise for that screen size. If the device isn’t found I’ve defaulted to a screen size in the middle of the screen sizes.

Looking through the API docs there are plenty of ways to distinguish between your users, using the following code will allow you to target specific phone brands:

So now you can target only Nokia users. Or instead of loading a different CSS file you could include a different sized image for different screen widths; there are tonnes of options available.

I must admit I really dislike having to ‘sniff’ for the user agent string and having a different CSS file / image per device width, it reminds me of the Netscape / IE browser war days, oh how much fun that was! I guess it’s a necessary evil.

A word or warning when it comes to DeviceAtlas, there seems to be distinct lack of support available. I wrote a couple of emails asking questions and got no reply, and lots of questions on the forum are left unanswered. So if you get stuck you may need to figure it out for yourself I’m afraid.

All in all I’m pleased with the results of my first adventure into the world of mobile web development. I still have lots to learn so if you have any tips and tricks please let me know!

Update 2: DB Cache Reloaded has now been updated and works flawlessly in 3.0, get it here.

I’ve been eagerly awaiting the release of WordPress 3.0 (due any day now!). I plan on making a few changes to my blog once it is released so decided to try out Release Candidate 1 on my development server. At first it all went fine, upgraded the database no problem… then a blank page. Weird! After a couple of page reloads the sparkly new dashboard popped up (it’s not that different, although it does look greyer). Clicking around the admin area I could see this blank page error was randomly occurring on different pages; bugger!

My immediate thought was a plug-in I had installed, as I’m sure this rather large error would have been picked up while testing the WordPress core functionality! Looking at my Apache error log the following error was listed:

The error is too vague to actually help, but after a little investigating (and from a hunch I had) I disabled any plug-ins involved in page caching; namely DB Cache Reloaded and Hyper Cache. Unfortunately disabling them still didn’t fix the error, so I decided to remove them completely (db-config.ini, advanced-cache.php and db.php removed from the wp-content directory). Suddenly no more blank page errors occurring! Huzzah!

So if you come across the same problem, then check what caching plug-ins you have installed. When 3.0 final is released I’ll be doing a fresh install of both plug-ins. Hopefully that will solve the issue. They are both quite popular plug-ins so I’m sure others have had the same issue.

To add a gallery (or album) to a post / page is as simple as adding ‘[ nggallery id=x ]‘ to the post content… super! One issue though… what happens when you allow a client to edit and add new pages; well what usually happens is the tag gets deleted or changed, the gallery breaks, client panics and the virtual world ends (well not quite, but close). A technique I have been using to help solve this issue involves using WordPress custom fields and the excellent Get custom field values plug-in. You can grab the custom field values directly from WordPress using get_post_meta() but the plug-in makes it much easier.

Digging through the nggfunctions.php file in the NextGEN gallery plug-in folder reveals a whole host of useful functions that can be easily called directly from inside your WordPress theme. So say you wanted a gallery in a post page, but didn’t want the client to have to remember ‘[ nggallery id=x ]‘ every time, simply add this code next to your content in the single.php file:

Add a custom field of galleryID with an integer value linking to the relevant gallery and you’re done. Now the client can pick out the galleryID custom field from a drop-down since WordPress remembers the custom fields used. Much easier for a client to remember than adding the tag every time.

I highly recommend looking through the nggfunctions.php file, here are just a few functions that are available:

• nggShowAlbum(): Show a whole album depending on the ID.
• nggSinglePicture(): Show a single picture from an ID.
• nggShowRandomRecent(): Show random image(s) from a certain gallery.
• nggShowSlideshow(): Show a flash slideshow pulling images from a specified gallery.

I have used nggShowRandomRecent() quite a few times in the past few months, here’s a quick example:

Pick 6 images at random from a selected gallery on page load, very simple and effective.

Note: When using the random images function make sure you don’t have any WordPress caching plug-ins running on the selected page, else it won’t work as the page gets cached on first load. It took me a good 15 minutes to figure out why the function had suddenly stopped working due to this slight oversight.

At the moment there’s very little difference between Frog and Wolf as you might expect, so migrating from one to the other is fairly simple, a wiki page has been created with instructions on how to do this. As it says on the page it’s probably best to decide between the two versions now since there’s still little difference between them, but this could change in future versions (version 0.6.0 introduced a number of large changes). So there may be a point where it isn’t (easily) possible to jump between the two versions.

So what are the differences at the moment? When version 0.6.0 of Wolf CMS was released on the 1st February it added a new core plug-in called ‘BackupRestore’, allowing admin users to easily backup the Wolf CMS core DB tables. I’ve been using an external plug-in to do this on sites I built, so having this feature added as a core plug-in is nifty addition. Other features include:

• Admin users can now uninstall plug-ins, including the db tables
• HTTPS Support added to the admin area for greater security
• You can now preview a page before it is published

It’s great to see that such a useful little CMS hasn’t been left to stagnate and die out, the roadmap for Wolf CMS looks promising, so fingers crossed it has a bright future ahead of it. I think it’s time to migrate my Frog websites over to Wolf…

Purely for styling I needed to add an extra span to the title and a div to the widget wrapper. After searching through the Codex I came across the perfect solution:

You simply create an array with your custom settings and pass it into the register_sidebars function along with the number of sidebars you wish to register; paste that into the functions.php file in your theme and you’re done. If you don’t have a functions.php file you can just create one. All the settings are pretty self-explanatory and with these changing widget markup is easy.

On a side note; I’ve never been a big fan of using nested lists in the sidebar, I’m not sure it’s semantically correct; but I guess it does the job and works even when CSS is disabled.

You learn something new everyday!

Some people may have deleted the default account for security reasons (very good idea) or they have more that one administrator account. After hunting about on the WordPress forums for a while I managed to piece together a little snippet of code to do this:

I placed it into it’s own function within my plug-in Class so it can be called whenever needed. It could also be used for finding users with different levels in WordPress if needed. If you wanted you could modify the function to accept an argument admin_user_ids($the_user_level_i_need); allowing you to get the IDs of users at whatever level you like.

There seemed to be a few ways of doing this on the forums, but this one works for me at the moment.

First thing I had to do (for my own sanity) was move the layout template outside of the CMS and into an external file. This gives you 2 advantages, you get to use whatever code editor you usually use to edit the template, and the file is then exposed so it can be committed to version control like any other file. It is simple to do with some very basic PHP:

Paste that code in to your layout with a content type of “text/html” and you are done.

The second code snippet allows you to generate a specific ID and class for every page; great if you need some CSS style / JavaScript hooks on different pages.

The first if else statement simply sets the home ID to “home” then every other page to “page-slug-name-here” (slug is set in the ‘Meta’ tab). The second one I use on ‘article’ pages; it simply says if the current page has a parent and its parent is the services page add a class of “event”. So now I can style every article page in the same way, and it’s safe for a client to add event pages themselves.

You may ask why the “$this->parent()”; this is to stop the site breaking when you hit the home page since the homepage has no parent, it is the parent of all other pages.