Imagefield widget upgrades aren't working

I updated CCK today and had the same problem as well. spent all day yesterday uploading images to nodes, and now they are all gone! The files for images are still in the file folder, but the nodes don't seem to show them. however if I go into edit mode it still shows me thumbnail that something was uploaded

I think this is because the widget got renamed from 'imagefield' in the D5 version to 'imagefield_widget' in the D6 version. The upgrades do not rename fields to use the new widget name, so they are 'lost' (still in the database but not showing up in the field).

I think you either need an update to rename the widget in content_field_instance to match the new definition, or change hook_widget_info() definition to use the original name.

There are other updates that are manipulating widgets with the original name, none of the updates seem to refer to the new widget name.

Plus after all the renaming, you'll need to run content_associate_fields('imagefield') because with the widget name change the database fields would not have gotten updated. You can see an example of this in text.install since the text module renamed a widget.

So the main question is whether you want to use the new widget name or the old widget name, then we can update accordingly.

Actually this is a bug report, and critical, because it makes upgraded fields unusable.

Looking at this more, I see there is an update that is trying to rename the widget to 'imagefield_widget_default', but there are a couple problems with that. First, that still doesn't match the widget name in hook_widget_info().

Second, it isn't necessarily getting triggered at all because you use content_fields() to interate through the fields and it isn't safe to use that in the install file any more because in D6 *all* updates get run, even when modules are disabled. So if you have the imagefield code in the modules folder but haven't enabled this module yet (like if you're enabling one module at a time to be sure everything is working), the imagefield info will not be in content_fields() and that update is marked as completed without anything actually happening.

CCK updates in D6 have been a nightmare because we can't use any of the content functions safely since not all modules are necessarily enabled, so we created the content_types_install() function (in content.install) as a 'safe' way of getting field info in install files. So you'll need to use that in the install file. For the same reason, I'm not sure content_field_instance_update() will work reliably in the install file, you may have to manually update the database to be sure it works right.

I'm still confused about what name you actually want to use as the widget type, though.

Plus you need to add the test to be sure that the Content module update 6000 has run before you do anything else or the code will be trying to update database columns that don't exist yet.

I take it back, you can't use content_types_install() for this purpose because that won't find disabled modules and you need an update even when disabled.

Actually, the easiest fix might be to add a test whether the module is enabled and if not just #abort. Then you could safely use the regular functions to do the update.

Related: #286474: D5 to D6 Update path

Bump. This is critical because anyone who has imagefield modules in the CCK folder during their upgrade ends up with a screwed up database.

See http://drupal.org/node/304813#comment-1025832 for the latest recommendations for updates of CCK modules.

After carefully following the latest upgrade procedures (from the CCK project page) I was able to successfully preserve all of my Imagefield 5.x images.

The images did not show up until, for each content type & imagefield I went into the administrative settings and reset all of the filepaths which were blank after the update. (This was not straightforward either, I had too click the "Change basic information" button and then submit the following form, just to get the path fieldset to even display at all, when it did display, the previous paths were wiped.)

I also had to wipe my imagecache presets and rebuild them.

After these steps, the images appear correctly everywhere.... except the admin edit form where the imagefield upload widgets show up missing their thumbnails.

As far as I can tell, Imagefield 6.x-x creates its own independent thumbnails now, (in the past it would just optically scale down the originals). The new thumbnails are created in the same directory as the original :/ and have 'thumb.jpg' appended to the filename.

http://example.com/sites/example.com/files/images/my-image.jpg.thumb.jpg

Newly uploaded images get the new thumbnails upon upload. All the images previously created with Imagefield 5.x do not have these thumbnails, but the admin form looks for them anyway.

I was able to get the widget update to work after much finesse. The trick for me was to set the widget_active flag to 1 in {content_node_field_instance}, for widgets of type "image", delete the field, recreate the field, the recreate failed, but then recreate it again, and then all the existing images were magically there!

I may have found the bugs that make imagefields not upgrade properly, but I'm not 100% confident my fix is correct. Patch attached, with explanatory comments.

