Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
New image styles are not brought into the feature nor are existing image styles updated. It seems all that works properly is exporting and not importing via Enable or Revert. This is a major flaw in regards to Image Styles features capabilities as it makes keeping image styles in code revision impossible.
To reproduce:
1. Create an Image Styles feature with some image styles in it.
2. Enable the feature so that it says "Default"
3. Add a new image style
4. Click Override
5. Select items to revert
6. Click revert
7. Observe that Overridden status still exists.
Comment | File | Size | Author |
---|---|---|---|
#20 | Screen Shot 2016-02-24 at 12.05.27 .png | 88.49 KB | ComboPrime |
#16 | Screen Shot 2015-05-25 at 12.38.47 PM.png | 110.18 KB | RavindraSingh |
#14 | features-2148453-14.patch | 1.31 KB | Dane Powell |
Comments
Comment #1
crystaldawn CreditAttribution: crystaldawn commentedA known workaround for this issue can be found here:
https://drupal.org/comment/7503246#comment-7503246
Comment #2
hefox CreditAttribution: hefox commentedPlease provide more detialed instructions - where are you clicking override? this is in image styles setting? is this a core bug?
Comment #3
crystaldawn CreditAttribution: crystaldawn commentedAdding a new image style will cause the Feature (In the features administration panel where you can see ALL feature modules installed) to display "Overriden" which is correct because something has changed. But if you click override to resolve the issue (remove the change or add the change in most cases involved with importing new changes), you will see that it does not add or remove anything at all and the overriden status does not change because nothing is changed and the features module and site state do not match causing the overriden status to be displayed.
Comment #4
nicobot CreditAttribution: nicobot commentedI can see some issues when reverting image styles that I would like to expose,
1- image_default_style_revert() deletes the image style. I'm not sure why this is the default operation when reverting an image style, and also when reverting some features components through hook_features_revert. My assumption is that it's a mistake to just delete the image style.
2- image_features_revert() is not doing anything when processing new image styles
3- when exporting an image style, the 'ieid' (image effect id) property it's being added as the key of the effects array, and while there is a sanitization process this is not correctly handled.
Example:
In the example the key 43 corresponds to the IEID of the system where the image style was created.
This makes that reverting a feature with image styles remains on overriden status all the time.
I'm attaching a patch based on the assumptions made above. Hope it helps.
Comment #5
nicobot CreditAttribution: nicobot commentedComment #7
Dane Powell CreditAttribution: Dane Powell at Acquia commentedI think deleting the image style via image_default_style_revert() is the desired behavior- that way existing image derivatives will be deleted and regenerated to pick up the new image style settings. When I used the patch in #4 as-is, stale image derivatives always hung around after updating an image style, and I had to manually override/revert the image style to regenerate them.
This patch fixes that.
Comment #9
Dane Powell CreditAttribution: Dane Powell at Acquia commentedNot sure why tests are failing... possibly due to the changes in #2308801: Export less data for image effects (within image styles)
Comment #10
Dane Powell CreditAttribution: Dane Powell at Acquia commentedComment #13
Dane Powell CreditAttribution: Dane Powell at Acquia commentedYeah, looks like this conflicted with #2308801: Export less data for image effects (within image styles). This should fix it.
EDIT: this patch introduces another problem, where every image style is reported as overridden after every revert, due to image_default_style_save being called every time.
Comment #14
Dane Powell CreditAttribution: Dane Powell at Acquia commentedI think we got off to a bad start here... here's a new patch written from the ground up.
The only real problem I see, which this patch addresses, is that Features assumes that if image style storage is not reported as being overridden, it doesn't need to be reverted. This is obviously a bad assumption, because the whole point of Features is that you can push changes to the image styles in code, and the core image module has no mechanism for detecting code changes and marking the image style as overridden. So it's up to Features to check if the file has changed at revert time.
Comment #15
sluceroIn the case where the image style already existed and just needed to be updated the patch from #14 worked great, but when the image style didn't exist yet and needed to be created the revert didn't create it and left the component status as Overridden.
Comment #16
RavindraSingh CreditAttribution: RavindraSingh as a volunteer and at Srijan | A Material+ Company commentedWho all are still facing this issue, please update with latest release 7.x-2.5. I have tested as mentioned and it is not showing me override. attached screenshot is a reference.
Closing this issue, please reopen if you face this issue in different scenario.
Thanks
Ravindra
Comment #17
mpotter CreditAttribution: mpotter commentedAs mentioned in #16, please reopen this if this patch is still needed in the latest version.
Comment #18
marcelovaniI know this issue is closed and will not re-open it.
Just wanted to mention what I found.
The features overrides for Image try to fix the problem with the ieid in image_features_override_component_overrides_alter()
When you try to add an override via UI you will see the key for the effect as [0] but in the database it could be any other value.
I managed to make this work by resetting the keys of the effects, starting the count from 0 on every image exported, i.e.
Will have the keys changed to
This fixes the problem with not being able to override the images, but there is still a problem where if the original image style is changed and a new effect is added, the Features overrides will not detect that change.
The only way to fix that would be to have either a machine_name to be used as keys for each effect or md5 the array of effect and use that as key.
I don't know if that would be the end of the problems, it's just an idea, I haven't spent time to proof it.
Comment #19
2phaI am facing this issue today.
I have a feature which includes a couple of image styles.
The "image styles" display as "overridden" on the feature admin page.
reverting the image styles component on this feature does not add the image styles and they remain as "overridden".
Comment #20
ComboPrime CreditAttribution: ComboPrime commentedI can confirm this issue is still present in 7.x-2.7, although oddly enough only on one of 3 identical servers (works correctly on local and dev, broken on demo).
Note in screenshot that the Image Styles have supposedly been reverted, but still display "Overridden". Checking the actual style confirms that the Feature module update is not being used:
Comment #21
ComboPrime CreditAttribution: ComboPrime commentedUPDATE: Since the Feature wasn't taking, I updated my image style manually. Then on a whim I tried to Revert again--and this time it worked!
No idea what made the difference, or whether this will happen again next time. I'll try to remember to post here again when I have another Image Style Feature update.
Comment #22
ShaneOnABike CreditAttribution: ShaneOnABike commentedSame for me I had this issue. Essentially, the only way to make it work was to create the style and then revert the feature. Can't hte feature just determine if the style doesn't exist and create it?
Comment #23
ashooner CreditAttribution: ashooner commentedI was experiencing this issue, but simply using calling
drush fr --force
with the force flag seemed to work to get the new image styles created, and the feature really reverted.Comment #24
joseph.olstadusing 7.x-2.10+3-dev I came accross this issue.
drush fr image_styles --force -y
did not work either.However, the patch does work!
Patching with patch #14 resolves the issue, after patching the problem goes away.
This applies to the latest dev of features 7.x-2.x
Comment #25
joseph.olstadThanks to @Dane Powel for the patch.
Comment #26
joseph.olstadComment #28
joseph.olstadPatch #14 is my preferred solution.
Comment #29
joseph.olstadComment #30
lamp5#14 works great! Thanks!
Comment #31
joseph.olstadRe-triggered tests on patch #14, it's still good.
Comment #32
joseph.olstadComment #34
joseph.olstad