Hi, what can i do with this error:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://d7.xxxxx/update.php?op=selection&token=o0hzVOphZk2Yr4k0UG_CYS7zr_TJz03_9XtmvHSCBBk&id=4379&op=do StatusText: OK ResponseText: Fatal error: Call to undefined function _update_7000_field_read_fields() in /home/www/xxxxx/d7/modules/image/image.install on line 343
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Prague man’s picture

Issue summary: View changes

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://d7.xxxxx/update.php?op=selection&token=o0hzVOphZk2Yr4k0UG_CYS7zr_... StatusText: OK ResponseText: Fatal error: Call to undefined function _update_7000_field_read_fields() in /home/www/xxxxx/d7/modules/image/image.install on line 343

StevenPatz’s picture

Component: install system » base system
Category: task » bug
xjm’s picture

Category: bug » support
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

Hi @mpark,

I'd suggest doing some more troubleshooting and providing more detail.

  • When do you get this error message?
  • Have you cleared the site cache?
  • Did you encounter any error messages during the upgrade process?
  • Did you disable all contributed modules before upgrading code?
  • Are you sure the files for Drupal 7 were all copied into the correct locations?
  • Have you tried reverting to your backed up database and trying the upgrade again?

Thanks.

Prague man’s picture

Hi,
I tried a long time to upgrade again - the same result.
I proceeded as follows:
1) update modules for Drupal 6
2) uninstall unneeded modules (in fact all except the core)
3) deleted Drupal 6.22
4) uploaded Drupal 7.10 (and modified the settings.php file)
5) entered update.php
6) 143 update was needed, but it stopped at around 120 update with this message:
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. path: StatusText: OK responseText: Fatal error: Call to undefined function _update_7000_field_read_fields () in / home/www/myserver/modules/image/image.install on line 342

dkingofpa’s picture

Title: After upgrade 6.22 to 7.9 error with image.install on line 343 » Call to undefined function _update_7000_field_read_fields() in image.install during upgrade
Version: 7.9 » 7.12
Component: base system » database update system
Category: support » bug
Status: Postponed (maintainer needs more info) » Needs review
FileSize
646 bytes

I was having this issue as well when upgrading core from 6.24 to 7.12 via the drush updatedb command.

Executing image_update_7002 [80.5 sec, 29.37 MB]                                                                                                                                   [notice]
Drush command terminated abnormally due to an unrecoverable error.                                                                                                              [error]
Error: Call to undefined function _update_7000_field_read_fields() in /Users/dking/Projects/test/upgraded.www.test.org/modules/image/image.install, line 342 [80.5 sec, 29.37 MB]
Output from failed command :                                                                                                                                                    [error]
 
Fatal error: Call to undefined function _update_7000_field_read_fields() in /Users/dking/Projects/test/upgraded.www.test.org/modules/image/image.install on line 342 [80.5 sec, 29.37 MB]

I set a dependency on the image module so it's upgrade isn't run before the fields module is enabled (system_7020). Patch attached. I also changed the subject to better reflect the issue.

xjm’s picture

Version: 7.12 » 7.x-dev

Ah, good catch! This looks like a correct fix. I wonder, is there a way to trigger the hooks running in the wrong order to write an upgrade path test for this?

BTMash’s picture

Checking through this...is there a reason image does not have a dependency on field? I understand that there can be field styles but it seems very strange that since it is primarily going to be the images that will use the field styles anyways that field should not be required. Otherwise, image styles should have been split out from the image module.

BTMash’s picture

I should have noted that the patch looks good - I'll see if there is any possible way to have upgrade tests for this.

BTMash’s picture

I actually don't know how I am going to test this (as my suspicion is that this was caused by a particular contrib module) ... I was trying to figure out the circumstances under which a possibility like this could occur and so ... @dkingofpa, did you have the image module installed when you ran your D6 website? Also, was the module disabled when you did the upgrade to D7?

EDIT: I ask this because image module for D6 is not the same module as the image module for D7 and so I can see a situation where moving from D6 to D7 (and isn't there an issue about updates running even though modules are disabled?) could certainly cause this issue.

dkingofpa’s picture

High-level overview of my upgrade steps:

  1. [D6] - Set all themes (default and admin) to Garland.
  2. [D6] - Uninstall any currently disabled modules: drush pm-uninstall `drush pm-list --type=module --status=disabled --pipe` --verbose --debug
  3. [D6] - Disable all contrib modules: drush pm-disable `drush pm-list --no-core --status=enabled --pipe` --verbose --debug
  4. [D6] - Move all contrib modules out of the drupal folder (so we only upgrade core first).
  5. [D6] - Upgrade core to D7: drush updatedb --verbose --debug
  6. Error: Call to undefined function _update_7000_field_read_fields()

Yes, the image module was installed (downloaded and enabled) in the D6 site. During the upgrade, the image module was disabled and then moved out of the drupal folder. The D6 image module code was not in the drupal folder when updatedb was run.

dkingofpa’s picture

FileSize
90.39 KB

Attached is a screenshot of my image module list on the D6 site prior to any of the upgrade steps.

BTMash’s picture

I'm actually a little stumped on how to approach this issue. And the reason for this is because the image module in D6 is *completely* different from the image module in D7 (which has far more in common with imagefield) and because D7 has the image module in its core modules list.

What I see has happened is:

  • You disabled the contrib image module. And you removed it.
  • You moved the site to D7.
  • Drupal saw you had a disabled image module but now pointed it to modules/image instead sites/blah/modules/image
  • Somehow, even though your module was disabled, drupal tried to upgrade it (isn't there an issue on this one somewhere??).

Since field was never installed (and image module's weight shows up before system * modules - I checked it and that is what the ordering is like), we end up in the situation you did. I think the patch is good, but as far as testing goes for this, I currently don't see an easy way to do so :( Any suggestions/guidance on this would be very helpful).

BTMash’s picture

Status: Needs review » Reviewed & tested by the community

I've talked with @webchick about this issue and based on our discussion...this patch looks good to go. We cannot write a test case for this as it requires a d6 contrib module (and putting that into core as a hidden module or creating a stub module would take quite a while) and the only real fix for this would be to fix up the disabled modules updates issue. As far as we see, this patch is safe and shouldn't cause any other issues (system update(s) run before image? Sounds pretty reasonable to me).

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 7.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

DarrellDuane’s picture

Status: Closed (fixed) » Needs review
FileSize
395 bytes

I received this error while running update.php even though I have the latest version of Drupal installed that includes this patch.

I was able to fix it by including this line at the top of image.install:

include_once  drupal_get_path('module','field') . "/field.install";  // needed for migration

Attached is a patch to insert this line.