By Lubkin on

Stumbled into an old problem on 7.50. Poking around, I see that while core module image's image_update_7005 was run, 7002 and 7004 weren't. Both add columns to the two field_*_field_image tables. 7002 also calculates and inserts the correct values for its columns for existing images.

I could fix this all by hand but next time it may be more intricate. What's the recommended approach to safely making sure that all skipped or failed updates are correctly applied when a core module is involved?

(I saw a suggestion in https://www.drupal.org/node/1348410#comment-5273968 of

UPDATE `system` SET `schema_version` = '7001' WHERE `system`.`filename` = 'modules/image/image.module';

but that's not clean any more. 7005 doesn't quietly do nothing if its changes are already in place.)

⋅ Categories: Drupal 7.x

Comments

Jaypan’s picture

Jaypan commented

I don't know how you could have missed updates, as later updates wil not be run without first running earlier updates, unless you manually changed something in the database first to tell the system that the updates had already been run. So you should really confirm that is the case, as it doesn't really seem possible.

Now if you confirm that this truly is the case, that somehow these updates really were not executed, then you can do the following:

  1. Change the schema version to 7001:
    UPDATE `system` SET `schema_version` = '7001' WHERE `name` = 'image';
  2. Manually edit /modules/image/image.install, and remove the functions image_update_7003() and image_update_7005()
  3. Run update.php (or update with Drush or whatever)
  4. Change the schema version to 7005:
    UPDATE `system` SET `schema_version` = '7005' WHERE `name` = 'image';
  5. Replace image_update_7003() and image_upate_7005() that you removed in step 2
Lubkin’s picture

Lubkin commented

I had not changed anything in the database manually. I'd started with an install of 7.50, added modules, added an image field to two new content types, created a couple of nodes for one of the types, and then added other modules. I'd have to research what those new modules were but the next time I went back to edit those nodes, the DB update failed because of the absence of the fields that 7002 inserts. Then I confirmed that 7004's changes were missing and 7005's changes were there. (One can't tell if 7003 has been run or not on a 7.50 install since it's removing variables that aren't in Drupal any more.)

Your sequence would fix the immediate problem. It sounds like if the site is still broken in another way I should just start over with a clean install, and check more thoroughly for problems between each module addition—I hadn't done that much on the site yet. That would have the advantage of either being known to a stable setup or pinpointing how those 7002 and 7004 DB modifications aren't in MySQL.

Jaypan’s picture

Jaypan commented

If you started with 7.50, then any changes in updates prior to that should have already been incorporated into the code. If it wasn't done, that's a major bug in core, and you should open an issue in the Drupal issue queue (https://www.drupal.org/project/issues) indicating this, and hope for a fix. Or you can do what I suggested. But to be honest, I'd be pretty darn surprised if you haven't misdiagnosed the issue, or done something else to cause this issue, as there are tests run against each new Drupal update, to ensure something like this hasn't happened.

If you do open a new issue in the issue queue, you'll need to provide a method to replicate the issue, so when you do that, you can check to confirm if you really did correctly diagnose the issue.

Lubkin’s picture

Lubkin commented

You're assuming the updates didn't occur. The other possibility is that they were there and something undid them. A misbehaving non-core module seems more likely than a problem this major in core.

I can't see where I could have misdiagnosed. I installed 7.50. When I got: 

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column
'field_image_width' in 'field list': INSERT INTO {field_data_field_image}
(entity_type, entity_id, revision_id, bundle, delta, language, field_image_fid,
field_image_alt, field_image_title, field_image_width, field_image_height)

etc., I googled and found that old issue. Which led me to 7002 adding field_image_width and field_image_height. Went to MySQL, looked at the tables and saw the columns aren't there. Also saw the lengths changed by 7004 aren't there.

Compared with another site I have on the same server that's on 7.41. Its field_data_field_image, in a different database, has those columns.

If I'm able to replicate this, I'll open an issue.