Crash when rendering url() (PHP 5.3 compatibility)

Could you at least provide what the error said? It'd be helpful to know why the current approach doesn't work.

Updating status

I got this error as well, but only after logging in from the /user page. I then found this page on drupal.org (http://drupal.org/node/362799) describing how to debug the issue and it pointed to the above line in flag. The output from the debug shows this:

array (
  'file' => '/Applications/MAMP/dev.moblin.org/sites/all/modules/flag/flag.module',
  'line' => 1092,
  'function' => 'url',
  'args' => 
  array (
    0 => NULL,
    1 => NULL,
  ),
)

Not sure if that helps?

I just had the same problem when playing with the Drupalcamp LA code and trying to log in as admin.

It was a fresh install of XAMPP 1.7.2a on the OSX.

Updated the code as per the description and all is good.

Thanks,
-- Jason

According to the data posted by mshaver in #3, the entire $link variable is NULL. This means that some module that whatever module is responsible for the flag type is not implementing a flag hook properly (probably hook_flag_link_types()), or it's possible that you were using a flag link type provided by some module, then that module was disabled.

So I'm still at a loss for how to fix this problem, since I don't think it's caused by Flag module alone, but likely caused by some other module extending Flag.

Perhaps this is a PHP 5.3 problem specifically? See #582388: Flag under PHP 5.3 gives WSoD, which I've marked as duplicate.

This fixed the error with php 5.3 for me.

Though I still get the following warning:
warning: Parameter 1 to flag_flag_link() expected to be a reference, value given in /Users/wedge/Sites/drupal/includes/module.inc on line 450.

I think there's something not quite right with the call to flag_flag_link(), which we haven't been able to nail down. Parameter 1 in that function should be a $flag object, but for some reason it's not. Really the first error (fixed by the patch) shouldn't be occurring either, but something calling the function incorrectly is triggering both errors. Do you have any additional flag_* modules enabled (flag_friend, flag_abuse, etc.)?

No other flag modules installed here.

@quicksketch i've updated http://drupal.org/node/582388#comment-2065546 maybe it helps.

@#7

I had this problem after dealing with my own unsupported operand types.

Removing the ampersand from the first argument eliminates the error. The flag link still seemed to work properly.
function flag_flag_link(&$flag, $action, $content_id)
function flag_flag_link($flag, $action, $content_id)

Worked for me with Drupal 6.14 on PHP 5.3, thanks Grayside! Hopefully everything else will continue working properly...

Update: I'm using the flag_note module and I also had to update the signature on hook_flag_link() within that module (ie. flag_note_flag_link)

Here's a stack trace on a site with

PHP Fatal error: Unsupported operand types in /includes/common.inc on line 1416
PHP Stack trace:
PHP 1. {main}() /index.php:0
PHP 2. menu_execute_active_handler() /index.php:18
PHP 3. call_user_func_array() /includes/menu.inc:348
PHP 4. node_page_view() /includes/menu.inc:0
PHP 5. node_show() /modules/node/node.module:1785
PHP 6. comment_render() /modules/node/node.module:1099
PHP 7. theme() /modules/comment/comment.module:1020
PHP 8. call_user_func_array() /includes/theme.inc:617
PHP 9. theme_comment_flat_expanded() /includes/theme.inc:0
PHP 10. module_invoke_all() /modules/comment/comment.module:1742
PHP 11. call_user_func_array() /includes/module.inc:471
PHP 12. flag_link() /includes/module.inc:0
PHP 13. flag_flag->theme() /sites/all/modules/flag/flag.module:168
PHP 14. theme() /sites/all/modules/flag/flag.inc:776
PHP 15. call_user_func_array() /includes/theme.inc:658
PHP 16. template_preprocess_flag() /includes/theme.inc:0
PHP 17. url() /sites/all/modules/flag/flag.module:1092

I patched this temporarily with this in common.inc

function url($path = NULL, $options = array()) {
   // Merge in defaults.
   $options_add = array(
        'fragment' => '',
        'query' => '',
        'absolute' => FALSE,
        'alias' => FALSE,
        'prefix' => '',
      );
   $options = array_merge(array($options), $options_add);

By way of cross reference Zen has a similar issue reported. #592726: When visiting some URL's: Fatal error: Unsupported operand types in /home/ps/prostaker/includes/common.inc on line 1542

When I look at $links as it's passed in (Passed in as $options) it looks like a valid array:

Array
(
    [href] => flag/flag/bookmarks/1234
    [query] => destination=node%2F1234&token=blahblahblah
)

Well as would be expected that causes problems. This however seems to keep flag happy and keep the rest of core happy:

$variables['link_href'] = check_url(url($link['href'], (array)$link));

subscribing

> I think there's something not quite right with the call to flag_flag_link(), which we haven't been able to nail down.

The reason this happens is that flag_flag_link expect a reference to $flag, but it is being called by call_user_func_array() (through module_invoke()). thus the value is sent as NULL to flag_flag_link, and the error only shows itself in the later call to url().

Since flag_flag_link() does not change the value of the flag, the fix in #11 works. Otherwise, the $flag object should be sent in an as a reference within an array, to keep it a reference.

I'm changing to RTBC, although formally there is no patch here, the fix is a single char change.

This is certainly an issue with Flag and PHP 5.3. I just moved a Drupal install from a server with PHP 5.2 to one with PHP 5.3 and this problem appeared.

Applied the fix in #11 to DRUPAL-6--1 and no longer get any errors. Tested quickly by flagging a node, then checking whether the flag was set using a view, everything appears to be working.

Attaching a patch.

I can confirm this bug and fix in #11.

I moved a drupal install like Liam above from a PHP 52 server to PHP 5.3 server.

Mine stated I had a problem with unsupported operands in common.inc. Traced problem down to flag and applied the fix in #11. Everything now works and flag works too.

Tagging

The php 5.3 "fix" will break this for php 4.x right?

So, if we are going to commit this then we should also add a php[] = 5.x to the info (or whatever it is) so it's clear what's going on.

The other option is to not use module_invoke. There are other places in core that need to pass references to hooks. I can't remember the syntax off the top of my head.

The flag_flag_link() function has no need at all to require that $flag be passed in by reference, so there's no harm in removing the ampersand. In fact it's already been removed from the 2.x version for some time. I've committed Liam McDermott's patch from #19 to the 1.x version and I'll make a 1.2 version to fix this and few other bugs shortly.