Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | image.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Usability |
Issue Summary
Regarding #602938: Provide default styles in image.module (add hook_image_default_styles):
In #drupal, yoroy and Bojhan pointed out that this Default / Overridden / Custom business probably falls under "too much information" for the vast majority of site builders, who are not deploying code through something like SVN, though it is very handy for those who are. I'm on the fence about it, personally. I can see both sides.
As a site builder who *does* follow best practices, this information is really useful so I know which database-related thingies I haven't moved to code yet. Yet, core itself doesn't do anything with this information (there's no image style export functionality) and we also do not do show this type of information in other places in core. For example, with blocks, the way I know whether something is module-provided or custom is whether it has a "remove" link next to it. If so, I added it myself, and I need to move it to code. If not, it's already provided by a module. However, blocks don't have this interim "Overriden" step: they're either module-provided, or custom, and you're stuck with whatever the module gives you.
This issue is for discussing this a bit more, since the intention here is for core to establish a pattern that contrib can follow.
Comments
#1
Subscribble. For those who are interested in this, a first task would be to collect screenshots of the admin screens where this pattern occurs, like in the image style settings :)
#2
Sure.
The idea of this pattern is that modules can define some sensible defaults for configuration settings, and it's clear to the site builder whether those defaults are being used. This is particularly important for things that are exportable, because if you see a "revert" or a "custom" here, it means your data is sitting in the database, and not in code, so your changes could get blown away.
Image styles is the only place in core that this pattern exists currently. Here's the overview page of image styles, showing each type of style: default, overridden, and custom:
If you click "edit" on a "Default" one, you see this:
You can't actually edit the style to make changes without first clicking the "Override defaults" button.
This feature/pattern originated in Views. Nowadays, this is how Views communicates this information:
#3
Following.
#4
Hai.
Discussed 'per project email notification settings' with dww.
There's an older mockup in [#4793642] that tries to tackle a similar situation:
The screenshot shows a 'Notifications' tab on your My account page on d.o. with these options:
label: Global issue notification level, with 3 radio buttons 'None', 'Subscribed issues' and 'All issues'
Then a table with rows for each project that you want to customize this setting for. First cell: project name. Second cell: 'notification level', with a select list with (presumably) the same 3 options as for the global radio buttons.
---
In general, it will be interesting to learn how prominent the option that you can actually customize/override stuff has to be.
- Yes I want to override stuff
- I want to override settings for item x, y and z
- I want to override setting a, b and c for item x
- But only b and c for item y
Do the overrides re-use the given default or are they hard resets (preferably the prior, building on a given setting). Can overrides totally reset the default if necessary?
#5
On a macro-level, the case that @webchick described in #2 and the one that @yoroy mentioned in #4 might be similar - but both from a user interaction and from a technical perspective, I think they are vastly different.
In the first case, there are actually three different possible states; default, overridden, and custom. And any item in "default" originates from someone or somewhere else (a module maintainer or a site developer/maintainer). As a site user/administrator, you did not setup those "default" items yourself. Also, all the configuration items are independent pieces of data and not related to each other. The "inheritance" of default/overridden/custom only applies to the item itself, and sub-settings within the item itself. There is no global default or similar for all of the items.
The second case (#4) is different, and logically and technically a lot easier; you, as a site user/administrator, have configured a global default value for a particular setting somewhere, which is used by default, unless an individual piece of data is configured to use a different value. The given example of project issue notifications can be directly compared to Comment module comment settings in the node/content type configuration form. The node type defines a global default for comments for all nodes of the type. But you can override that global default to a different value for each node of the type. Thus, in these cases, there's a simple global default setting for "all" items, which the user can override on a per-item level.
I think this issue should continue to focus on @webchick's originally intended default/overridden/custom UI challenge.
Lastly, important: The screenshots in #2 are missing the "Disable" and "Enable" operations. Default configuration items in code cannot be deleted, but the user interface normally allows to at least disable them (so they're kinda "hidden" and not exposed or used elsewhere in the site).
#6
AFAIK, there is no such notion as 'overridden in the database' in in the Config Initiative. Config changes performed by the UI are instantly persisted to disk. This issue is becoming moot I think.
#7
Moot how? These cases still need UI no?