By isak_manresa on

Hi everybody,

When I try to upgrade Durpal 7 from 7.21 to 7.22 or later version I get the following error, while running update.php:

"Fatal error: Unsupported operand types in /xxxx/xxxxx/www/modules/field/field.info.class.inc on line 479"

The Drupal 7.22 version adds the "field.info.class.inc" file in the field module. This file is not present in 7.21 or older versions.

The line 479 of that file is:

"$field['settings'] += field_info_field_settings($field['type']);"

I'm running PHP 5.3.2 version and MySQL 5.1.73-0ubuntu0.10.04.1-log version.

Anyone knows why this problem happens?

Thanks in advance!

⋅ Categories: Drupal 7.x

Comments

John_B’s picture

John_B commented

Did you run database updates after updating?

If so and you still have a problem, you probably have an old version of a contributed module which is not compatible with the later versions of core. You may be able to find which module that is from Reports > Recent Log Messages. If you cannot, you could try the laborious method of disabling contributed modules then re-enabling them one by one.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

isak_manresa’s picture

isak_manresa commented

Hi John_B,

Yes, I run databes updates after updating. When I execute the update.php file the Error apears.

I also try disabling contributed modules and the upgrade works only when almost all modules are desactivated. When I reactive the main contributed modules the Fatal Error apears again.

I also try to upgrade all the contributed modules to the last version, but the error still apears.

Any other idea?

Thanks!

John_B’s picture

John_B commented

Are you really saying you have the latest version of all contributed modules, have disabled any custom modules, and have cleared caches (and if you are using an opcode cache, made sure that is clear, probably by restarting the webserver)?

If so, chances are you have some incomplete code, and it may be worth copying it over again, as suggested here http://drupal.stackexchange.com/questions/44605/fatal-error-unsupported-...

Since re-enabling contrib modules caused the problem to come back, you should be able to narrow down exactly which module(s) trigger the problem (provided you are enabling them then checking the site, one module at a time). A laborious but often a productive method of diagnosis.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

isak_manresa’s picture

isak_manresa commented

Hi again,

I've tried a lot of diferent things during this days but I can't solve the problem.

The only way that the error doesn't appears is disabling all contribuited modules, and going to pages that doesn't use the contributed modules (for example, if I go to a page that is using webfom functionalities the error apears).

When I re-enable any of the contribuited modules (using new or older versions) the error apears going to any page, that use functionalities of the contribuited module.

I also tried to copy the code again several times, but the error still appears in localhost server, and in the production server too.

Is there any way to get more information of the problem that causes this error??

Thanks a lot!!

John_B’s picture

John_B commented

If you are copy the code and getting faulty code every time (which is not proved but is a hypothesis) it sounds as though the code you are copying already corrupt. One way to check this is, as suggested under the stackexchange link, to use https://www.drupal.org/project/rebuild. Another way is to download and run Hacked module ('Hacked' is the name of the module). If your site is not working, both these options assume that you are working from command line with drush. One of those two methods of looking for or correcting corrupt code would be my next move. Note with Hacked module there are false positives. It is pretty obvious which differences from a standard codebase are the ones to worry about.

If every module you enable breaks the site, including modules which do not touch the field system, let alone create a field, then the situation is very surprising and mysterious. Can you not even find a 10-line very simple module which does not break the site? I am really struggling to believe that every module you enable, even a basic Hello World module like the one described here http://stackoverflow.com/questions/15426755/i-need-to-create-a-simple-mo..., is breaking the site. Why not try creating and installing that module. Disable every other contributed module. This way you can double-check your theory that any single contrib module, however simple, is enough to break the site.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

isak_manresa’s picture

isak_manresa commented

Finally I can verify that the contribuited modules that causes the break are "views" and "administration menu".

If I disable and upgrade the other contribuited modules to the last version, one per one, and truncating the cache_field table before re-enable some of them, the error doesn't appear, during the module upgrade process.

However, although not enable the administration menu, views and their dependecies, in some of the pages of the site the error apears (the pages that uses views, or have webforms, for example). Restoring the 7.22 core version the error disapear, so this version doesn't have the line of the field module that causes the break.

