Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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?
Comment | File | Size | Author |
---|---|---|---|
#17 | common-404-path-error.patch | 441 bytes | ayalon |
#4 | common-228435-4.patch | 469 bytes | hitka |
Comments
Comment #1
wildtang3nt CreditAttribution: wildtang3nt commentedI 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.
Comment #2
wildtang3nt CreditAttribution: wildtang3nt commentedI 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.
Comment #3
wildtang3nt CreditAttribution: wildtang3nt commentedIt 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).
Comment #4
hitka CreditAttribution: hitka commentedI 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 functionl()
is not an array (e.g. when it isnull
). I think thatl()
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.Comment #5
chingsha CreditAttribution: chingsha commentedI've run into the same problem, and your advise did work!! Thx!
Comment #6
Dave ReidThis 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.
Comment #8
RedTop CreditAttribution: RedTop commented@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. :)
Comment #9
atzanov CreditAttribution: atzanov commentedI 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.
Comment #10
Fogg CreditAttribution: Fogg commentedPatch 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).
Comment #12
cybernomad CreditAttribution: cybernomad commentedThis patch worked for me too, Drupal 6.16
Comment #13
wxman CreditAttribution: wxman commentedI just had the same problem, and I'm using Pressflow 6.17. The patch worked there too.
Comment #14
Coupon Code Swap CreditAttribution: Coupon Code Swap commentedPatch still works with Drupal 6.19.
Comment #15
angusi CreditAttribution: angusi commented#4: common-228435-4.patch queued for re-testing.
Comment #17
ayalon CreditAttribution: ayalon commentedI had the same problem an recreated a new better formatted patch.
Comment #19
adbn CreditAttribution: adbn commented#4: common-228435-4.patch queued for re-testing.
Comment #20
jibize CreditAttribution: jibize commentedPatch worked for me on Drupal 6.19.
Comment #21
Danny_Joris CreditAttribution: Danny_Joris commentedPatch worked for me too in Drupal 6.19. Thank you!
I don't know where the issue came from, but it looks fixed now.
Comment #22
San_ANDREYEV CreditAttribution: San_ANDREYEV commentedWorks for me too, D 6.19.
I came from here - http://drupal.org/node/739158
Comment #23
christopherareed CreditAttribution: christopherareed commentedThe 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).
Comment #24
dddave CreditAttribution: dddave commentedSetting back to rtbc, testbot broken for D6. Loads of good feedback, could use the eye of a core maintainer...
Comment #25
Ela CreditAttribution: Ela commentedthe patch here works for me: http://drupal.org/node/739158#comment-3684276
Comment #26
mr.baileysThis 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.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.
Comment #27
Damien Tournoud CreditAttribution: Damien Tournoud commentedThere 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.
Comment #28
fcaneda CreditAttribution: fcaneda commented#4: common-228435-4.patch queued for re-testing.
Comment #29
Kjartan CreditAttribution: Kjartan commented