Last time I checked this bug was still valid, so bumping version. I'll do my best to review this and test it on a real D5 site tomorrow.

subscribing

I'm a drupal newbie and I have the same problem : http://drupal.org/node/332692

Maybe, it will be usefull to explain this problem to CCK users who are upgrading from CCK 6.x-2.0-rc10 to CCK 6.x 2.0 with a text in red on the CCK module download page !

@bjaspan, #13:
Thanks for this patch. I only read this issue after I had unsuccessfully tried to upgrade, and my imagefields didn't work anymore. I took these two lines from the patch:

<?php>
db_query("UPDATE {". content_instance_tablename() ."} SET widget_type = 'imagefield_widget' WHERE widget_type = 'image'");
content_notify('enable', 'imagefield');
?>

and run them in the execute-php-block from the devel module. Now my image fields are back in business again. I only have an error message left in Views, but I believe this is not related.

The solution described in +17 (mostly) worked for me, so thanks for that! I still had to go in and out of every content type to resave the widget, but after that it worked.

#17 did the trick for me. Kudos

• Temporarily disabled caching and aggregation via /admin/settings/performance and "Save Configuration.
• Edited an existing node, changed the body field's input format to "PHP Code" and pasted in the code from #17 and Saved, which displayed and executed that code. You might want to press refresh (F5) for good measure.
• Edited the node and removed #17 PHP code from the node's body, since it only needs to run one time.
• Not sure if it was necessary, but visited and saved each content type as suggested in #18, and "Clear the cache" button on /admin/settings/performance

Drupal 5.12 to 6.6, CCK 2.1, Imagefield 6.x-3.0-alpha2

Tested this on a site with two imagefields (and several thousand instances), was originally a 4.7 site. Since it's been verified to work by a few people now, bumping to rtbc

Thanks guys. I definitely had to clear my cache after running the PHP code, but I didn't have to save the content types.

But then I noticed that I was having problems with a filefield field type. I dug through my database, looking at content_node_field and content_node_field_instance and noticed that "active" was set to 0. I changed the value to 1 and then reset my cache and it worked.

I have an alternate patch in #336259: Imagefield widget upgrades aren't working (more complete patch) that solves #11, #18 and #21. However, your #5, Karen, makes me think my patch still needs a bit work before being fully upgradeproof.

guillaume, I've marked the newer issue as duplicate #336259: Imagefield widget upgrades aren't working (more complete patch) - please re-attach your patch to this issue so things can be tracked in one place.

OK, here we go.

First, big warning: as of 11/19, this patch is not the RTBC one. See #13 and #17 for this matter.

Now my new patch:

+ preserves storage base path "filepath" (imagefield will find images, where you stored them on D5)
+ creates full imagefield_widget (no need to reedit them)
+ calls what should reactivate the widget once the update went well
- heavily relies on CCK being there. Some conservative tests should be made before each function, to test for its capability to answer as intended.
- relies on imagefield_widget form being able to create forms (to get default values). It worked on my site, but I suspect multiple tries to update resulted in my database being in a not-so-pure-5.x-without-any-update state. Thus perhaps when someone tries to run the update on a really fresh 5.x install, the form will be empty (or crashy); I don't know the Drupal upgrade process enough to tell if forms are able to generate as soon as imagefield.install is running.

(hmm, so previewing made the attachment disappear. Good to know)

So. Based on guillaume's patch in #25 and another look at the code and my own patch (#13), I am now not confident that my patch is right (even though it seems to work). I also think guillaume's patch is wrong, and also that the current code in imagefield.install is seriously borked. I'm setting this issue back to CNW.

Details:

1. My patch is wrong because it just whacks all 'image' widget names to be 'imagefield_widget' and re-associates fields. This makes content_fields() return all the image fields so be updated. This does seem to work, but see point 3 below.

2. guillaume's patch adds update_6002() which does some work to change 'image' widget settings into 'imagefield_widget' settings. It looks to like that those steps are already handled in update_6001() *if* my patch is applied, so maybe he wrote his patch to work based on 6001's current behavior (which is "do nothing" without my patch) and so ended up duplicating the code.

