Closed (won't fix)
Project:
Drupal core
Version:
6.9
Component:
base system
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Dec 2008 at 03:37 UTC
Updated:
18 Jun 2009 at 12:57 UTC
Jump to comment: Most recent file
Comments
Comment #1
bomarmonk commentedNevermind: this was actually caused by the e-journal module!
Comment #2
kenorb commentedThe same problem, but I don't have e-journal module.
I've did some changes in Filtered HTML Filter and now when I'm going to admin/settings/filters/1 or many other pages I've got blank screen with the same fatal error:
In line 1369 there is array:
Issue: $options argument received NULL from some unknown module.
Comment #3
kenorb commentedMy solution was to add following validation line before $options line:
Then I can disable my broken filters back (without restoring my whole database from the backup).
So it should looks like:
function url($path = NULL, $options = array()) {
$options = is_array($options) ? $options : array(); // validate $options input
// Merge in defaults.
$options += array(
'fragment' => '',
'query' => '',
'absolute' => FALSE,
'alias' => FALSE,
'prefix' => ''
);
And of course I know that Drupal doesn't support invalid modules and I'm a clairvoyant and I should know which module from around 123 is broken in few seconds.
And I'll spend whole week for searching which module was buggy and the users on production until this time will see the blank screen.
I think it's a bad goal, because it's always and it will be a nightmare for developers.
In case if this condition were already in Drupal, then maintainer of the module should worry why some argument is not passing throught, instead of breaking the whole working website to inform all users of the website, that some module is broken.
Google Results about 287 for "common.inc on line 1369"
Comment #4
kenorb commentedhttp://www.r-feed.com/node/2015
http://acquia.com/node/178429
http://www.ovelho.com/content/bug-no-site-fatal-error-unsupported-operan...
#351029: Unsupported operand types in ../public_html/includes/common.inc on line 1369
http://www.amchome.com/forum/2 - LOL!:)
http://www.bookzek.com/node/501 - LOL!:)
http://www.innebandy.dk/multimedia/test-3 - LOL!:)
http://chistescool.com/hiwz/?q=node/4 - LOL!:)
http://twitter.com/joncates/status/1081687549 - LOL!:)
I think it's a quite serious problem on many web sites and blank screen is not good solution for that.
Comment #5
kenorb commentedIn my case the real solution was to upgrade links from beta11 to beta12
Comment #6
yhager commentedIf the idea in #3 is the right direction, I can prepare a patch.
I think defensive programming is generally a good idea, so core should not break with misbehaving modules.
Comment #7
jcmarco commentedI found the same bug when anonymous user was accessing to information out of the home page.
I don't have nor links neither e-journal. I will try to find what module is causing the problem.
Buy I agree with #6, by the way the solution in #3 solved my problem.
Here is my patch for #3
Comment #8
jcmarco commentedBy the way, in my case was community tags
http://drupal.org/node/294397
The bug was reported, fixed and created a patch three weeks ago, but the maintainer it is not updating anything since August.
Comment #9
dave reidSince this seems to happen frequently with improperly-converted contrib modules, I have created a new Troubleshooting FAQ page about this error that explains how to debug this problem and find the offending module. So now I'm marking this as fixed since Drupal core does not babysit broken code. It is up to the module maintainers to write and test their code.
Comment #10
kenorb commentedFixed even it's not fixed, as always;p
And the Drupal users are the most injured.
Appeal: #362931: Automated testing for contrib modules
Please vote;)
Comment #11
dave reidOk, then I'll set the more appropriate status. I know it sucks when contrib modules don't use the correct code, but there are too many places just like this where we could baby-sit broken code, or just ignore something that should be an error. It should be an error so that the module can be fixed. I went out of my way to create documentation on how to debug this error, but there's nothing that Drupal core can do.
Comment #12
kenorb commentedSee this document as well:
http://drupal.org/node/362799 (Fatal error: Unsupported operand types in common.inc)