Download & Extend

Fatal error: Unsupported operand types in .../common.inc on line 1376

Project:Community Tags
Version:master
Component:Code
Category:support request
Priority:critical
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

Steps to reproduce:
. A Blog entry content type is published as user/1.
. Access to content nodes for Anonymous User is enabled.
. Log out is performed.
. Blog entry created in the first step is opened as anonymous user and Fatal error is displayed.
. Same error is produced when the node is opened as address node/xx or custom URL Path.

I'm not sure if there is a module that might have caused this error. I've checked everything and I think everything else are fine. Any action related to openning the content node as an Anonymous user produces the same error.

Need help on this problem.

Comments

#1

Original code is:
// Merge in defaults.
$options += array(
'fragment' => '',
'query' => '',
'absolute' => FALSE,
'alias' => FALSE,
'prefix' => ''
);

I changed this code to:
// Merge in defaults.
$options = array(
'fragment' => '',
'query' => '',
'absolute' => FALSE,
'alias' => FALSE,
'prefix' => ''
);

The second fragment fixed this problem but this might affect other functions in the future.

Is there another solution to this?

#2

Category:bug report» support request

See here http://drupal.org/node/362799

Please post back which module was causing the problem.

- Arie

#3

Status:active» postponed (maintainer needs more info)

#4

Project:Drupal core» Community Tags
Version:6.10» master
Component:node system» Code

Sorry for not posting the project. I have just traced the problem with #2 reply.

array (
'file' => 'D:\\srv\\site\\modules\\community_tags\\community_tags.pages.inc',
'line' => 44,
'function' => 'url',
'args' =>
array (
0 => 'user/login',
1 => 'destination=node%2F145',
),
)

#5

Same here... same trace results.

Upgrading to dev version fixed this issue for the one place I found the error.

#6

Status:postponed (maintainer needs more info)» needs review

Hi,

i fixed this issue for me with taking this code:
'#value' => ''. t('Login or register to tag items', array('@login' => url('user/login', $destination), '@register' => url('user/register', $destination))) .''
and changing it into:
'#value' => ''. t('Login or register to tag items', array('@login' => l('user/login', $destination), '@register' => l('user/register', $destination))) .''
in file: community_tags.pages.inc

According to: http://api.drupal.org/api/function/url
When creating links in modules, consider whether l() could be a better alternative than url().

Bye, Transmitter

#7

This solved the problem for me as well.

Thanks Transmitter!!!

#8

I ran into the exact same issue and the solution in comment #6 fixed the issue.

#9

+1 for #6, it solved this same issue :)

#10

yes - this seems to do the magic!

problem is, url() needs an array as second parameter - l() needs the destination.

seems to be mixed up!

attached the patch!

AttachmentSize
community_tags_url_l.patch 1.88 KB

#11

Can you please explain the problem and patch more. The way url() is being used is to generate a path for use as an argument in the t() function. I believe that using l() may have fixed the problem, but it is meant to create links, not generate urls. perhaps a better solution is to eliminate the use of the arguments all together and use l(t('Login'),'user/login')

#12

I think thats a better solution, then the one proposed in comment#6

'#value' => ''. t('Login or register to tag items', array('@login' => url('user/login', array('query' => $destination) ), '@register' => url('user/register', array('query' => $destination)))) .'',

it makes use of the url() function, but passes the query parameter in an array. in drupal5 the url() function worked like that, just in drupal6 it was changed to accept an array with options. that might be the reason why the bug was introduced. doing it this way, the user gets redirected to the specified destination, after logging in or registering.

#13

Status:needs review» fixed

After being unable to reproduce, I realized that this bug exists in 6.1 but has been fixed in the dev (to be just like valderama posted). Sounds like it is about time for a beta2.

#14

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nobody click here