Hi all,

totally new heer but already having problems.

I can't load the installer. I get the following error:
Fatal error: Unsupported operand types in /drupal/includes/form.inc on line 342

Any help here?


pobster’s picture

It's a bug with using views_fusion and/ or shared (prefixed) dbs. I'm sorry I can't be more help than that, it's nothing much to do with me. If you're using a db prefix, try erm... not...


DonTino’s picture

I just dowloaded the latest dev version.

Works perfectly with it. The bug seems to be fixed there.

Thanks for the help anyway

FvanT’s picture

latest CVS still gives me this error on update.php but on a different line

Fatal error: Unsupported operand types in /var/www/localhost/htdocs/drupal-5.1/includes/form.inc on line 379

PHP version is 5.2.2, is that the problem ?

Shiny’s picture

I also had the same error today. Here's how i solved it
(please do on a testing site first)

1. rolled virtual host back to drupal-4.7
2. disabled all modules
3. ran update.php (just to check)
3. updated forward again to drupal 5.1
4. ran update.php


drinkypoo’s picture

I think that this should be recorded for posterity

There's a short list of reasons why this happens.

One possibility is doing something stupid with forms. If you installed a new module recently, or started using the functionality of a new module recently, try not doing that.

Another common possibility is that you have some corrupt files for one reason or another (your disk is dying, your ISP is stupid, you had some error while uploading files, aliens modified your bits, etc etc) and you just need to upload files. There are numerous file comparison and synchronization tools out there (rsync, mirror, blah blah blah) and I don't want to go into that topic because most of them suck. rsync is good but hard to use well. YMMV.

But another possibility is that drupal decided that a module lived in some magical new location. It does this automatically for your own good. For example you're using a module in a site-specific directory (say, sites/default/modules instead of sites/all/modules) and you want to move it so that all sites in a multi-site installation can get to it. A pretty reasonable way to handle development (although I certainly wouldn't use shared dbs!) It's also good if you want to override a system module; just copy it from the drupal modules directory (the one in drupal's root) to some other modules directory (under sites) and drupal will use the copied file instead of the original one. Then you can make changes at will. I suggest putting those changed modules right in the root of the site (or all) modules directory so they're easy to identify later.

So drupal discovers that you moved the module and updates its path in the system table. And we maybe don't want this to happen. It just happened to me. Note that drupal also feels this way about themes...

If you accidentally unpacked drupal in some place where modules are kept, and then viewed any page, it's possible that drupal is now looking someplace new for your modules. And if it doesn't decide to look again (it doesn't seem to look for missing system modules in the system modules directory, maybe that's a feature request for 6, I guess I'll go make one) then you will have to go and manually edit your tables.

It's actually not difficult to diagnose and repair this problem just with the mysql CLI (my examples will use mysql, but other databases will work in similar ways) and that's how I'm going to explain this first. Then I'll explain how to do it with mysqldump and mysql; the same tactics, again, will work on other systems.

First, remove the redundant directory. I had unpacked it into the modules directory (while unpacking a bunch of modules, of course) and so it was in /var/www/public_html/sites/all/modules/drupal-5.1. This is where my webroot (the public_html dir) lives, because I put it there, this is Ubuntu so it defaults to /var/www/html or something. This is only significant because it will determine what commands I type. In my case it's rm -rf /var/www/public_html/sites/all/modules/drupal-5.1.

Now run mysql (mysql -u drupal -p drupal, or similar) and enter your db user's password, you get the prompt and you're using your database (in this example the user and db are both 'drupal', which is probably the most common case anyway.) Then you run the following command:

SELECT name, filename FROM system WHERE filename LIKE '%drupal-5.1%';

This command shows the filenames and names from the system table if they contain the string 'drupal-5.1'. This will not help you if you actually have this directory in your path, or if you're using another version of Drupal. Display some adaptability in determining what should be in the %% (SQL's wildcard character.) AFAIK there should be only one occurrence of each name here. Drupal should be using only the last (or so I suspect) example of each module (by name) that it locates. A number of things are keyed off names in drupal, or so it appears (I know only enough to be dangerous, and welcome corrections.)

If this doesn't give you anything back, then your problem is probably something else. But you probably wouldn't have done this much if that were the problem. You can literally solve this problem by entering the following sort of thing:

UPDATE system SET filename = 'modules/user/user.module' WHERE name = 'user';

And you'd do this for each of the system modules. There's probably some slick SQL way to do this that isn't even hard, but frankly what I know about SQL is right up there with what I know about who killed Kennedy or what's under the white tape on the CIA family jewels. (Which might be related!) :)

Okay so this isn't how I did it. I did it like this: I used mysqldump (mysqldump -u drupal -p drupal system > drupal.system) to export just the system table into a file. Then I edited the file and did a global search and replace to turn sites/all/modules/drupal-5.1 into nothing, which stripped the BS part of the path off the front and left the actual path to the module behind (which is relative, of course, to the drupal root.) et voila, the problem was solved.

I then took the easy way out and instead of even figuring out how to do this with the theme, I (manually) visited admin/build/themes and set the theme, at which point the system seems to be back to normal.

Hope this helps someone someday.

demo9’s picture

