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

Nevermind: this was actually caused by the e-journal module!

The 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.

My 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"

http://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.

In my case the real solution was to upgrade links from beta11 to beta12

If 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.

I 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

By 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.

Since 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.

Fixed 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;)

Ok, 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.

See this document as well:
http://drupal.org/node/362799 (Fatal error: Unsupported operand types in common.inc)