Call to undefined function - vocabindex module

You may report bugs for any version. I'll look into it ASAP.

Last time I saw this issue was with a similar module, the way I solved it was to wrap this around the function call:

if (function_exists('drupal_get_path'))
{

//body of code of the function were failure was occurring goes here ....

}

Try this out.

I think the best way to solve this issue is to check out why drupal_get_path() is getting called and why it doesn't exist yet in that phase of execution. Wrapping it in an if(function_exists()) may cause another piece of code to break, because the if's body isn't being executed.

I am not saying you should blindly apply it, but thats a way to fix it...

In any case, I got the same error:
Fatal error: Call to undefined function drupal_get_path() in ......vocabindex\vocabindex.module on line 13

It tends to happen when logging out of drupal, so it looks like function not set for anonymous users or something. But in my case, access rights do exist for anonymous user.

Drupal_get_path() is located in common.inc, which should have been included before vocabindex.module. If you are experiencing this problem again, please provide a step-by-step list of instructions on how to reproduce the problem.

Line 13 is the first line of the following code, located directly at the beginning of the file, not containing within any other code:

$path = drupal_get_path('module', 'vocabindex');
require_once($path . '/vocabindex.admin.inc');
require_once($path . '/vocabindex.view.inc');
require_once($path . '/vocabindex.theme.inc');

This should work at all times, unless something really went wrong. Unfortunately I have no multisite setup available anytime soon, so I cannot reproduce the problem using those instructions. Since I cannot analyse the problem if I can't reproduce it I have to ask you to come up with a different approach to reproduce the error.

Nothing obvious.

Project module does this drupal_get_path() trick too, and runs fine on d.o.

Could also be a Panels issue.

Then I suspect Panels may be trying to load the module out of sequence.

As long as modules are being loaded normally all core's include files should have been loaded already. Since Vocabulary Index doesn't load anything outside its own 'scope' I believe a won't fix is appropriate.

It seems strange that if Panels loads an index page into a panel it loads the module out of sequence, but perhaps agentrickard is right and Panels _is_ doing something wrong. Perhaps you could create an issue there.

Hmm, this is getting tricky. Could you test again using a fresh multisite setup without using other contrib modules than Vocabulary Index? Just to be sure no other modules aren't involved.

@xano

Note that Domain Access (which skizzo is using) is not a normal Drupal multisite. I may have to install VocabIndex and see what is going on.

Ah, darn. Somehow I missed that bit. It would be great if you could test for this bug as well!

I cannot replicate the error. But if I set the View Type to 'Browsable' I get the following:

[04-Nov-2008 15:57:09] PHP Fatal error:  Cannot access empty property in /Applications/MAMP/htdocs/drupal-5.11/sites/all/modules/vocabindex/vocabindex.theme.inc on line 67

The other two types seem to work fine. Domain Access seems to have no effect.

I created a new issue for that bug.

The error you get after applying that workaround is a logical result of requiring a file from the wrong location, since the file's directory isn't available anymore.

Confirmed. It is a problem with caching, and Project would have the same issue.

[05-Nov-2008 09:22:43] PHP Fatal error:  Call to undefined function drupal_get_path() in /Applications/MAMP/htdocs/drupal-5.11/sites/all/modules/vocabindex/vocabindex.module on line 13

What happens (and why it seems unpredictable) is that the first time a page is requested by an anon user, the entire code generates the cached page. On subsequent views, the page is pulled from cache and drupal_get_path is not loaded.

The proper D5 code, I believe is to move the load statement into hook_menu() !$may_cache.

function vocabindex_menu($may_cache) {
  // existing code (ends on line 175)
  }
  else {
    $path = drupal_get_path('module', 'vocabindex');
    require_once($path . '/vocabindex.admin.inc');
    require_once($path . '/vocabindex.view.inc');
    require_once($path . '/vocabindex.theme.inc');
  }
}

See http://api.drupal.org/api/function/hook_init/5, which describes this issue.

A better fix would be to load those files only on paths where they are needed, if possible.

Since the Drupal 5 menu system does not allow include files for menu callbacks I decided to require all files at the beginning of vocabindex.module. I could have chosen to require them only where necessary, but I didn't for the simple reason that it would make the code more complicated, especially because I am maintaining three branches at the same time.

Skizzo, agentrickard: Thanks a lot! It seems like you have found the problem and a possible solution. I'll try this fix in a couple of minutes.

Xano-

I've done that trick before by routing all my D5 menu items through a handler function, which takes an argument that indicates the function to load, then loads the includes in the handler function, but that is probably more effort than its worth.

@Skizzo: The new RC releases are from yesterday morning, when agentrickard hadn't suggested a fix yet. I was busy with updating some strings and the Dutch translation, which took more time than expected. That's why the fix still hasn't been committed.

@Agentrickard: It's probably not worth it, but I'd still like to see your solution; it sounds very interesting.

I found an example in the D5 version of Domain Access.

See:

http://therickards.com/api/function/domain_menu/Domain
http://therickards.com/api/function/domain_admin/Domain

In general, menu calls to the domain_admin function include a callback argument that indicates which function to fire. The conditional file loading happens inside domain_admin.

I like it :) It might be worth implementing this after all to reduce the amount of parsed code.

It is basically a straight port of the D6 menu file include system, using D5 APIs.

I have been able to reproduce and fix the problem. The code to load the include files has been moved to hook_menu().

Thanks, skizzo and agentrickard!

Fixed and committed to 5.x-2.x-dev.