I'm unable to disable the Video module using Drush or the Drupal interface while trying to upgrade from 7.x-2.4+23-dev to 7.x-2.4+48-dev. The module seems fused with Drupal core and can't be unselected without disabling many core modules. Here's the error I get with Drush:

# drush dis video
video is a required module and can't be disabled.                                    [ok]
There were no extensions that could be disabled.                                     [ok]

I don't have the same problem with Video.js (7.x-2.0-rc2) but, curiously, the Video.js module is added when testing the probable dependencies, while the Video remains unable to be disabled:

# drush dis field field_ui field_sql file image
text is a required module and can't be disabled.                                     [ok]
field_sql_storage is a required module and can't be disabled.                        [ok]
field is a required module and can't be disabled.                                    [ok]
image is a required module and can't be disabled.                                    [ok]
taxonomy is a required module and can't be disabled.                                 [ok]
video is a required module and can't be disabled.                                    [ok]
The following extensions will be disabled: field_ui, file, options, list, number, videojs
Do you really want to continue? (y/n): n
Aborting.                                                                            [cancel]

Here is a previous issue with a related title that apparently came from D6 but I don't get these errors:
http://drupal.org/node/1000926

Comments

Jorrit’s picture

Jorrit commented
Status: Active » Postponed (maintainer needs more info)

Is the video module part of your profile? Can't you just upgrade without disabling?

michael.k’s picture

michael.k commented

I have not set up any custom profiles or installations. I generally select the standard installation option when setting up Drupal with a new database.

When the site is up, I usually use drush to install -dev versions by typing "drush module-devVersion" but I've read that Drupal does not update them faster than once per day. So, because you're so fast with these fixes(!!), I use wget and reference the dev page with the detailed version number.

It may be obvious but worth mentioning that "drush up" doesn't work because it only looks at the recommended release.

Yes I can force the upgrade by overwriting the directory, but that has produced errors with this module in previous sandboxes and broken the site. Something is wrong if the module cannot be disabled.

Jorrit’s picture

Jorrit commented

What do you mean by "I use wget and reference the dev page with the detailed version number."? My guess is that that also doesn't update faster than once per day.

Maybe try the following procedure:

rm -rf modules/video
drush dl video --select

I'll look into the reason for this module being required.

Jorrit’s picture

Jorrit commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

The module can't be disabled if it has active fields, see the documentation of http://api.drupal.org/api/drupal/modules!field!field.module/function/fie... . That function provides an explanation for this, but that isn't displayed by Drush.

michael.k’s picture

michael.k commented
Status: Closed (works as designed) » Postponed (maintainer needs more info)

Sorry the confusion. I try to be clear in these posts, as well supply more detail for the benefit of others who may read them. It's very frustrating to read through oblique or incomplete references to solutions that are "inside baseball" and not be able to resolve your own issues. Plus, Drupal and many other open source projects involve people who speak a wide variety of other languages.

Anyway, please let me know if I am mistaken about this: My understanding is that simply overwriting a module's directory with a new version doesn't properly address the database issues when upgrading because of how Drupal manages modules, so I assume it is best practice to first disable a module before replacing its directory with a new version. Formally uninstalling it would (and should) delete content from the db, which is undesirable if you need to preserve it and important if you're trying to clear the tables. The Video module is not able to be cleared properly, which is why I have to continue building more sandboxes.

Regarding wget, what I mean is that I prefer to use drush when possible, so I download and enable modules, also disable, update, clear cache, backup, install drupal etc. I can successfully overwrite a module with "drush dl module" or "drush dl module-alternateVersion" but because you are providing fixes so fast (which is freaking awesome), I use the wget command to be certain about what is being downloaded.

For example, to download the latest Video-dev version, I visit http://drupal.org/project/video and click on the notes link for the latest dev, which points me to http://drupal.org/node/1215918. There I find the link to the tar file for 7.x-2.4+50-dev, so I copy the link and paste it in a shell:

wget http://ftp.drupal.org/files/projects/video-7.x-2.x-dev.tar.gz

michael.k’s picture

michael.k commented

Regarding #4: In the past, I have created a lot of fields with other modules but been able to disable and re-enable them without errors, so I am confused about this. Surely, one shouldn't have to delete all the content that has custom fields in order to disable a module?

Jorrit’s picture

Jorrit commented

The rule that modules can only be disabled when their fields are removed was introduced in Drupal 7.8 (#943772: field_delete_field() and others fail for inactive fields).

To my understanding, there is no difference between drush up and downloading the tar file and running update.php. However, you must make sure to run drush rf to refresh the update status cache. -dev releases are created once per day, but the update status cache is also only refreshed once per day. In the worst situation, a new -dev release would only be picked up two days after it was created, so I always run drush rf before drush up.

You are saying:

My understanding is that simply overwriting a module's directory with a new version doesn't properly address the database issues when upgrading because of how Drupal manages modules.

If you remove the module directory, download the new version and then run update.php, you should be fine. After all, that's what drush up does.

I see that you have updated video8. From what I can see, the database has been updated successfully. For instance, the video tag http://video8.mkdev.org/node/14 now lists webm, mp4, flv and ogg.

Jorrit’s picture

Jorrit commented

I have created #1467800: Show explanation when required modules can't be disabled so Drush might be updated to show the reason that the module can't be disabled.

michael.k’s picture

michael.k commented

Thanks for the reference node in #7. It's interesting to read about how this fix was added to prevent orphaned data after a module is removed.

Also, thanks for the tip about running "drush rf" first. But doesn't that only refresh the cache locally so wouldn't affect the issue of older caches on d.o?

I hope they implement your patch because it certainly is a good idea to have drush explain why it can't disable a module.

Jorrit’s picture

Jorrit commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

Well, there is no cache at d.o. As far as I know, a process at Drupal.org looks at the commits for every project once a day, and creates a new dev release when there have been commits since the previous one. So you always have to wait at most a day before the tar.gz is updated.

So, assume the following time line:

Day 1, 01:00: your Drupal cron refreshes its update cache.
Day 1, 10:00: I fix a bug and commit a change.
Day 1, 16:00: Drupal.org checks if there have been commits since the previous commit, creates a new release and publishes it. It contains my change.
Day 1, 17:00: You use drush up and you find no updates, because it uses the cache from 01:00.
Day 2, 01:00: your Drupal cron refreshes its update cache and finds my new release.
Day 2, 10:00: You use drush up and you find my new release.

So when you would have used drush rf at Day 1, 17:00, you would have seen the Day 1, 16:00 -dev release.

In contrast to many other Drupal modules, the maintainers of Drush have responded very quickly and have committed my patch.