Posted by killes@www.drop.org on September 14, 2009 at 11:50am
| Project: | FeedAPI |
| Version: | 6.x-1.x-dev |
| Component: | Code feedapi (core module) |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
feedapi_enabled_type is called in the .install file, but defined in the .module.
Comments
#1
Patch is attached. However i'm not glad about querying serialized data from variables table. Any better way?
This is a regression of #455688: Make refresh rate of feeds configurable
#2
Calling feedapi_enabled_type() should be fine in hook_update_N() - killes, can you describe better the problem that has occurred?
#3
The error reported is:
Fatal error: Call to undefined function feedapi_enabled_type() in /drupalroot/sites/all/modules/feedapi/feedapi.install on line 250
This patch seems to address that error but then it comes back in update 6107 which calls the same undefined function.
#4
Looking at this further it seems to happen only on sites that have FeedAPI disabled, but haven't had FeedAPI uninstalled. At least on several sites in a multi-site install I've been working with. The modules directory is the same for all sites to the same code is present but only a problem on updating those sites have disabled feedapi
#5
#4: Just learned something new. I see now that the update system tries to update all modules that are available and have a schema record in system, not just enabled modules.
This means we can't use any module API functions in our updates.
Needs fixing.
#6
you can use module_list() and it's force list parameter to add it if need be.
outside of modifying core, it's pretty much your only real option.
#7
What about using drupal_load() to load your module? ;)
#8
Is that an intended behavior? Should it be running updates on modules that are not enabled?
#9
You may never ever call your module functions or APIs anyway, because they may change over time, thereby breaking the upgrade path.
#10
#9: that's a good point.
I just tested using drupal_load() on systems where feedapi is present but not enabled. It works. Attaching the patch as a stop gap.
Otherwise I agree with Wim that we shouldn't use the module's APIs so as to not break upgrade paths when if it changes.
#11
I can get this error when using drush to update the feedapi module, and then calling drush 'updatedb'.
Fatal error: Call to undefined function feedapi_enabled_type() in /var/www/html/drupal-6-sites/all/modules/feedapi/feedapi.install on line 237#12
This still breaks upgrades for anyone coming from Drupal 5. Unless the changes can easily be done at a level closer to the database, one way around the API limitation is simply to place clones of the called function stack in the install file - (e.g. "feedapi_update_6106_feedapi_enabled_type") - verbose, but it does the job.