Hi,
my watchdog log is cluttered with error messages like this:
call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'image_gallery_page' was given in /var/www/drupal/includes/menu.inc in line 348.
These errors are caused by accessing an image gallery as provided by image module; those vews-based gallery are not being displayd, instead I'm getting a blank screen (WSOD?). ./admin/reports/status indicates no problems, and update.php has neither pending updates nor errors.
With the help of one of the image.module maintainers (Joachim) I was able to exclude a malfunction inside image.module (cf. #571504: Galleries not working anymore); since the error points somehow to Drupal core's menu router, I hope this is the right place to post this issue.
What we tried was to put an print_r(debug_backtrace()); before line 348 (which is return call_user_func_array($router_item['page_callback'], $router_item['page_arguments']);) mentioned in the watchdog error message. That gave me a blank page with the following textual output:
Array ( [0] => Array ( [file] => /var/www/drupal/index.php [line] => 18 [function] => menu_execute_active_handler [args] => Array ( ) ) )
Next we tried to put an print_r($router_item); before line 348. That gave me the following output (again on a blank page):
Array ( [path] => image/tid/% [load_functions] => Array ( [2] => ) [to_arg_functions] => [access_callback] => user_access [access_arguments] => a:1:{i:0;s:14:"access content";} [page_callback] => image_gallery_page [page_arguments] => Array ( [0] => tid [1] => 1917 ) [fit] => 6 [number_parts] => 3 [tab_parent] => [tab_root] => image/tid/% [title] => Image galleries [title_callback] => t [title_arguments] => [type] => 4 [block_callback] => [description] => [position] => [weight] => 0 [file] => [href] => image/tid/1917 [options] => Array ( ) [access] => 1 [localized_options] => Array ( ) [map] => Array ( [0] => image [1] => tid [2] => 1917 ) )
/**
* Implementation of hook_menu().
*/
function image_gallery_menu() {
$items = array();
$items['image'] = array(
'title' => 'Image galleries',
'access arguments' => array('access content'),
'type' => MENU_SUGGESTED_ITEM,
'page callback' => 'image_gallery_page',
'file' => 'image_gallery.pages.inc', <------- this is the line your system seems to not be picking up!
);
Sorry, I can't provide steps to reproduce this error. However, I can reproduce it on my site, and of course I'm willing to help debugging this issue if someone provides instructions I can follow (but beware, I have no coding experience).
Thanks & greetings, -asb
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | edit_term-image_gallery-20090924-2.patch | 1.71 KB | dman |
| #3 | edit_term-image_gallery-20090924.patch | 1.29 KB | dman |
Comments
Comment #1
asb commentedmore meaningful issue title.
Comment #2
asb commentedAfter lots of enabling and disabling my contributed modules I was able to positively verify that the "Edit term" module in version 6.x-1.2 breaks image galleries provided by image.module. At least on my D6 site this can be reproduced with total certainty: Enabling "Edit term" switches image galleries off; disabling "Edit term" (re-) enables image galleries.
Since "Edit term" is such an incredibly usefull tool I'd love to see this fixed. At least if someone can reproduce this... ;)
Thanks & greetings, -asb
Comment #3
dman commentedOK, thanks for looking as far into it as you did. What you diagnosed here was indeed the trouble bubbling up, and it helped a lot.
So what's happened is that :
- in order to knit the 'edit gallery' link right into the middle of the 'view gallery' normal behaviour, a small amount of the 'view gallery' menu was replicated and tweaked within edit_term.
- (recently : September?) image_gallery.module was restructured to shift some of the functions out into different files. When that happens, hook_menu takes an extra bit of info about where that file is to load - required before it does its stuff.
- Edit term knew nothing of that change, and continued to have a menu invocation of a callback function that was no longer availabe because it wasn't being explicitly loaded.
Easy fix - yes, tell edit_term that when it is tweaking the gallery menu, also remember to include the new required file.
I think I've got that right now.
What I DON'T know is how this will effect backwards compatibility. I'm guessing it could be transparent, but may cause watchdog warnings if you use this updated edit_term with an older image_gallery.
FWIW, this fix [edit_term 2009/09/24] is against [image_gallery 2009/09/04 (HEAD/DRUPAL-6--x)]
Here's the patch. it could be an easy commit, but I need to retro-test it against earlier stable image_gallery releases.
Comment #4
dman commenteddammit, it's not backwards-compatible.
This fix breaks things for folk on image-6.x-1.0-beta1 or older.
Without it, it's broken for folk on image-6.x-1.0-beta2 and newer.
Fart. I've gotta do version detection?
Right, this patch works on the before and after versions of image_gallery - using version (capability) checking. Ugly, but safer.
Comment #5
aoturoa commentedSince image module is stable, could this module get an update regarding the fix for the image gallery please?
Comment #6
asb commentedYes, it'd be nice to get some decent support for image module. 49,538 sites are still using it (and are stuck with D6 as no upgrade path exists).
Thanks!