I had the line 342 error and was trying all sorts of stuff to fix it. In the end (after reading drinkypoo's post a second time!), it turned out to be missing system files. I had developed the site one one machine and then uploaded it (FTP) to the prod server. For some strange reason the directory /modules/system had completely vanished! I don't remember seeing any errors but then I was burning the midnight oil (more like 4am), so I may have missed something... ?

So, after reading this thread (again) I simply copied the /modules/system directory from the latest drupal 5 tar.gz file and "bingo".

Hope this helps someone else, although I never did figure out what happened to the missing files..?

doublejosh’s picture

I thought it might be that I was setting up a second Drupal install on the same shared host account... but it was a system.module file of 0kb in the modules/system folder. So, go check that.

Wutime’s picture

Same issue... just about to launch the website for a client and the entire site doesn't work:

Fatal error: Unsupported operand types in /drupal/includes/form.inc on line 342

Does anyone have any idea how to troubleshoot/fit this issue?

I've tried running update.php, and overwriting with 5.1 zip, and then running update.php... but always get the same error; even when trying to execute update.php... :(

Dave Cohen’s picture

I don't know if this is the cause for everyone who wrote in here, but here's why this is happening for me.

Static variables are somehow being initialized when they shouldn't be. If you look at _element_info(), it starts something like:

function _element_info($type, $refresh = NULL) {
  static $cache;

  $basic_defaults = array(
    '#description' => NULL,
    '#attributes' => array(),
    '#required' => FALSE,
    '#tree' => FALSE,
    '#parents' => array()
  if (!isset($cache) || $refresh) {

In my case, the test isset($cache) is returning true when it shouldn't be. If I change the top line to

  static $cache=NULL;

That solves my problem, but then later I have similar problems elsewhere, because this pattern occurs all over the place in drupal.

But why this is happening I do not know! A bug in PHP??? I'm mystified.

PTLF’s picture

I am a drupal-beginner, may be a simple question: where do I find _element_info()?

Have the same mistake. At the moment I have two pages on my drupal using the same database. One works fine, the other gives me the line 342 message.

drinkypoo’s picture

If you look in drupal's code for "function function_name" then you can find where functions live. Example on Linux:

$ tar xfz drupal-5.7.tar.gz 
$ find drupal-5.7 -type f -exec grep -l 'function _element_info' '{}' \;

The 'find' command found all files in the drupal-5.7 directory (this way you're looking only at drupal's source, and not your files dir, and all the third party modules; you can do it against your webdir as well. You could make this much more complicated... etc etc) and then for each file it ran the "grep" command (in a nutshell, it searches for patterns which can just be words) with the -l flag which causes it to just print filenames. The '{}' is replaced with the filename and the \; ends the arguments to find's -exec option.

Now just open drupal-5.7/includes/form.inc and search for "function function_name" and you will find it:

 * Retrieve the default properties for the defined element type.
function _element_info($type, $refresh = NULL) {
  static $cache;

  $basic_defaults = array(
    '#description' => NULL,
    '#attributes' => array(),
    '#required' => FALSE,
    '#tree' => FALSE,
    '#parents' => array()

etc etc.

On Windows there is an option to "find files containing the words" or something similar. Hit Control-F in any Windows Explorer window to bring up the search pane.

There are tools for doing this sort of thing from various Unix GUIs as well, and on OSX the search tool also will allow you to specify contents of text files as search criteria. Hope this helps.

Dave Cohen’s picture

NIce tip on the use of grep and find. I use that sort of thing all the time, and I'm surprised to see it crop up in this particular thread. I do it this way:

find . -name .svn -prune -o -name CVS -prune -o -name '*~' -o -type f -print0 | xargs -0 -e grep -n -e "something"

The -prune options tell find to ignore CVS and .svn directories, and files ending in "~" because my editor saves backups that way. I pipe to xargs grep so that my search string ("something") comes at the very end of the command.

On Windows I recommend cygwin to get these features.

Dave Cohen’s picture

I had this problem (for reasons I describe in an earlier reply). And I think it had something to do with PHP session management. I can't be sure because I've changed more than one thing. But I think what solved it was setting PHPs session_id() properly. I was doing some funky user management stuff, allowing users to visit without cookies - that sort of thing.

So to anyone with this problem I recommend looking at what session_id() returns and if empty, set it.

Garrett Albright’s picture

(Whoops! This comment contained errant information. But I can't delete it…)

alextronic’s picture

bobthecow’s picture


... so if you need it in English, that's where it is :)

steelrh19’s picture

Hi, I got a big problem.

I was running the test module that was posted on the module tutorials nodes and I came up on a problem.

Fatal error: Unsupported operand types in /home/mavware1/public_html/rickh/includes/common.inc on line 1582

I deleted all the files in my ftp server then I reinstalled my files. The error was still there. Can somebody help me out please?

steelrh19’s picture

Hi, I got a big problem.

I was running the test module that was posted on the module tutorials nodes and I came up on a problem.

Fatal error: Unsupported operand types in /home/mavware1/public_html/rickh/includes/common.inc on line 1582

I deleted all the files in my ftp server then I reinstalled my files. The error was still there. Can somebody help me out please?

H_alt’s picture

I had the same problem but after carefully reviewing i found that there was a # missing in the form item eg:
'description' => t('Please Enter A Valid Number.'),
change it to this :
'#description' => t('Please Enter A Valid Number.'),