Scenario

Install and enable feeds 7.x-2.0-beta3
Import some data, it works fine, so disable feeds
Upgrade the site to 7.x-2.0-beta4
Run drush updatedb

Error report

Setting the cache class for the cache_feeds_http bin failed because the FeedsHTTPCache class could not be found. Please rebuild the Drupal class registry and perform database updates again.

Does not help to run either of

drush cc all
drush php-eval "registry_rebuild();"

For most modules this would be a low priority scenario, but for feeds it seems quite likely people will enable it, use it, and disable it once the data has been imported.

Possible workarounds

Uninstall feeds. However I prefer not, as I'd like to keep the feeds importer config just in case.
Enable feeds, run the update, disable feeds again.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

AdamPS created an issue. See original summary.

Eric_A’s picture

In general modules *must* be enabled before updating. So not so much a workaround, it's more of a requirement.

Not sure where or if this is documented for Drupal 7, but the brokenness of disabled modules was fixed for Drupal 8 by removing the entire concept: #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed.

MegaChriz’s picture

Okay, so basically the error message should be changed and say "Please enable Feeds to run this update."?

AdamPS’s picture

Thanks for the responses.

#3 sounds like a good plan. I guess it is possible that people also hit the error because they need to rebuild the registry so perhaps could try to preserve both alternatives in the error message?

MegaChriz’s picture

@AdamPS
Having both the rebuild registry message and enable Feeds message sounds good to me. Maybe the "enable Feeds" module should be conditionial: only show that message if Feeds is actually disabled.

I see that the performance of feeds_update_7213() could also be improved. In there, Feeds is trying to perform a registry rebuild if the function 'registry_rebuild' is available. It doesn't need to do that if the class 'FeedsHTTPCache' is already available. That could be fixed in this issue as well.

Do you want to create a patch for this, AdamPS?

AdamPS’s picture

I'm afraid that I don't have time to create a patch at the moment.

If you don't either, then I propose that a reasonable fallback is to add a clear warning to the release note.

MegaChriz’s picture

Title: FeedsHTTPCache class could not be found: 7.x-2.0-beta4 broken if feeds is disabled but not yet uninstalled » FeedsHTTPCache class could not be found: 7.x-2.0-beta4 database update can only run if Feeds is enabled

I've added a note to the release notes. :)

MegaChriz’s picture

Status: Active » Needs review
FileSize
713 bytes

This adds the warning that the Feeds module must enabled during the database update. I tested it myself on fresh install as follows:

  1. Installed Feeds 7.x-2.0-beta3.
  2. Disabled the Feeds module.
  3. Checked out the latest dev of Feeds with the attached patch enabled.
  4. Tried to perform database updates through drush:
    drush updatedb
    > Feeds  7213  Set cache class for Feeds HTTP cache.
    > Do you wish to run all pending updates? (y/n):
    y
    > Please enable the Feeds module to perform this update. [error]
sonnykt’s picture

Patch #8 does not fix the issue still. If Feeds is disabled, all subsequent database updates will display the above error. It may cause issues with automated deployment system such as CI. I suggest to only enable the cache class when the module is enabled in feeds_update_7213(), and add an extra call in the hook_enable.

MegaChriz’s picture

@sonnykt
Nice suggestion, but then the cache class gets set each time that you enable Feeds. So if you've overridden the cache class, your override will be removed upon (re)enabling Feeds.

  • MegaChriz committed b011ee3 on 7.x-2.x
    Issue #2911711 by MegaChriz: Inform the user Feeds must be enabled in...
MegaChriz’s picture

Status: Needs review » Fixed

I've committed the patch from #8 instead of the patch posted in #9.

Status: Fixed » Closed (fixed)

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