Setting a menu item as ‘current’

We would always like to know where on the site we are on each given moment. For that, we always expect to see a special mark up for the menu item that refers to the page we’re in. To Realize such a thing, we assign a special css class (almost always containing the string ‘current’) to the said menu item, and apply special style rules to that class

As a general rule, WordPress always sees to add such a mark up to its menu items. For instance: when you’re in a certain page, the menu item that refers to this page, would always get a special ‘current’ class – probably: “current_page_item”. If your menu contains a link to a category, on the category page that the link refers to, or for each post belonging to this category, the relevant menu item will be assifned a special class – normally: ‘current-menu-item’ or ‘current-parent-item’.

However, there are times when WordPress fails to make the connection between a menu item and a post/page. For instance: you have created a special page that lists recipes from all recipe categories on your site. You call it ‘recipe main page’ and you refer to it from the ‘recipe’ menu item on the main menu. When on this page, the menu item ‘recipes’ is assigned the ‘current’ css class. But as soon as you pick an actual recipe from the list within the page and load the recipe page – even though logically you are still in the ‘recipes’ section – WordPress wouldn’t know to assign the ‘current’ class to the ‘recipes’ menu item any more.

In order to solve this – we should intercept the actual menu output and add an action to it – to always check, for instance: are we on a recipe page, and with that, are we right now handling the ‘recipe’ menu item? If so, then we should add the current class to it.

Luckily – WordPress provides us with a filter to do right that: the filter name is ‘nav_menu_css_class’ and it passes and processes the array of class for each menu item. Now we have to write a function to this filter. On each iteration on a menu item, this function checks two conditions: 1. Are we on the recipes menu item right now? 2. Is this post a recipe.

Our first task is simple: to know if we are on a certain menu item, we need to have its id. The id is very easy to indicate and be extracted from the menu items id: right click on the page to view the page source, or use Firebug to tell ‘recipes’ menu item’s id – that should be along the lines of: ‘menu-item-NN’, where NN is a number representing the actual id of this menu item. For this example let’s assume it is 42.

Our next task is a bit more complicated. We need to retrieve, not just the category id of our current post, but its root parent id, because the recipe root category may contain several sub-categories, and all should affect the ‘recipe’ menu item to get the current indication.

WordPress has a function that gets a category id and returns a string containing a breadcrumb trail of all its ancestors, all the way to its root category. The category names in this string are separated by ‘/’.

Next step is to add the extra code to handle our special current situation inside the function.php file. A reminder: this file should be located in your current them root directory. If it’s not there: simply create a file named functions.php and save it under your current theme root directory.

So first off – we write a function that retrieves the root category id from this string:

function get_root_category($category_id='') {
$ancestors = get_category_parents($category_id); //get the string containing the category ancestors
$split_arr = split("/", $ancestors); //break this string into an array
return get_cat_id($split_arr[0]); //pass the first value of this array (being the root category) to the function get_cat_id, that gets a category name, and returns its id.
}

Now we have tools to check for each page, if it is a recipe, and for each menu item being handled, if it is the ‘recipes’ menu item.

Next: we right the actual function, to be added as a filter to the menu construction:

function add_recipe_class( $classes = array(), $menu_item = false ) {
$category = get_the_category();
$category_id = $category[0] -> cat_ID;
$is_recipes = ($category_id != '' && 4 == get_root_category($category_id)); // our root recipes categories is 4. Replace 4 with your actual one
if ($is_recipes && ! in_array( 'current-menu-item', $classes ) && 42 == $menu_item->ID) { // recipes menu-item's id is 42. Replace 42 with your actual one
$classes[] = 'current-recipe'; // Off-course, the class name may be changed to anything more relevant to your case.
}
return $classes;
}

and now: adding the actual filter/ This too should be added to the function.php file:

add_filter( 'nav_menu_css_class', 'add_recipe_class', 10, 2 );

That’s it! Now, when you’re in a post belonging to the recipes root categories, you should see (viewing the page source, or using Firebug), that a new class was added to the recipes menu item: ‘current-recipe’. Now, only thing left is to apply a couple of style rules to it – and you’re good to go!

Code Dissection (or the Frog’s Revenge)

Here’s a piece of code that I have came across and pasting here in order to figure it out:

That’s right. This snippet is taken from the earlier discussed Lavalamp menu. But now we are going to dissect it.

So first step – the anonymous function that wraps the whole deal and gets an argument $. This is a general recommendation when designing a plugin – we pass the jQuery reference for $ as an argument of an anonymous function, to set up a closure and thus avoid collision with other scripts in the page, that may also use the $ sign.

