Imagefield module gets disabled on upgrade, or unexpectedly on running cron

ImageField does not automatically disable itself on it's own accord. It doesn't even implement hook_cron(), so it's definitely not doing anything during cron runs. I'd check other modules that you have enabled. Make sure that you've updated FileField to version 3.0 also, as ImageField will not run properly with earlier versions.

Something I have seen happen before is the database becoming unavailable in the middle of a request, so the module code is loaded but the database isn't available. This could make it possible that ImageField checks for FileField, but because the database isn't available, it looks like FileField isn't available and it disables itself in imagefield_init(). But I'm just guessing there, I've never seen ImageField disabling itself personally or heard any other similar reports.

Closing after inability to reproduce or confirm. Please reopen if this problem still exists.

This is happening to me. I'm running Drupal 6.15, FileField 3.2 and ImageField 3.2.

I can tell this is related to the cron because if I disable the cron, the problem doesn't happen anymore. I do need the cron to run though. My site is getting indexed by Apache Solr.

*EDIT*
Oh, and one more thing, I tried commenting out the module_disable function call in the ImageField module and it still deactivates.

I'll need to know how to reproduce this problem from a fresh Drupal install to investigate it further.

Marked duplicates.
#791822: Update from 6.x-3.2 to 6.x-3.3 deactivates imagefield, filefield and videofield
#791320: ImageField disables itself after latest update

I have the same issue that occurred on the update 3.3. The module was disabled after the update.
I am running latest Drupal build

Same issue with update 3.3 issue as well. Mod was disabled - had to enable.

I did update a couple other mods as well - devel, imageapi, filefield.

And added new ones - url_alter and domain.

Not sure if it was one of those or what.

subscribe

The module disabling itself upon upgrade to the most recent version, as described in the recent comments and in the two issues marked as duplicates, seems different than the module unexpectedly disabling itself over its lifetime, somehow being tied to when cron runs. It seems like perhaps one of those duplicates should be brought back, as this seems like it would be a different problem.

That said, I'm experiencing the upgrade-disabling issue as well. What additional information do we need to diagnose this problem? I, like the others, upgraded filefield and imagefield from 6.x-3.2 to 6.x-3.3.

Could it be related to #455368: Views field format lost after update that was included in the last update?

This seems like a pretty critical error -- upgrading to the newest version disables it on a site (some, at least). I hope you don't mind me increasing the priority on this one.

Updated the title to try to capture both issues going on.

Hi,

I've never had this module disable itself before and my installation is even running on a VPS that sometimes becomes unresponsive due to something running away on the physical server. After the most recent upgrade, this module and FileField looks to have disabled themselves.

imagefield 3.2 to 3.3 (views 2.10), imagefield module is deactivated (disabled) and it cant be activated back (!)

(manual database module status activation field edit from 0 to 1, activates it but it doesnt work, views Broken/missing handler....)

downgrading to 3.2: you have to manually activate in database (status field in system table), then deactivate and reactivate module as usual in modules page
images are back, views ok
subscribe

Did you check FileField? That got disabled too. I re-enabled both FileField and ImageField with no problems.

Same issue here, filefield is enabled. I cannot re-enable imagefield. Imagefiled 6.x-3.3 Views 6.x-3.0-alpha3 CCK 6.x-3.x-dev

Updated 2 sites with the same views, cck versions. One upgraded fine and the other I cannot re-enable imagefield.

Additional Information:
I have several drupal sites and all use filefield and imagefield. I have updated from 3.2 to 3.3 on three of them. On two no problems, however after the update, imagefield could be enabled/disabled from admin/build/modules on one but not on the other - both imagefiled and filefield are greyed out (enabled) on it.

The third site also had filefield and imagefield greyed out and enabled after the update. No images appearing. When you go to a content type that has an image field, the field is missing. If you try to add it back, the option to select image as the file type is there. Which it would not be if it was not enabled??? Clicking "save" results in this message:

* This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled.
* Add new field: the field name field_image already exists.

Tried disabling and re-enabling in the database. No change.

Pulled a copy to experiment on locally. I reverted to 3.2 - still greyed out. Still not working.

I also had the emfield module installed, I cannot disable it in admin/build/modules either. Thinking a conflict might be the problem, I removed the module folder for emfiled, disabled imagefield and filefield in the database, ran update.php, enabled imagefield and filefield in the database. Drupal now sees the modules as enabled and my images are back, I am at 3.2, but working correctly.

I repeated the same proceedure on the live site and did not get the modules enabled or the images back.

Remote:
Drupal 6.16
Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5 DAV/2
Php 5.2.11
MySQL 5.0.67
filefield 6.x 3.2 to 6.x 3.3
imagefield 6.x 3.2 to 6.x 3.3
cck 6.x-3.x-dev

Local:
Drupal 6.16
Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch
php 5.2.6-1+lenny6
mysql 5.1.41
filefield 6.x 3.2 to 6.x 3.3
imagefield 6.x 3.2 to 6.x 3.3
cck 6.x-3.x-dev

Any suggestions would be appreciated.

A note to anyone having this problem: The reason you cannot turn on ImageField module is because another module is depending on it. If you turn OFF all the modules that depend on ImageField, then you can turn ImageField back on. Drupal is intending to make it impossible to turn off a module that has dependencies enabled, but it's actually doing the opposite here. Another option is simply setting status = 1 in the "system" database table for the imagefield row.

I still don't know exactly what causes this problem, and as has been noted by several users, it's an inconsistent problem.

Hello, We have a similar problem.

But we haver realise that not only doesn't work, also the update delete the field from the node-type.
We have restored the 2.x version an also we have restored one back up of the database, but seems to be really weird this problem.

Oskar

same problem...

this is what I get in views after updating...

