EDIT Nov 10: This has been solved by Letharion's suggestion to do a md5 file compare of my file with an original package file containing the function that was throwing the error.


I was referred here by https://www.drupal.org/node/2336585#comment-9311707

I've spent the better part of two days on this. I have searched and tried suggestions and so far no dice. Summarizing as much as possible:

Recently my WHM/cPanel auto-updated itself and locked us out of phpMyAdmin short of upgrading to MySQL 5.5 or higher -- when I tried accessing phpMyAdmin one day I was confronted with a red box with red text stating to upgrade. We've been ignoring it but two days ago we needed to get into our database so we had cPanel perform an unassisted upgrade to SQL 5.5.

Process went perfectly smooth and things seemed normal until we went to edit a node on our Drupal 6.33 and received a WSOD. Reloading a different page gets this error:

warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'node_page_edit' not found or invalid function name in /home/SITENAME/public_html/includes/menu.inc on line 350.

Line 350 of my unmodified menu.inc is within the function menu_execute_active_handler() as follows: 345 if ($router_item = menu_get_item($path)) { 346 if ($router_item['access']) { 347 if ($router_item['file']) { 348 require_once($router_item['file']); 349 } 350 return call_user_func_array($router_item['page_callback'], $router_item['page_arguments']); 351 } 352 else { 353 return MENU_ACCESS_DENIED; 354 } 355 } 356 return MENU_NOT_FOUND;

After pulling out some hair I discovered that during the SQL upgrade the server automagically updated it's PHP from our longstanding 5.2-branch to now 5.3.29. I have since learned that D6 does not 'officially' support PHP 5.3.

Looking up call-user-func-array(), indeed it has changed in PHP 5.3+

Can anyone shed some light on how to patch this for now? We are still using D6 because a few modules we need are not ready for D7 yet.

Thank you very much in advance, BigMike

-- Additional Info:

So far everything else including a good number of contrib modules are working as expected. The only error we have seen is call_user_func_array() expects parameter 1 to be a valid callback and only when trying to create (node_add) or edit (node_page_edit) nodes.

I did a dump on $router_item and call-user-func-array() is working for node_page_view, drupal_get_form, and statistics_node_tracker page_callback's but not working for node_page_edit or node_add.

Anything that uses drupal_get_form is fine, which so far I've tested creating and editing both blocks and taxonomy and both function as expected. So for kicks I intercepted 'node_page_edit' and changed it to 'drupal_get_form' and now my node edit pages load -- no longer white screen of death -- but have a ton of other errors and nothing useful is outputted to the screen.

We also get an error on our Clone page (Clone module v6.x-1.3),

warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'node_form' not found or invalid function name in /home/SITENAME/public_html/includes/form.inc on line 421.

which in form.inc is...

419 // If $callback was returned by a hook_forms() implementation, call it. 420 // Otherwise, call the function named after the form id. 421 $form = call_user_func_array(isset($callback) ? $callback : $form_id, $args);

Dumping $callback here and it's an ordinary string of value "node_form".

So I need to figure out how to manipulate call_user_func_array() for use under PHP 5.3.x. There are a few tips on the php.net site but so far I can't figure it out.

So far I've tried... return call_user_func_array($router_item['page_callback'], array(&$router_item['page_arguments'])); and return call_user_func_array(array($router_item['page_arguments'], $router_item['page_callback']), $router_item['page_arguments']);

...and I've tried adding ampersands and changing array orders... I'm really just spit balling as this is my first time ever working with call_user_func_array().

Any help is GREATLY appreciated! Our website is http://www.marlincrawler.com and most things are working as they should. Not being able to edit content isn't the end of the world as we can do that in the DB, but we need to be able to create content and not having this feature is a critical issue for us.

  • I'm with caleb below. Have you tried clearing the cache? Drupal 6 normally works just fine on 5.3.
    – Letharion
    Commented Nov 5, 2014 at 10:53
  • Letharion & calebtr, Sorry for not specifying but yes I've done that and found where people had to do it multiple times, all to no avail. I also truncated the cache tables manually in phpMyAdmin, restarted both httpd & mysql, still getting blank white pages when trying to edit or create nodes.
    – BigMike
    Commented Nov 5, 2014 at 15:18
  • Update: I also get WSOD while trying to delete a node at /node/%/edit/delete. I looked at the page_callback value and it is node_page_edit here as well.
    – BigMike
    Commented Nov 6, 2014 at 20:15
  • 1
    What's the md5 sum of your node.pages.inc file? Perhaps it's gotten corrupted somehow. I downloaded 6.33, and mine is "e77cc2e63d87afaa6b297a0549437590".
    – Letharion
    Commented Nov 7, 2014 at 8:17
  • 1
    HOLY CRAP IN A HAND BAG. Letharion. How in the world did you guess this... I did a md5 and it was different. Then I figured that's probably because I made some core edits back in the day... Then I used a text compare utility with the stock file and they had the same contents, just wasn't a binary match. Why this? So I copied over the stock file and WA-LA! I can edit and do everything else!! Checking some things now, brb...
    – BigMike
    Commented Nov 10, 2014 at 19:01

