The latest version of D6 updates all modules in the modules folder to the latest update, whether or not they are installed. On top of that, the updates run in an arbitrary order -- it's not weight and it's not alphabetical and it's not in dependency order. So the updates for most of the CCK modules run before the update for the content module, and all while the content module is disabled.

This is introducing all kinds of problems, since we have always assumed that the modules we are updating are actually enabled.

For the moment, I'm adding if (module_exists) so it returns false so they at least won't run while the content module is disabled, but this needs investigation.

We also need to investigate whether and how to remove all API calls from the install and update files, which is what is being done in core, but re-creating all that code in the CCK install files will be a huge huge pain.

CommentFileSizeAuthor
#9 208576.patch3.76 KBasimmonds

Comments

moshe weitzman’s picture

moshe weitzman commented

instead of recreating code, i think we will want to simply include what we need. if we have to include all of cck, so be it. og includes its own .module file, for example.

karens’s picture

karens commented

Well my fix doesn't work. It returns FALSE and keeps the updates from running, but the next time you go to the update page, instead of seeing those updates still to run, they show no updates available, so now they'll *never* run.

karens’s picture

karens commented

OK, my fix didn't work, so I'll try including code. But I fear I'm going to have to include every one of the content modules files, including the .inc files, plus every one of the field files, to be sure all the right functions are available, and I'm still not 100% sure that's going to work because there may still be some assumptions under the hood that certain values exist, like variables, that won't exist if the module is disabled.

karens’s picture

karens commented

That's not going to work either. My biggest problem is that I have an update in the content module that *must* run before any of the field modules because it is updating the node_field table that they all share to add some new columns to it, and then the field updates populate it with some data. So if they try to populate the table before I update it, we get errors and the data is not saved.

CCK updates were ugly before this, they just got a bit uglier :(

Well, I'll figure something out.

I decided the fact that returning false didn't keep the schema version from being updated is really a core bug, so I file it as such.

moshe weitzman’s picture

moshe weitzman commented

yes, thats a bad bug. on the update.php page it looks like you can choose which updates to run but i think drupal just marks them all as run. so it is bad ui too.

karens’s picture

karens commented

The commit in http://drupal.org/node/209041 to always include content.module on the .install pages will help with this.

Now waiting to see if http://drupal.org/node/208602 gets in to see which way to go to ensure critical updates happen in the right order.

karens’s picture

karens commented
Title: D6 updates all modules whether or not installed » Abort updates if modules are not installed
Component: General » upgrade path

Renaming this to reflect the current state of the issue, and assigning it to the new 'upgrade path' category.

yched’s picture

yched commented

http://drupal.org/node/208602 got in since then, so if I get this right we do have a way to abort field modules updates if content.module updates have not been run yet, and display a message like 'please run update.php once more'.

Is that enough to fix the issue ? (no time to test this tonight, unfortunately...)

asimmonds’s picture

asimmonds commented
Status: Active » Needs review
StatusFileSize
new 208576.patch3.76 KB

I recently did a test upgrade of a 5.x-1.7 install to 6.x-2.x-dev (on Drupal 6.3) and ran into a problem of the updates for a number of cck field modules running before content.module updates. The errors generated were mainly because the 'widget_module' column was missing from the content_node_field_instance table.

The attached patch adds a check for the missing column into the field module updates that were a problem for me. It aborts the relevant update if the check fails, allowing you to come back and re-run update.php.

yched’s picture

yched commented
Status: Needs review » Needs work

Thanks asimmonds
I think we should rather check for the schema version of content module and skip all field updates if content schema version is still 5xxx.
We could also add a drupal_set_message to make it extra clear that the user needs to re-run update.php.
Asimmonds, is it too much to ask that you handle this ? :-)

Problem is : we can only affect 'core' field types. We will need to advertise contributed field modules to do the same.

yched’s picture

yched commented
Status: Needs work » Closed (duplicate)

OK, I forgot about that issue. We dealt with that in #304813: CCK module developers read this!!

asimmonds’s picture

asimmonds commented

@yched - Sorry, I thought I had uploaded my patch for this a couple of weeks ago, which was very similar to what you ended up committing.