3. I also noticed that update_6001() attempts to use the batch API to run the functions _imagefield_update_6102_move_operation() and _imagefield_update_6102_drop_operation(). However, those functions do not exist, though _imagefield_update_6001_move_operation() and _imagefield_update_6001_drop_operation(). Thus, I think these functions are never getting called. Someone (dopry?) bothered to write them so I figure they are probably doing something important, though I haven't taken the time to figure it out.

dopry gave me permission to commit my reviewed patch in #13, but given item 3 above and the differences in guillaume's patch I suspect what I would end up committing is different enough from #13 that it would need another review first. For today, I'm punting.

You're right, 6001 already had the code. I hadn't even looked at it.

My code added some widget fields based on the forms gathered in current filefield and imagefield (takes the default values provided by those forms, that ensures converted images have all imagefield_widget fields). It then completes with whatever fields it finds in the old image widget, and renames some fields (image_path to file_path). Then it writes back the whole modified thing to DB. I think this "fill the form" mechanism could be integrated in the actual patch (before computing 'multiple', which I had not ported, and changing 'image_path' to 'file_path', which I had).

For the content_fields(), that your patch has to fool: couldn't it be replaced by what I use in my patch:
content_field_instance_read(array('widget_type' => 'image'), TRUE)
as of D6.6, when I tried it, it has the same return type as content_fields, that is, fields with a ['widget'] in it, so it seems safer and still compatible.

Regarding imagefield_widget_default: why not imagefield_widget?

Thanks for all who patched and shared -- any final updates? I am having this prob after upgrade to D6 from 5. Thanks.

Hi there,

What are plans for this module?

This one module makes upgrade from D5 pointless:

- with the patches above there is no edit preview, custom alt and title fields are empty,
- without them - I'm losing hundreds of pictures from D5.

Please let us know, please help us :]

... and thank you for your work... :]

Szy.

Anyone who has upgraded to Drupal 6 only to find that your imagefield admin thumbnails are not working, add the following function to your theme's template.php file.

function phptemplate_imagefield_admin_thumbnail($item = null) {
  if (is_null($item) || empty($item['filepath'])) {
    return '<!-- link to default admin thumb -->';
  }
  $thumb_path = imagefield_file_admin_thumb_path($item);
  return '<img class="imagefield-admin-thumb" width="150" src="'. file_create_url($item['filepath']) .'" />';
}

It will basically tell the form to use the actual file instead of the lame .thumb.jpg. This is exactly how it was handled in D5, and IMO should still be this way. Anyway. No patches, no hacks, portable, gets the job done, welcome to D6.

Note: The width="150" is only there to keep the image from taking over the form. It can be safely removed in favor of declaring a width on img.imagefield-admin-thumb in your stylesheet.

this is not work for me

i try

imagefield-6.x-3.0-alpha1

and

imagefield-6.x-3.0-alpha2

file is exist and displaying on the node page, but lame thumb file not displaying!

help!

This is the first working update path I know of.

The update process is in two parts:

1. Update the widget definition
  - first change the name of the widget from 'image' to 'imagefield_widget'
  - run content_associate_fields('imagefield')
  - then, for each field instance:
    - migrate 'max_number_images' to 'multiple' (was severely broken, fixed it)
    - update formatter name
    - call content_field_instance_update($field);

2. Migrate the old schema to the new one (batch operation)
  - for each field (not field instance)
    - for each row in that field
      - migrate 'title' and 'alt' to 'data'
      - create the thumbnail

After a quick test, this appears to be working. Rerolled to fix a broken 'case' statement -- the 'default' case must always go last.

Needs further testing/review.

+          case 'default':
+            $field['display_settings'][$context]['formatter'] = 'image_plain';
+            break;

Either there is a mistake here, and this should be default: instead of case 'default':, or it's just testing for a string value of 'default', and I don't see why that test should be last.

