Features is not allowing export of overridden default image styles

I came across the same problem and found this issue already describing it. I thought it would be easy to solve, but it turned out to be a bit more difficult than I thought. This has to do with the fact that the execution order of the hook_image_default_styles is not easy to change. Thus the styles defined by the exported feature in its hook_image_default_styles may be overwritten by the module that originally defined it. The last (and largest) addition (in the patch file) is to solve that (by also generating a hook_image_styles_alter). Without that it would even be kind of a code clean-up, but now it might be hard to immediately grasp what is going on.

OK, this patch better handles dependencies on contrib modules that define default styles. To test, you can use the linkit module (version 2.x).

Please see the features override module, which aims to handle exporting alters.

Hello, reopening the whole case because I think there was a confusion over what the actual bug is.

Using features & strongarm, a user could normally (or perhaps I misunderstood?) port his own settings for the Drupal's default image styles (aka thumbnail, medium and large), I think the variable is called 'user_picture_style'.

However, a bug occurs when trying to import a feature that has Drupal's default image styles overriden, I get the following message on the image style screen: Warning: array_merge() [function.array-merge]: Argument #1 is not an array in image_styles() (line 512 of www\test_drupal\modules\image\image.module).

Other custom image styles are unaffected and ported correctly.

I'm using

Drupal 7.10
Features 7.x-1.x-dev
Strongarm 7.x-2.0-beta5

I tried using the features override module, but it keeps saying there's no overridden components found, and I think that module's purpose is irrelevant to the current bug.

improved the title

I hadn't had a look yet at the mentioned module, but from the project page I indeed don't get the impression that it solves the problem at hand.

- Setting back to needs review as the patch is still valid then.
- This issue is also about overridden image styles from contrib modules (example: linkit 2.x), so new title may not be that much of an improvement.

Ah I did misinterpret the issue. This is it, then?

Instead of defining a new hook, features should not let exporting of the already defined styles.

There's work on features override forth coming to handle overriding of non-featured controlled default components (at least, I plan to try and get features override to do that), so anything along those lines should be directed over there, and fix the bug that it allows exporting of something already defined here.

Suppose I want my thumbnails to be 200X200 instead of the 180x180 as core defines it. As this now can be considered a "custom defined" image style, I would expect to be able to export it using the features module. In the screenshot below I would expect to be able to export both the overridden thumbnail and custom my_thumbnail:

I agree with Fiet, I don't see why the user should be unable to feature his own settings of the default image styles.

Also when I look at the feature override front page:

Features Override is used by modules that provide features to selectively enhance other features. You may want to use it if:

• You are installing a feature module that requires this module.
• You have a site built on features - e.g., an Open Atrium or Managing News site - and you want to make changes without losing them when you upgrade to a new version.
• You are a feature developer looking to selectively override components (Views, content types, etc.) of existing features and export just the changes to code.

I don't see why we shouldn't keep this module the way it is now, i.e. an external solution made to edit features?

==============

@fietserwin
Patch #2 works fine with Drupal's default image styles, I haven't tested it with contrib module though, working on it right now

edit: Patch #2 works with linkit's default image style too, but i've noticed an incorrect behavior: the site still display 'default' under the modified image styles, I think it would be best if 'overriden' was shown under the modified image styles after the activation of the feature.

In the target site it is "default" as it is now defined by the module generated by the feature module, so it is not user overridden anymore...

Sure but it looks a bit confusing to me, even though I understand the logic.

In fact it's no biggie, if this works as designed then I would recommend applying the patch to the current dev?

Exporting of *changes* in a exportable is features override's area.

If you enabled blog module, would you expect to be able to export the blog content type already defined there? Now you got two competing definitions!

I haven't looked into it yet, but it does sound like there's a valid bug where features is allowing export of these already defined styles. Not being able to export changes to a default exportable is not a bug.

I may be missing some terminology specific to the features module, but I am confused by hefox's comments to the question/problem at hand.

- Features is currently not allowing export of styles already defined by some module (be it the core image module or a contrib one).
- If such a style is overridden, I would expect to be able to export it using features, just like I can export custom defined styles.
- Competing definitions can always occur. If I define a custom my_thumbnail style and export it to a site where also a custom style my_thumbnail has been defined, we are also in a situation of competing definitions.
- And yes, if I would modify the blog type, I would like to be able to export that to another site.
- As I can export the by core defined filter full html/filtered html, ...

- If you call a blog type or an image style an exportable and say that "feature override" handles the export of (changes to) exportables that are defined by core (or contrib) than I think I may start to understand you.

But then, I think that features override should be an integral part of features. Why would I be able to export the core defined but overridden full html filter but not the core define but overridden thumbnail image style?

The default install profile inserts the filtered html, etc. formats into the database -- you can have a different install profile and won't have them, thus you can have a site without them so would need to export them yourself to insure they are there.

Image always has the styles provided via it's default hook; can't use image module without image defining them.

You can make a module that defines hook_permissions() {return array('access content' => ...)} also, and that'll produce conflicts, just like having a module that defines duplicate image styles.

I don't get why this feature would be so far from the core module's purpose

Of course there is a compatibility risk associated with it, but isn't the whole spirit of this module 'Make sure you know what you're doing' anyway?

@Marc-Antoine I would say the spirit of the module is "We're trying to make this work, please bear with us" :P

Every time Features is introduced as a module dependency a baby pig loses it's wings.

What do you mean by module dependency?

The patch #2 fail on features-7.x-1.0-rc1.
I manually apply it and reexport a new one.

Sorry, I'm a newb at patching

Please see features override module for this.

THIS PROBLEM ISN'T SOLVED BY FEATURES OVERRIDE. not only does it not clear this problem but for some bizarre reason FeatO isn't clearing any of the overrides at all.

am on the 2.x-dev; so i'll have to take a closer look at the patches before applying *sigh*

this is bananas. a year later and this problem is still dogging my site. i created a features module for my custom styles. i still can't "re-do" the module with new changes/overrides AND i still dont understand why in the world would i need another module (Features Override) to update a module i manually created with Features. can someone please EILA5?

It does not sounds like the same issue mentioned in the rest of the ticket. If I'm reading the comment history, the issue this ticket is for is that someone want allowing export of styles that are already defined by core, e.g. the ones here https://api.drupal.org/api/drupal/modules%21image%21image.module/functio.... Having two modules export the same style via the same hook leads to conflict. Thus features override so can export the differences (it creates alter hooks). This issue does not have anything to do with new/custom styles.

This is open source. Everyone is volunteer for the most part. Please don't yell/be rude :(