All image styles set in fields are replaced with an empty string when reverting a feature. This happens because a feature-revert triggers a subsequent image_style_delete(), which causes image_image_style_delete() (i.e., hook_image_style_delete()) to tamper with the field settings.

Comments

smk-ka’s picture

Status: Active » Needs review
StatusFileSize
new901 bytes

Luckily, there is an easy way to avoid this behavior by providing a $replacement_style_name to image_style_delete() that is identical to the original style name.

Additionally, this patch fixes feature-revert processing always all existing features instead of only the currently processed one, and limits reverting to image styles not in code or in overridden state.

goldenboy’s picture

I've got the same problem and this patch works for me.

That was the scenario:

  1. I've got a feature (feature_xyz) with a content type named xyz.
  2. xyz has an image field (field_xyz_image) with a custom image style associated (xyz_medium).
  3. Everything is correctly exported into the feature with all the needed dependencies.
  4. I installed feature_xyz in a fresh drupal installation. Everything gone ok.
  5. I added some changes into the content type xyz.
  6. drush features-export ... the changes.
  7. drush fr -y --force feature_xyz on the new drupal installation.
  8. drush fd feature_xyz showd nothing.
  9. drush cc all
  10. drush fd feature_xyz showd the absence of image style xyz_medium for field_xyz_image.
hefox’s picture

Status: Needs review » Needs work
smk-ka’s picture

Status: Needs work » Needs review
StatusFileSize
new772 bytes

Hrm, good question?

vbreak’s picture

Encountered the problem here as well.
When reverting the custom featured module, It always shows up as overridden,
Image Styles on Fields seems overridden in "manage display"

ghankstef’s picture

Status: Needs review » Postponed (maintainer needs more info)

Please provide more information on how to replicate the problem.

Specifically, which version of Drupal core and features are being used and very detailed steps to replicate the problem. I am unable to replicate the problem with the sparse descriptions above.

Attached is the make file and the feature I created with custom image styles. The feature is patching.tar and the make file is patching.make.tar

hefox’s picture

Status: Postponed (maintainer needs more info) » Needs review

Even if can't replicate the problem, that we're calling delete instead of revert function strikes me as a definite bug so don't think this should be at postponed status.

Would be nice to have some tests added.

pfrenssen’s picture

Issue tags: +Needs tests

Adding tag as per #7.

yannickoo’s picture

#1 works for me, thank you so much! It was such a pain because every time I got the original image instead of the image styled image.

mpotter’s picture

Status: Needs review » Fixed

I was able to reproduce this problem and the patch in #4 worked great. The key to triggering the problem was do use a --force on the initial "drush fr" to cause the image style to get dropped. Nice catch everybody!

Committed to 4de06df.

Status: Fixed » Closed (fixed)

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

pfrenssen’s picture

I have this patch applied and am experiencing problems with reverting features that contain a new image component. The image style is not created when the feature is reverted.

bradjones1’s picture

@pfrenssen - that's a different issue from this one... as of now I don't see a ticket for that particular issue, but if you create a blank image style with the same name as the one you're trying to create, then revert, it will configure as you'd expect.

crystaldawn’s picture

@13 Brad you seem to know about the issue where new image styles are not brought in with reverting and know about the workaround. It would have been nice to create an issue for a known problem dont you think? I've taken the 5 seconds it takes to create an issue for this problem here:

https://drupal.org/node/2148453

larowlan’s picture

For those coming here and seeing fixed, note this fix *isn't* in features 1.0.