Everything that we need for the plugin is inside this anonympus function.

Next, within this closure, we add a new function property to jquery’s fn object. This function’s name is the actual plugin’s name.

Most important to remember at this stage is that ‘this’ actually refer to the object we have just created – i/e/ the plugin itself, and not to the element it is applied on.

Next we deal with our constructor’s parameters: o. Basically o is an object that contains the properties speed, type of effect an a callback function. o is also extended by any argument passed through. If no argument is passed through – then o is extended by an empty object.

Next we iterate through all elements in the documents that are asigned by this onbjects – for example – all elements that has the class name ‘lavaLamp’, and for each we apply all the object’s properties and methods. We always define the properties first, separated by commas.

Graphic Issues on Oneiric – Recap

Last night, after a very hectic day, one notch before a new installation on a clean hard disc, I just realized that there’s one option I hadn’t try yet: KDE.

KDE was never my favorite, but logging in there after all I’ve been through, was really refreshing. Great colors, everything works, this is a nice sanctuary to stay in until the war’s over

But this morning, at booting the system, I didn’t even get to the login screen. The system halted at it’s last check before starting X and there it rested, or, as it is referred to in most Google results – ‘The system hangs at battery check’

As it turned out: Up until now – Ubuntu used the gdm display manager. As of now – it was changed to the new lightdm manager, which apparently is not quite baked yet. According to the major part of complaints all over the Internet – it mainly lacks support for Nvidia drivers, even the most recent. Ubuntu’s new window manager – Unity, is based on this display manager. It exists in two main versions: 3d (which comes as a default) and 2d (which is not installed by default but can be added). A fresh installation also makes it available to login on ‘gnome classic’ – compared to the new ‘gnome-3’ – (Not installed by default either, and can be added).

So seems my hardware (a reasonably new Nvidia GeForce 9600) is not supported by lightdm (and any window manager based on it, such as gnome-3 and Unity 2d or 3d), and as classic gnome is also set to work over lightdm – it would not work properly either.

This situation starts to look like a spaghetti dish, and it seems that nowhere I go – there’s a dead end. Trying to sort it out as much as I can, I realize I have now two missions: First – getting to a functional log-in screen. Having that achieved – logging in to a functional desktop – at the moment being only KDE.

So at the moment I’m on phase 1 – being hanged at ‘battery check ok’

  • I you run into any graphic related problem, better start with having both gdm and lightdm installed on your system.
    1. Log into a none-graphic terminal by hitting ctrl-alt-fN (when N is any number between 1-6) and logging in to a prompt line
    2. type
      sudo apt-get update

      (enter superuser password)
    3. Install gdm: At the prompt, type
      sudo apt-get install gdm
    4. Install lightdm: At the prompt type
      sudo apt-get install lightdm
    5. Install lightdm login part manager: At the prompt type
      sudo apt-get install lightdm-gtk-greeter
  • Selecting which display manager should be on is done by typing at the promtp:
    dpkg-configure gdm to set up gdm, or dpkg-configure lightdm At any rate you will get a menu where you can select the proper manager hitting the arrow-up or arrow-down keys. This is a matter of try and error. Try first loghtdm, and then reboot your systme hitting: sudo shutdown -r now At least one of them should work.
  • At boot – please take some time to wait – the ‘battery check screen’ may hang there for awhile. Give it a couple of minutes (time to grab a sandwich or a have a quick channel-zapping round on the tv), before you give up and start anew. At least one way or another should work for you.
  • Having achieved the login screen again – make sure you log in to kde – and you should be good to go.
  • Now all left is to sit and wait until all is quiet at the Gnome/Unity front, and all refuges may return home.

Html5 and the Modernizr

Modernizr is a little javascript api compatible with most modern libraries (jquery, mootools etc..), that allows you to already start using most of HTML5 tags and features, while taking care of all cross-browser compatibility issues for you! This is all over the internet, so there’s not much new I can add. However, here’s a speed guide to making a very basic cross-browser html5 page using Modernizr.

Continue reading

The Lava-Lamp Menu in WordPress

The other day one of my clients asked me to look at a very neat effect he saw somewhere. He insisting on having “the same” in his site. So I made a little research and came across this really neat gimic: the Lava Lamp Menu. The main idea is to have a neat transition that enhances the hover effect, making the active menu item transform to its new css with a very delicate and not-too-obtrusive sliding motion.

Continue reading