You're right -- I was thinking it was simply "default:".

I assumed that was the problem since the original display settings still aren't migrating fully. Images with display values of 'Default' end up set to 'Generic files' rather than 'Image'.

I guess it should either be "default:" or "case 'imagefield_default':"

Great!! I have also tested this patch and it has repaired by completely broken db regarding imagefield (well, after my many tests and changes with the original imagefield.install, so it was not strange the db ended broken.. :-)). But just removing unneeded columns added to node types tables (?¿) and just restoring the previous (5.x) imagefield table did the magic...

This version of the file is much, much better, and I think it accomplishes what autor's module was trying to do when he started to write the update functions... So thank you very much for your work, Damien!!

pedropablo's review aside it seems like the 'default' at least needs some work.

This is going to be pretty detailed, but I want to be sure I used the right workflow for implementing this fix. Unfortunately, the patch did not work for me.

Here is my workflow. Note I recently upgrade to Drupal 6, being carefull to follow the recommendations for upgrading CCK:

1. Replaced the 6.x-3.0-alpha2 version with the 6.x-3.x-dev that was released on Dec. 15.
2. downloaded webernet's patch (released on Dec. 13th) into the imagefield module directory and ran the patch command: patch < 26195-Imagefield_6_update.patch
3. Reactivate the imagefield module on the module page
4. Ran update.php The selected version for the imagefield module was 6002
5. The upgrade ran with no stranger errors, and the following message at its conclusion

The following queries were executed
imagefield module
Update #6002

* No queries

After the upgrade, I still had not restored the imagefield images that were on my blog, and I was getting the following message in my blog content type (see attached screenshot)

worked for me!

I just tried this with the most recent patch, and it got my images moved over. The formatter was not properly set for image_plain, but that was easily solved by resaving my display settings. I tried the update with both versions of the default switch from above and neither worked, and because I'm using imagecache for everything but one default display, I really can't tell if any of the formatter translations are working. But it did get the site working.

Perhaps I had no success because I patched the wrong version (athought the patch applied just fine to the Dec. 15, 6.x-3.x-dev version).

Would anyone who has had success with this, please post weather they used "webernet" version or Damiens version of this patch?

And exactly what version of the module was the patch applied to?

I used version from comment #33 on version 1.16 of install file

Thank you for the clarification on the versions. I repeated the process of updating but I am still not getting the images. And I get the following message on the "Manage fields" page of the content type:

* post_image (field_post_image) is an inactive Image field that uses a image widget.

This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled.

Perhaps it is not working because I am missing a step?:

1. deactivate the imagefield module
2. download the patch into the imagefield module folder and apply the patch
3. reactivate the imagefield module
4. Run update.php making sure to first select the 6002 update for imagefield module dropdown on the "Available updates" page.

Any important steps left out?

Revised patch:
-It looks like it should be [format] not [formatter]
-Uses 'imagefield_default' rather than 'default'

@jeeves - Imagefield 6.x is currently alpha quality - that means 'use at your own risk'. You might be able to get your fields properly migrated by running imagefield updates starting with 6001, but there are no guarantees.

Success with webernet's patch at comment #44!

Thanks for the new patch webernet - the changes you had just made seem to have made the difference for my Drupal install. I had installed earlier versions of the patch with no success. Now everything works, and I did not even need to jigger or reset the imagefield settings.

So the upgrade procedure that worked for me was:

1. I restored my Drupal database back to the point before I started experimenting with various fixes for this problem. That was the point where I had successfully upgraded CCK from the 5x version, and had 6.x-3.0-alpha2 version of imagefield installed (and none of my old images showing up).
2. Swap imagefield 6.x-3.0-alpha2 for imagefield 6.x-3.x-dev (Dec. 15 version) and patch the imagefield.install file with webernet's patch
3. Run update.php

Back to CNR, looks like a cross-post.

Tested webernet's patch #44 with imagefield 6.x-3.x-dev and everything seems to work as it should on my local dev enviroment.

