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.

After a little sniffing around, it looked like a no brainer: add a couple of Javascript calls to your page, make some touch-ups to your css, give the right class to the right menu element (read more about that here), and you’re good to go. A while later it just occurred to me that there might already be a designated WordPress plugin based on that script. I went ahead and looked it up – indeed there is a lavalamp plugin for WordPress. Only problem: at the time of writing this article, it is not compatible with WordPress current version – at the moment 3.2.5. As announced on the plugin’s page on WordPress – it was not tested on 3.2.5. Having tested it – indeed it doesn’t work.

So at this moment – a little research under the hood is required.

The plugin folder’s most important files are the plugin main file (lavalamp.php) and the script files under the js library. The js folder contains these files:

  • intface4.js (Probably related to backword compatibility)
  • intface4.pack.js (minified version)
  • jquery.easing.1.3.js (also in the original lavalamp package)
  • jquery.easing.1.3.pack.js
  • jquery.lavalamp.js (also in the original lavalamp package)
  • jquery.lavalamp.min.js (minified version) (also in the original lavalamp package)
  • jquery.lavalamp.pack.js (minified version)
  • my-menu.js (supposed to contain the menu activation on page load)

On the plugin’s settings in the admin area, there is a toggle option – whether or not to rely on WordPress’ core files as dependencies. This option is reflected in the actual code inside the lavalamp.php file with the boolean $useinternals. When true (rely on WordPress dependencies) – a couple of scripts should load. When false, the call is for a couple of others. Always preferring to rely on WordPress’ core scripts (at the moment = jquery 1.6), I set this option on the admin area. However – loading the page in this state – the lavalamp designated scripts are not loaded at all.

Here’s a code snippet taken from the makeLavalampScripts($useinternals) function:
if($useinternals == 1)
wp_enqueue_script('easing', WP_PLUGIN_URL . '/lavalamp-menu/js/jquery.easing.1.3.pack.js', array('jquery', 'interface'));
wp_enqueue_script('lavalamp', WP_PLUGIN_URL . '/lavalamp-menu/js/jquery.lavalamp.pack.js', array('jquery', 'interface', 'easing'));
wp_enqueue_script('mymenu', WP_PLUGIN_URL . '/lavalamp-menu/js/my-menu.js', array('jquery', 'interface', 'easing', 'lavalamp'));...

As already discussed here, the wp_enqueue_script function actually loads the requested scripts to the page, based on their dependencies. In this case the first file in the queue is expected to be a file labeled ‘interface’, but no such file is to be found, and therefore none of the scripts on this queue is actually loaded. This should have probably pointed to a file identical to the inface4.js file in the plugins’ folder, that in former WordPress versions was maybe registered as part of core scripts, but I am only guessing here. Anyway, here’s the fix:
if($useinternals == 1) {
wp_register_script('easing', WP_PLUGIN_URL . '/lavalamp-menu/js/jquery.easing.1.3.pack.js', false, '1.3');
wp_enqueue_script('lavalamp', WP_PLUGIN_URL . '/lavalamp-menu/js/jquery.lavalamp.pack.js', array('easing'));

Looking again at the page source code reveals that all scripts are registered in place now.

Our next step is to activate the menu at page loading. If I get it right, this code should be located inside the my-menu.js file. I tried to figure it out, but frankly, didn’t quite get it. Only thing I know – for some reason, it didn’t do the job. So instead of wasting time on reverse-engineering (which is NOT a good practice, and I wouldn’t recommend it normally), I decided to replace the whole lot of code written there with the full-proof snippet of code from the original Lavalamp guide page:
jQuery(document).ready(function() {
fx: "backout",
speed: 700,
click: function(event, menuItem) {
return true;

Here we have the three call to the object with 3 arguments: an effect, transition speed and a callback function that we leave at the moment as just “return true.”

There. It works.

Some precisions for dessert:

  1. Note that the actual Lavalamp plugin code is not overriden. Before touching it, I have created a new plugin folder, named it lavalamp-menu-i, and made all the necessary changes there.
  2. Notice that inside the jquery code, the pointer ‘$’ is replaced with its alias ‘jQuery’ to avoid conflicts, should this page also call scripts related to different API’s, such as mootools or scriptaculous, that use the same notation.
  3. Pay attention that the reference from the script to the menu class or id (jQuery(‘.lavaLamp’)) should match the actual menu class in the HTML, and, off-course, don’t forget – case matters!
  4. The menu should be of one line only. I suspect that given too many items that force the menu to break into two lines – weird things might happen to the lava lamp…
  5. The menu (UL) should have a fixed width set in the CSS
  6. The menu current item class name under WordPress is either “current_page_item” or “current-menu-item”. Sometimes it may be be named differently, depending on many factors. We should hope that no matter what, at least it should always contain the word ‘current’ in it. So we are better off changing the assignment of the var curr from
    curr = jQuery("li.current", this)[0]
    curr = curr = $("[class*=current]", this)[0] || $($li[0]).addClass("current-menu-item")[0];

Hi there, after a long search i finally found a somewhat article on a WP enabled LavaLamp script / plugin.

I was wondering if, how, and when it is possible to implement this into a working WP site?

This Lava issue had gotten me boiling since I cant seem to get it to work. Any help and pointers much appreciated, please mail me at the given mail address if you know a way out.


Hi Rams, I really hope to find time really soon to upload this fix to the Lavalamp plugin to WordPress repository. Untill then – you can download the original plugin from the repository and make the changes I mentioned here, in order for it to work. Good luck!

Hi Chris, sorry it took me so long to reply – I need to find time to refine the modification to this plugin and upload it to WordPress, once it’s done, I will update this post with a link to the actual code.