Fatal error: Call to undefined function genesis_menu_item_link()

I don't think that's my fault. Your theme is somehow sneaking a function into the theme registry that it then fails to implement. Try rebuilding your theme registry or changing your theme.

From the 3.3 release notes:

Bug #331352: Themeable menu functions can now be overridden by themes (DHTML Menu used to completely block that)

Before 3.3, DHTML Menu simply stopped themes from implementing the theme_menu_item(_link) functions. If a theme implemented these, they were never called as DHTML Menu replaced them with its own functions.

Now, DHTML Menu remembers the functions it replaces, and makes sure to call them once it's done with its own stuff.

For some reason, your theme registry contains a function named genesis_menu_item_link even though this function does not actually exist. I'll check how the theme registry is built to find out why this is happening. It might still be a bug in DHTML Menu...

Please check your modified version of the genesis template.php file for the function "genesis_theme".

In this function, you return an array that probably contains an element with the key "menu_item_link". Please remove or comment out this element, rebuild your database caches, and see if you still get this error.

I have 'Garland' as my admin theme and these errors happened only when I go from the Genesis theme to the Garland theme

That changes everything. It's my fault after all. ;)

DHTML Menu uses a single variable to store the function it "overrides" - but logically, this does not work when multiple themes are used on the same site. I expect that the same bug will be experienced on sites where the user can pick their own theme.

I'll have a patch ready in a bit.

The underlying problem goes deeper than this. theme_registry_alter is not made aware of which theme is being processed, which is imho an annoying failing of the theme API. It makes it impossible to do this perfectly.

Instead, the stop-gap measure is to make only one attempt to find the overriding theme function, and revert to the base theme function if it is not found. This will stop the fatal error, but could cause unpredictable behavior when multiple themes are used on a site and more than one of them implements menu_item or menu_item_link.

There is only one part of my code that calls menu_tree_output... assuming that the error is the only problem, it should be sufficient to make sure that the argument is always an array.

I wouldn't commit on a single review normally, but I know what the change does and don't expect any regressions. At most, some remaining weirdness in the above-mentioned special cases, but nothing worse than the fatal errors it fixes. So, committed to DRUPAL-6--3.

I'll have a release out soon, once I fix the other few bugs in the queue.

I have successfully applied this patch, and it got rid of the error.
Thanks!

sorry... we replied at the same time it seems :X

Had the same problem with zen theme ("Call to undefined function zen_menu_item_link()") and Garland as admin theme.
The patch solved the problem.

Thanks.

Heh... normally I have to wait weeks before my patch gets reviewed, and now I get two reviews the moment I commit the patch. :)

It seems there's still a problem with this, let me explain:

I've tested a bit, if we switch theme (we're using garland for admin pages, which doesn't have a custom function), and then switch to the theme that has the custom function, it doesn't get picked up, and the menu is rendered again by default. If you then empty the cache, the theme function gets picked up and is displayed accordingly. Looks like there's a problem with the way that dhtml_menu updates what function to use, though not being a developer it totally eludes me.

Let me know if you need more information or further testing, this is a critical issue for our site :)

Information that might help out narrow down the issue:
This runing the 6.x-3.3 version with the patch dhtml_menu-theme_function_exists-355521-9.patch applied.

Below the functions we're using the functions: abacus_menu_item_link() and abacus_menu_item():

function abacus_menu_item_link($link) {
  if (empty($link['localized_options'])) {
    $link['localized_options'] = array();
  }
  if ($link['href'] == "no_link")
  {
      $link['dhtml_disabled'] = TRUE;
    return "<span class='nolink'>".$link['title']."</span>";
  }
  return l($link['title'], $link['href'], $link['localized_options']);
}

function abacus_menu_item($link, $has_children, $menu = '', $in_active_trail = FALSE, $extra_class = NULL) {
  $class = ($menu ? 'expanded' : ($has_children ? 'collapsed' : 'leaf'));
  if (!empty($extra_class)) {
    $class .= ' '. $extra_class;
  }
  if ($in_active_trail) {
    $class .= ' active-trail';
  }
  if (strpos($link,"nolink"))
  {
    $class = str_replace("collapsed start-collapsed","",$class);
    return '<li class="'. $class .' no-dhtml">'. $link . $menu ."</li>\n";
  }
  return '<li class="'. $class .'">'. $link . $menu ."</li>\n";
}

Oh. Right. :(

I knew there was a flaw, but I thought the conditions were rarer.

I need to go back to the drawing board and the theme API. Surely there must be some way I can tell in the alter hook which theme is being altered...

That was surprisingly simple, which makes my earlier flawed solution all the sillier. ;)

I completely forgot that the name of the active theme is in the global namespace. "global $theme", and suddenly I know exactly which theme function to call.

Here is the patch. It requires the theme registry to be rebuilt, of course - before the version is released as stable, I will create an update function that does this and removes the old system variables.

Edit: Note that this version applies to what is in CVS, so it rolls back the committed patch.

Stupid typos. >_<

OK, so applied the second patch to the already patched version, here is what it spitted out:

/var/www/drupal/sites/all/modules/dhtml_menu# patch < dhtml_menu-theme_function_exists-355521-19.patch 
patching file dhtml_menu.module
Hunk #1 succeeded at 27 with fuzz 1.
Hunk #2 FAILED at 51.
Hunk #3 succeeded at 73 (offset -3 lines).
Hunk #4 FAILED at 82.
Hunk #5 succeeded at 106 with fuzz 2 (offset -4 lines).
Hunk #6 succeeded at 124 (offset -6 lines).
2 out of 6 hunks FAILED -- saving rejects to file dhtml_menu.module.rej

Looks like it didn't apply properly... any chance we can get a patch for the current version? Or did i do something wrong here?

Nevermind!!

Seems like one of our developers had previously touched the module :S I've re-done the whole process, and it seems like the bug is now gone. Please people confirm :)

That's great. Thanks for testing this! :)

Here comes the update path (which is really just housekeeping). I'll give this a last minute testing and see if it works.

Er... yes.

Committed, tagged, released!

Awesome, thanks a lot Arancaytar... I'll update the module today :)

Still needs to be fixed in 7.x-1.x-dev.

I've ported the patch from #23 so that it applies to my version of HEAD. Here we go.

I removed the hook_theme implementation pre-commit. This is part of a pending dhtml_menu change that allows custom labels on items, and it shouldn't be in CVS until that change actually happens.

It already worked in the stable version, so I've committed the change to the unstable 7.x-1.x-dev branch without a second review.