The existing images displays according to the fields settings and on the edit page I get the thumbnails. Creating new nodes with images also works.

My procedure:
* Install Drupal 6 and all modules I need, but *not* any contributet CCK field modules.
* Ran update.php on my Drupal 5 databas.
* Installed CCK field module including imagefield.
* Ran update.php again.

Thanks everyone for working on this. The imagefield is the one thing holding up a move to Drupal 6 for me now.

I upgraded another site, using the Dec-14 dev release of imagefield and the #44 patch, and everything seems to have worked brilliantly! I don't even have to resave the types' display settings...

This was the big thing holding me back too, so thanks everyone.

N.

Tested webernet's patch #44 with imagefield 6.x-3.x-dev and everything seems to work as it should on my local dev enviroment. I've a few thousand images and it took a while to run the update.php also came up with a lot of errors containing

array_merge() [function.array-merge]: Argument #2 is not an array in /home/drupal6/public_html/sites/all/modules/cck/content.install on line 43.

Seems to have worked a treat all images working. I can upgrade to 6.x know. Thanks for the great work

I tried this on a live (but offline) site and got the following error:

An error occurred. http://www.mysite.net/update.php?id=42&op=do <br /> <b>Fatal error</b>: Allowed memory size of 67108864 bytes exhausted (tried to allocate 10848 bytes) in <b>/home/projectu/public_html/includes/image.gd.inc</b> on line <b>190</b><br />

I assume that means I need to enlarge the php memory value, I'll try that out but if this patch does get committed someone should make a note about this.

Interestingly it seems despite giving me that fatal error, everything is now fixed. I still can't get Lightbox 2 to work properly with thumbnails but I don't think that is a related issue.

Ran the patch in #44 against imagefield.install,v 1.16 2008/11/07 with success.

My ImageFields now exist in D6.

I incorporated the patched ImageField Module as a part of the upgrade process.

Upgraded Drupal.
Upgraded CCK.
Installed FileField.
Upgraded ImageField.
Upgraded the rest of my modules.

(running the update.php after each step)

(for an ubercart site, (the standard "product" cck content type)

I did things a little backwards and had to backtrack.

First I install 6.x-3.0-alpha2
Then I had the imagefield issue with it saying "is an inactive Image field that uses a image widget"
So then I upgraded to 6.x-3.x-dev but still no luck.
Then I patched the imagefield.install file with #44 (please note upgrade imagefield.install not imagefield.module)
I ran update.php and it ran 6002 update for imagefield but still no love... :(
THEN I re-ran the update for 6001 on the imagefield module and it re-ran updates 6001 and 6002. It took a while to process the update but it worked!!!

So hopefully that helps someone.

I've also tested webernet's patch #44 and all went well.

Thanks a lot, this was holding all my upgrades to D6.

introfini

i didn't test this but between eyeballing it and it looking good and the positive feedback i went ahead and committed it. it's definitely better than what's there.

so thank you very much to everyone who helped writing and testing the fix.

hi and thanks for such a great mod.

just fyi-
i updated to the latest version-

6.x-3.x-dev 2008-Dec-30

and got some errors, on running the DB update.
specifically-

i had installed imagefield 6.x-3.x-dev from start on drupal 6.8.0
no issues

so i was not upgrading or anything

but the 6002 update was trying to drop the existing columns
for the existing TITLE and ALT fields

for each cck image field

the update didn't seem to let the drops go thru-
but the errors were reported

does this mean anything to you

please advise and thanks again
v

I am getting the same errors while upgrading to alpha3 RE: #56

I'm still having the problem with update 6002. I try to run it, it just hangs there not doing much of anything until it errors out. I get a bunch of errors saying it can't drop certain columns, but that may be because I've run it more than once and it's trying to start from the beginning. But the end result is that update 6002 doesn't complete according to update.php.

i upgraded from drupal 5 to drupal 6 and suddenly my images dissapeared. I re-run update selecting 6001 for imagefield and the appeard again "automagically".

Thanks a lot.

See http://drupal.org/node/327041#comment-5217206