Closed (fixed)
Project:
Features
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
26 Jun 2012 at 15:19 UTC
Updated:
5 Jun 2013 at 21:05 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
smk-ka commentedLuckily, there is an easy way to avoid this behavior by providing a
$replacement_style_nametoimage_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.
Comment #2
goldenboy commentedI've got the same problem and this patch works for me.
That was the scenario:
feature_xyz) with a content type namedxyz.xyzhas an image field (field_xyz_image) with a custom image style associated (xyz_medium).feature_xyzin a fresh drupal installation. Everything gone ok.xyz.drush features-export ...the changes.drush fr -y --force feature_xyzon the new drupal installation.drush fd feature_xyzshowd nothing.drush cc alldrush fd feature_xyzshowd the absence of image stylexyz_mediumforfield_xyz_image.Comment #3
hefox commentedWhy are we calling delete?
http://api.drupal.org/api/drupal/modules!image!image.module/function/ima...
Comment #4
smk-ka commentedHrm, good question?
Comment #5
vbreak commentedEncountered 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"
Comment #6
ghankstef commentedPlease 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
Comment #7
hefox commentedEven 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.
Comment #8
pfrenssenAdding tag as per #7.
Comment #9
yannickoo#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.
Comment #10
mpotter commentedI 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.
Comment #12
pfrenssenI 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.
Comment #13
bradjones1@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.
Comment #14
crystaldawn commented@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
Comment #15
larowlanFor those coming here and seeing fixed, note this fix *isn't* in features 1.0.