3 Answers 3


Letharion's suggestion above has solved my issue. For some reason the MD5 checksum of my d6_root/modules/node/node.pages.inc file changed during the cPanel auto-update of our PHP/SQL rendering 'node_page_edit' not found or as an invalid function name. Even despite a word-for-word text compare match of my unmodified node.pages.inc file with an original/stock Drupal 6.33 file, I was getting this WSOD. My node.pages.inc file was not a binary match of the stock D6 file, and directly after overwriting my unmodified node.pages.inc file with an original file from the D6 package, my website instantly began functioning normally.

To me it seems highly unlikely that this change occurred during the PHP & SQL upgrade. I wonder if rather the file had some issue with it before and perhaps the older version of PHP simply didn't mind it....?

So if anyone else out there has a particularly pesky white screen of death, in my example here, knowing which function was causing the issue and which file contains said function, perform a MD5 file match and see if for any reason your file differs from the original Drupal install file.

Many thanks to Ashish Bairagi, calebtr, and Letharion for their help is getting this resolved.


First of all I would like to mention that the error you are referring is indeed just a warning which does not cause WSOD. So you need to dig out what exactly the fetal error there which is causing WSOD.

To do this you need to change level of error reporting in you settings.php file. Add this code :

ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
//Note:  Do not include the opening and closing PHP tags when you copy this code

then you would be able to see exact error, if you are able to solve that then the issue might get resolved or you can simply post that here as well so any one of us can help you.

more details here: https://www.drupal.org/node/1056468

  • Could the WSOD still be caused by the warning, because the failure to call the function just means Drupal doesn't know how to proceed and you end up with no output?
    – Letharion
    Commented Nov 5, 2014 at 10:54
  • Warning appear only when drupal can go ahead after notifying the user that there may be some unusual output but not a blocker. If you go through reference link you get more clarification. Commented Nov 5, 2014 at 11:02
  • Ashish, thank you very much for the help. I added this code and am now receiving the following: .... Notice: unserialize() [function.unserialize]: Error at offset 465 of 466 bytes in /home/SITE/public_html/includes/bootstrap.inc on line 566 .... Notice: unserialize() [function.unserialize]: Error at offset 605 of 606 bytes in /home/SITE/public_html/includes/bootstrap.inc on line 566 .... and .... Notice: unserialize() [function.unserialize]: Error at offset 611 of 612 bytes in /home/SITE/public_html/includes/bootstrap.inc on line 566
    – BigMike
    Commented Nov 5, 2014 at 15:18
  • Line 566 of my bootstrap.ini is in the function variable_init() and is as follows .... $variables[$variable->name] = unserialize($variable->value);
    – BigMike
    Commented Nov 5, 2014 at 15:20
  • This is the only new error and I checked my /usr/local/apache/logs/error_log and it's being reported there as well but without any other errors. One thing to note however is that this error is seemingly occurring to all my site visitors. Ever time I tail the log file I get the error being generated from different referrers (random visitors on our site at the moment), yet, however, they are not getting WSOD. Browsing site works fine, just can't create or edit nodes.
    – BigMike
    Commented Nov 5, 2014 at 15:22

I don't have enough reputation to comment. I don't see you saying anywhere that you've tried this, but here it is:

Clear all of your caches.

(at admin/settings/performance)

call_user_func_array() is working fine, but it can't find the function 'node_page_edit', so it PHP is complaining.

But of course you have a function called node_page_edit, it is part of the node module in Drupal core, and there is no way you can disable that module. So something is wrong with the way Drupal is loading modules and most of the time clearing caches helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.