After updating from RC-3 to 6.0, I recieve the following error from my admin/build/menu page:

"Fatal error: Unsupported operand types in ../public_html/includes/common.inc on line 1435"

I have now updated to 6.1 and I still get the same error. Not sure what could have caused it. everything else seems to be working fine. Has anyone else come across this?

CommentFileSizeAuthor
#17 common-404-path-error.patch441 bytesayalon
#4 common-228435-4.patch469 byteshitka
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wildtang3nt’s picture

I have the same error with profile pages... again, no clue how it happened and upgrading to 6.1 from 6.0 didn't fix it.

wildtang3nt’s picture

I rolled back to my old database and the error went away until I logged out and logged back in. Suddenly profiles can no longer be viewed. I rolled back again, no problems... login however and it's suddenly broken again. I'm at a total loss to explain this. I need help, I can't have a site that doesn't allow any /user/* pages to be viewed.

wildtang3nt’s picture

It would be nice if someone would look into this, I think this is a pretty serious problem (not to mention my client is getting very impatient).

hitka’s picture

Component: menu system » base system
Status: Active » Needs review
FileSize
469 bytes

I got the same error in the menu administration page when I wanted to edit my primary links. This happened to me after importing dumped db data and it did not appear on original drupal installation.

It seems to me that the problem occurs when the parameter $options for the function l() is not an array (e.g. when it is null). I think that l() should be at least able to accept null options without failing with fatal error. I attach a simple patch that checks if options parameter is an array and sets it to an empty array if not. I am not sure if this is the right approach, anyway it does not do any harm IMHO and solved my problem, so I hope it helps.

chingsha’s picture

I've run into the same problem, and your advise did work!! Thx!

Dave Reid’s picture

Status: Needs review » Fixed

This is a contrib module problem by not correctly implementing l(), which changed from D5 to D6 to accept only an array of parameters instead of a list of parameters. You'll need to disable groups of modules at a time to narrow down the problematic module, then file an issue with the respective contrib module.

Status: Fixed » Closed (fixed)

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

RedTop’s picture

@David, this is not related to contrib. I disabled all contrib modules by renaming their folders and the error persisted.

I can confirm that the error still shows up after upgrading to Drupal 6.17. Patch fortunately still works as well though. :)

atzanov’s picture

I can confirm that this problem still exists in 6.17. I run Drupal 6.17 on Apache 2 and PHP 5.2.11. I posted about this here http://drupal.org/node/828738

Also, the patch still works. Thank you Hitka.

Fogg’s picture

Status: Closed (fixed) » Reviewed & tested by the community

Patch works like charm in drupal-6.17 for me!
Thanks!!

As this patch seems not to be commited yet I set the status back to reviewed and tested (quite a view testers confirm it works).

Status: Reviewed & tested by the community » Needs work

The last submitted patch, common-228435-4.patch, failed testing.

cybernomad’s picture

This patch worked for me too, Drupal 6.16

wxman’s picture

I just had the same problem, and I'm using Pressflow 6.17. The patch worked there too.

Coupon Code Swap’s picture

Patch still works with Drupal 6.19.

angusi’s picture

Status: Needs work » Needs review

#4: common-228435-4.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, common-228435-4.patch, failed testing.

ayalon’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
441 bytes

I had the same problem an recreated a new better formatted patch.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, common-404-path-error.patch, failed testing.

adbn’s picture

Status: Needs work » Needs review

#4: common-228435-4.patch queued for re-testing.

jibize’s picture

Patch worked for me on Drupal 6.19.

Danny_Joris’s picture

Patch worked for me too in Drupal 6.19. Thank you!

I don't know where the issue came from, but it looks fixed now.

San_ANDREYEV’s picture

Works for me too, D 6.19.

I came from here - http://drupal.org/node/739158

christopherareed’s picture

The last patch works, and I can pin point specifically how it was encountered. A friend was transferring a site to an updated version of another site and didn't want to set everything up again so...

Scenario that caused it:
Friend creates a copy of website on a sub-domain which was in Drupal 6.19, uses node-export/import via the copy paste text area, while the site he exported from was in Drupal 6.15 and he went to edit the Secondary-links menu which is where the 'create-content' links were located and got the error described here with line 1592 in common.inc.

Recreating the above scenario I said to update all his modules and core, export node via views bulk operation this time and upload that text file to the new install, and there was no longer an error. 'We' tested the patch before recreating the error and like I said also worked. Just thought this may be useful to some (who like to take to many shortcuts, jk).

dddave’s picture

Version: 6.1 » 6.19
Status: Needs review » Reviewed & tested by the community

Setting back to rtbc, testbot broken for D6. Loads of good feedback, could use the eye of a core maintainer...

Ela’s picture

mr.baileys’s picture

Version: 6.19 » 6.x-dev
Status: Reviewed & tested by the community » Needs work

This is not ready to be committed yet, as the patch in #17 was set to RTBC by the same person that rolled it, while standard procedure is to have at least one independent review before setting a patch to RTBC.

Additionally, I think Dave Reid's comment in #6 is correct: l() expects an array as third parameter. If anything else is passed to it, then this needs to be fixed wherever l() is invoked incorrectly (could be core or a contrib module), not in l() itself.

I think that l() should be at least able to accept null options without failing with fatal error.

Drupal core can fail in a multitude ways if you don't use the correct function signatures. The standard approach is that we "don't babysit broken code", meaning we don't go through great lengths to prevent fatal errors being thrown when core functions are called incorrectly by faulty code. In short: we need to fix the root issue, not the symptom.

Damien Tournoud’s picture

Status: Needs work » Closed (works as designed)

There is nothing to fix here. Drupal Core works as designed, but something is calling the API in an incorrect way. Try to fix the really issue, not the symptom, please.

fcaneda’s picture

Status: Closed (works as designed) » Needs review

#4: common-228435-4.patch queued for re-testing.

Kjartan’s picture

Status: Needs review » Closed (works as designed)