Relationships
Broken/missing handler: node > image_files

Fields
Broken/missing handler: image > nid

I tried disabling in phpmyadmin/system both filefield and imagefield... then enabling them again. no luck.

I hope this helps troubleshoot...

thanks!

Same problem here. I performed an update using drush and I received the following error message:
module imagefield is incompatible with this release[warning] of Drupal
I had to install the previous version 6.x-3.2

Regards,
Marco

Did this fix it? I reverted to 3.2 also, but everything is still broken. views_slideshow in particular.

yikes. this is on a live site! bad, admin, bad.

bredi

I can confirm the problem with views slideshow. In my case, on one of my websites, after upgrading imagefield and filefield, the slideshow worked properly but shows a broken handler. when I upgraded views slideshow to 2.1 the slideshow was also broken. I had to go back to 2.0.

I upgraded imagefiled and filefield on several sites that had no problems at all.

When upgrading drupal core from 5.x to 6.16, all images using imagefield were gone. I had used a content type that had a fieldgroup to group the image and caption. I found that after removing the fieldgroup, the images were displaying again.

I am having this issue also.

Upgraded filefield, views and cck and imagefield disabled itself and would not let me enable it. I enabled it manually which got rid of the error messages I was getting.

I tried the above solutions but nothing has worked. No images are displaying in any of my views on my site.

Subscribed

Same workaround than yours, I fixed it upgrading to FileField 3.5, and as #15 points out, disabling first imagefield depending modules.
Then it re-enabled itself, and I enabled again depending modules (ImageCrop in my case).

subscribe

Just something to check if you use ImageCache/ImageAPI, I noticed recently that ImageAPI GD2 was mysteriously disabled on my installation too.

Problem: After upgrading filefield 3.3 -> 3.5 imagefield is deactivated, imagefield images missing from content types. I also upgraded cck 2.6 -> 2.7 and views 2.10 -> 2.11, but re-updating fieldfield a second time caused imagefield to deactivate a second time. After reactivating imagefield images returned to content types.

This only happened on my remote server, Apache/linux. Prior to updating the live site I tested the upgrade on the local copy (apache/win) without this problem appearing.

I have no modules dependent on imagefield.

Thanks

Suscribing... I have the same problem.

Updated to the latest version of CCK, FileField and ImageField on my local host and didn't get any problem.

But on the production website, the same update makes it impossible to enable again the ImageField module (although I got no problems during the upgrade process), the checkbox is disabled... which makes all image fields to disappear on the web pages...

Finally I could fix the problem by disabling the "ImageField tokens" module and enabling it back. When disabling this module, the ImageField module checkbox got enabled.

So for those who haven't tried yet, disable all your modules depending on the ImageField module and see if it can helps.

@quicksketch - What do you think of removing the call to module_disable() in imagefield_init(), so this doesn't impact so many people who are simply doing routine upgrades? Seems to me that this is kind of a brute force action that ought to be handled more gracefully.

In comment 4 of #611514: After upgrading filefield to 6.x-3.2 imagefield module disappeared?, you wrote that this issue traces back to a time when imagefield didn't have filefield as a dependency, so you HAD to force imagefield to be disabled in case users installed it alone. But now that the dependencies are set up right, do we really still need to force imagefield to be disabled in this scenario? Seems like it's punishing good users for doing a legitimate update of filefield, and only protects users who foolishly delete filefield module without disabling it (and modules that depend on it).

But now that the dependencies are set up right, do we really still need to force imagefield to be disabled in this scenario?

Dependencies still aren't set up right when working with install profiles or upgrades from D5 to D6 unfortunately. However I completely agree, I think that we're suffering much more from ImageField disabling itself than people having a minor inconvenience when building install profiles or upgrading from D5.

We've already got to make a few fixes to catch up with the FileField 3.5 release, since I like to keep ImageField and FileField on the same version number anyway.

I've rolled back the patch from #430866: Update error when filefield was not previously used and used the originally suggested (and much less destructive) approach recommended by KarenS. The next version of ImageField will be 3.6 to match the FileField releases.

Just updated to imagefield 3.7, am experiencing the same as described above;
- all images disappears from nodes
- module is inactive in modules list
- impossible to re-activate imagefield from modules-list.

I just updated to imagefield 3.7, an i am experiencing the same as described here.

#15 the workaround from quicksketch works fine in my case.

I turned off all the modules that depend on ImageField, than Imagefield enabled automatically and all works like expected. In my case I it was only one module to disable - Imagefield Tokens.

I'm having the same issue, which causes images to disappear site-wide. it happened for me after an upgrade to 3.9 from 3.7. Images do no show, and in a view that integrates them I get the error: 'You must select "url" as the imagecache handler for the "slide_field" field.'

My thanks to the creates of this module; hope someone can chime in with insights. This is a rather critical bug for my site...

The resolution to this, finally, was to go into the Views that used the CCK imagefield (in my case, Gallerific), and change the format of the relevant fields. You might just have to change yours then change them back.

In some hindsight o posting here, I'm sorry if my final problem resolution wasn't specifically about imagefield (perhaps), but if others have the issue then they may wind up here, too. Hope this helps someone else.

Same problem updating to 3.9.

Just had to re-enable the mod.

I have just encountered this problem when moving a Drupal install from one server to another. The issue I had was that Imagefield was enabled but Filefield wasn't, and was greyed out in the module list. As a result, the Imagefield module was throwing up errors because of its dependancy on Filefield.

The great advice in comment #15 worked for me though, in that I disabled the modules which were dependant on Filefield (in my case, just Filefield Sources) and then the Filefield module itself became renabled autmoatically. I was then able to re-enable Filefield sources and everything is fine now.

Thanks ot all involved in this thread for their advice and suggestions.