So, now that I have more information about the modules that probably cause the break, the best way to proceed is using rebuild or hacked module to look for or correct corrupt code?

Thanks a lot Jhon_B!

John_B’s picture

John_B commented

Administration Menu can be oddly buggy. Anyway the site will work without it. I would disable it sort out the Views problem first, then return to it when other things are fixed. By all means make sure the Views code is OK. Did you upgrade Views too?

I wonder whether it is worth enabling Views then disabling each View to see whether Enabling Views and Views_UI module without an views present is causing a problem.

I am not comfortable that I am giving useful answers because I am puzzled by the problem. Of course, the whole thing is compounded if the site has been publicly available because it is general beleived that most Drupal 7 sites which were not updated promptly to 7.32 have been hacked: https://www.drupal.org/PSA-2014-003. Perhaps your site has been damaged by hackers?

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

isak_manresa’s picture

isak_manresa commented

Yes, I've updated Views to the last version.

I've tried to disable all views (and delete the ones that can delete), but the error appears too when I upgrade to 7.34.

I'll try to use the hacked or rebuild module, hope can help me to solve the problem.

And yes, my production site was hacked, that was the reason I start to upgrade core and contributed modules to the last versions. At the moment the site is working fine but sometimes appears new admin users created by the hackers.

I tried to upgrade the core with a backup version of October 12th (before the site was hacked) but the same error appears in the upgrade process.

John_B’s picture

John_B commented

It sounds like there is a hack in the database as well as the code.

If you restored the code and not the database, the hack is still there. You need to restore both code and database at the same time to a pre-Oct. 15 th version, if that is possible.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

isak_manresa’s picture

isak_manresa commented

Yes, I did the restore of both, code and database. The day of the restore was Oct 6th (not Oct 12th as I said before). The first time I've got the error was updating the restored version.

I've used the hacked module and get this information:

Changes of views module

ORIGINAL
- var queryString = queryString.slice(1).replace(/q=[^&]+&?|&?render=[^&]+/, '');

ACTUAL
+ var queryString = queryString.slice(1).replace(/q=[^&]+&?/, '');

There's another changes in default.settings.php, example.sites.php, and Readme.txt of the core but aren't significative.

There's some modules that have .gitignore deleted also and core have .htaccess deleted.

No other changes are reported.

If I upgrade the views module to the last version, the changes disapear, but the page still breaks.

Is there a way to check if the database is hacked?? I've googled looking for this with no lucky.

Thanks!

John_B’s picture

John_B commented

I read that typical hacks involve adding an 'assert' or 'file_put_contents' to the menu router table.

Have you tried winding back to pre-update backup of the database, then re-running the database updates? Sometimes during an update the database simply gets corrupt, and in my experience Views is particularly subject to this. I have the experience that simply deleting a View and re-importing it fixes an error. Who knows why these unfindable (to me) database problems arise: they are rare and seem to happen more often when updating a site on a server which is busy with other things, for example on shared hosting.

EDIT are you really saying that enabling Views & Dependencies and nothing else, the error was still there? I was expecting it to be a conflict between two modules rather than a single module. I am asking just to help keep track of this puzzling problem.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

isak_manresa’s picture

isak_manresa commented

I look for a new fields or columns in menu_router table that match with 'assert' or 'file_put_contents', and there aren't any matches.

I did the update (in a shared host) with the backup of Oct 6th and then I ran the database updates. Now I'm working in localhost with more recent version of the database, so all the previous backups of Oct 15th has been deleted of the server.

I try to delete views (not only disable), and then reinstall, with no luck. I also try to disable all the other modules (except the most important modules of the core) using the last version of views and the error apears too.

I'm thinking in pay some drupal expert that can help me to solve this problem, so at this time I don't know what can I do to solve the problem, and my drupal knowledge is not so high (I'm the developer and maintainer of my enterprise website, but I don't work in web developing).

John_B’s picture

John_B commented

Yes, it is a bit mysterious. Sometimes hacks can be very hard to track, although most of the hacks from the particular security hole in question have been so far relatively simple. I am sorry we have not been able to solve this one yet.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors