Call to undefined function field_info_fields() in admin_menu.map.inc on line 111

I have gotten the same problem, At the moment I've uninstalled js module and delete js.php from the root directory and now the error has disappeared

It definitely seems to be the js module that isn't working well with Admin Menu.

Edit: posted issue to js module #2071163: field_info_fields not defined when using js and admin menu

It's the other way around. Admin Menu has built-in support for project/js callbacks which is obviously broken. And there's no way to switch Admin Menu back to normal callbacks when js is enabled.

@Administration menu maintainers: Please add the field module in the dependencies to fix this bug. While you're at it, please remove the devel module from the dependencies as it won't always be available with everybody. I attached a patch to make the required changes.

That patch didn't work for me, it ran into more problems with

Call to undefined function menu_tree_all_data()

So I added the menu include, but still ran into more errors. e.g.

Trying to get property of non-object in admin_menu_output() (line 463

Is js module integration really needed for admin menu? How about just removing it? At least then it doesn't interfere for those of us who want to integrate js with other modules.

The attached patch simply removes the admin_menu_js function.

I'll second that. It seems that admin_menu no longer works with the js module and this error could greatly dissuade developers from pursuing development with the js module. Until someone can whip up a working patch, I'd vote for leaving out js module support.

I take that back. Simply removing hook_js in admin_menu still causes the issue with admin_menu because it tries to request js/admin_menu/cache anyway. In order for admin_menu to work with js on, hook_js has to be implemented...

I think I solved the issue. It appears that admin_menu_js_cache was returning the whole admin menu. Under normal circumstances that is fine, but the js module is expecting the callback function to either exit or return an integer representing the status, otherwise it outputs the return as json. So our admin_menu was getting json_encoded and thus wasn't rendering properly...

Added a few extra includes and dependencies to prevent function not found errors and moved the bootstrap level up so the user session was available to check against. Seems to have done the job, at least for us.

Some more testing of this and digging into the code a bit more, it appears that the js module will set the bootstrap to _SESSION if a valid access argument is included, so manually setting the bootstrap is not needed, and adding the access argument has the added benefit of consistency with permissions. Incidentally, once we're at that bootstrap level, it appears that the field_info_fields error and other dependency/include errors are resolved automatically. The only explicit dependency left is the path include.

Patch #9 does not solve the problem for me, there are also other related crashes like: Fatal error: Call to undefined function field_info_instances() in admin_menu.map.inc on line 88.

For the time being, Administration menu clashes with the High-performance JavaScript callback handler module. There is a workaround: disable Cache menu in client-side browser option inside Admin menu configuration, Performance section avoids the problem.

For testing and workaround purposes, it would be nice if the JS callback support would be an option in the Performance section.

@interdruper -- what version of admin_menu and js module are you using? Also, be sure to clear your caches after applying the patch in #9. I can reproduce the issue you're having, but after applying patch #9, everything works as expected and the problem seems to be resolved.

I am afraid that something more is happening. Yep, problems remains after clearing caches. New errors also appear when I edit any content type Manage Fields screen, related with field functions. If Cache menu in client-side browser option is disabled, problems go away, with or without patch #9.

Versions used:

• admin_menu: 7.x-3.0-rc4
• js: 7.x-1.0+1-dev

I am using js module because I am testing the last dev version of ip_geoloc module.

I'm not sure where to go from here. I have done the following testing:

* Downloaded and installed a clean Drupal 7.24 standard profile.
* Added admin_menu 7.x-3.0-rc4 and js 7.x-1.0+1-dev as the only two contrib modules.
* Disabled core Toolbar module.
* Applied the htaccess rules for the js module.
* No patches applied.
* Confirmed the error:

Exception: The dependency <em class="placeholder">devel</em> for the callback <em class="placeholder">cache</em> in <em class="placeholder">admin_menu</em> is not installed. in js_execute_callback() (line 206 of /var/www/drupal-7.24/js.php).

Then:
* Downloaded and enabled devel 7.x-1.3.
* Still no patches applied.
* Confirmed the error:

Fatal error: Call to undefined function field_info_instances() in /var/www/drupal-7.24/sites/all/modules/admin_menu/admin_menu.map.inc on line 71

Then:
* Applied the patch from #9.
* Confirmed no errors and admin menu works as expected in Chrome 31.
* Confirmed the same in Firefox 26 and IE9 (I don't have 10 or 11 on this machine).

And as one final sanity check:
* Disabled devel module.
* Confirmed no errors in any browsers as before.

I have not altered any settings in admin_menu, so the default 'cache menu in client-side browser' is enabled.

@interdruper - as far as I can tell, the errors you're getting involve something else going on, although what it might be, I'm not sure. A few things to check:
* Make sure that the patch is applying properly.
* Disable all other modules that use hook_js() for testing.
* If you've updated the js module recently, I'm not sure if it will automatically update the js.php in your Drupal root or not; it might be worth copying it over manually as a sanity check.
* Clear your cache and cookies completely after applying the patch (or use Chrome's incognito mode).

@all - If anyone else can reproduce the fatal error issue that @interdruper is experiencing and is able to shed some additional insight to the situation, it would be much appreciated.

You can disable the admin_menu js implementation by using code like this in your custom module:

/**
 * Implements hook_module_implements_alter().
 */
function mycustommodule_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'js') {
    // Disable js implementation for admin_menu as long as issue is not fixed.
    // @see https://drupal.org/node/1981308
    unset($implementations['admin_menu']);
  }
}

EDIT: that approach did not really work (as js does not use module_invoke). The problem was only solved temporarilly and occured again later.

I can verify that the patch in #9 works. This was quite an annoying bug.

kindly fix thid problem asap please .

please find attached file for issue.

Same here, applying patch in #9 did not fix the problem, I also get the Call to undefined function field_info_instances() error. If I go in the .module file and remove the function call as a test, it just complains about another function it cannot find. This is probably stating the obvious, but it seems to me that generating the cache relies on functions/modules that the JS module bypasses.

Does not sound like we have consensus on #9.

Actually now that I think about it we should just close this issue as "won't fix". The JS module has undergone a refactor because of security issues.

The patch in #9 does work with the latest dev branches of both admin_menu-7.x-3.x and js-7.x-1.x. I have already opened a separate issue that will tackle changing the API implementation in admin_menu. We should focus our future efforts there instead.

If the patch in #9 fixes the bug for the current versions of admin menu & js, shouldn't we commit it?

Then when js 2.x is out we can commit that other patch?

Seems odd to leave it broken like this.

Given that this is strictly for JS module support and that we're going in an entirely different direction in that module, it is really just a mute point to commit this particular fix for something that will change here shortly down the road anyway.

We're not "leaving it broken", it's just going to be handled in an entirely different way in 7.x-2.x (ie: won't fix, not works as designed). The related issue, which will inherently fix this one, essentially allows the admin_menu module to implement what is actually more of a stable API via the new changes in the JS module.

The patch in #9 will always exist on d.o. It can be manually applied if needed, but this isn't the issue that really needs focus.

A bit frustrating seeing this as won't fix - after about a half a year down the road without visible progress on either side of admin menu or js module :|
In my opinion a working patch shouldn't be postponed / held back because there will be a completely other fix sometime in the future.

Is there any disadvantage if we just merge #9 temporarily in dev version rather than leaving it broken? I agree that marking it won't fix is very frustrating.

I ran into Call to undefined function field_info_instances() again.
The updated patch contains a generic dependency detection for the JS callback. Not very pretty but it seems to solve the issue.
Flushing caches will make this work. Every cache flush rebuilds the dependency cache - we might want to do this in another hook.

Added more includes. And an include for admin_menu.map.inc to ensure the "on behalf of" hooks are available if we call module_implements().

I think there was confusion about "won't fix", so marking as a dup instead. It isn't that we said we weren't going to fix it, but rather that it's already been fixed in the refactor of the JS module and now Admin menu just needs to adjust it's API integration: #2219467: Fix client side caching, as stated in #20:

We should focus our future efforts there instead.

Please work towards the larger solution and jump on the right bandwagon rather than trying to "fix" something that has already been fixed. That's what these issues with artifact patches are generally for: you can still apply them to stable code if needed, as stated in #22:

The patch in #9 will always exist on d.o. It can be manually applied if needed, but this isn't the issue that really needs focus.

So please.... stop barking up the wrong tree here. Instead, I would be more than happy to release a stable 7.x-2.0 version of the JS module once someone other than myself has tested/used it. This would then force admin_menu to address #2219467: Fix client side caching.

Thanks a lot das-peter. Confirming patch #27 works whereas #9 was broken for me.

I had this problem on the client's server, but couldn't reproduce it locally, using the same code base and database.

I finally found interdrupers comment #10 and this solved it for me as well: "For the time being, Administration menu clashes with the High-performance JavaScript callback handler module. There is a workaround: disable Cache menu in client-side browser option inside Admin menu configuration, Performance section avoids the problem."

Thank you!