Where is "Use default" button? used to revert override to default (master) values

There is now a select-box at the top, where you can choose the used display.

Good point this seems to me like a big regression.

EDIT: I'm experiencing this too. Sorry to have to re-open! Thanks for all your hard work on views!

Why open it without any informations?

Apologies - I didn't have any new information to offer so I didn't bother with the 'Me too...'

I'm experiencing the same issue as the OP, and you only acknowledged it as 'big regression', after having marked it as fixed. There aren't any patches and I couldn't see anything in the git log so assumed it hasn't actually been fixed, and you left with that status inadvertently. Sorry if I missed something there!

Also apologies I can't offer a patch right now - what's the intended behaviour? That when you select 'all displays (except overridden)' the form values revert to the master? Or should still be a 'use master' button?

The select-field is the intended behaviour. This part of the ui got changed in the new ui.

So the field values should revert to the master display values when you change the scope from "this display" to "all display's"?

I agree that in the midst of the many improvements in the new UI, this seems like a regression. I wouldn't go back to the previous toggle, but having a clear way to say that you wanted to remove overrides and use default/master values would be really useful.

Here's a use case:

• I created a view with multiple displays and filtered on a different taxonomy term for each display.
• Then I added a more complex filter to the master display, using two different filter groups and and/or settings.
• But of course, because the different term meant every display was overriding defaults, my complex filter isn't inherited by any of the other displays.
• So it would be simpler to remove the overrides on each display and then re-add the taxonomy filter setting, rather than having to re-create the complex filter in every display.
• If, on each display, I set the part of the filter I overrode (taxonomy term) back to the default (no term chosen) and set it to Apply to all displays (except overridden) I can indeed get it to revert to the master values. But it isn't obvious that this will work, and I would assume that if I couldn't remember what bit had been overridden, I would end up changing the master values in the process of reverting my display.

So a really clear "remove overrides" option would be great.

The whole business with the select box needs major re-evaluation. It even managed to trip me up.

Linking another issue which shows that under certain cases this feature is horrible broken #1174588: Overriding 'Display access settings' changes all displays unless 'Access control type' is also overridden

Subscribe

What about in the dropdown for fields/filters/... where it currently has "add" and "rearrange" add a "reset to defaults" if the fields/filters/whatever is overridden?

Because I know drupal well and I'm really having a hard time right now on a view where I have to take the fields for 8 displays back to the default values.

It looks like there was some confusion between #3 and #6.

It was marked fixed in #1, but then #3 says it was an actual bug, but not reopened.

#11 seems like a good explanation of the issue.

Talked about this more with dereine in IRC. I think we're on the same page again.

In D6, the "Use default" button was on individual item edit pages, which was very confusing. An example of how it worked:

You have a default display with "Title" field and "Body" field. Your page display is overridden; "Body" is displayed as a teaser, and you've add "Updated Date". Then you decide you want to revert your "Body" field to the default, so you edit it and click the "Use default" button. Now, your "Updated Date" field is gone.

If we reintroduce the "Use default" button, I propose it only appear on the Rearrange page. When you click "Use default", all of the current display's fields will disappear and the defaults will be shown, giving you the chance to still hit cancel.

Now, the real discussion is if this should be a standalone button up by the dropdown, like it was in D6, or as a button along with Apply and Cancel at the bottom.

Also up for debate is the text of the button:
"Reset to default"
"Use default"
"Remove override"

Just tagging to catch them all.

Ok, I guess I'm not going crazy because I could not find a way to revert an overriden view back to the default.

There are two work arounds I thought of.
* Try to duplicate all of the default settings for whatever section you are trying to revert and then apply to all displays from within the display that was overridden.
* Export the view, edit the exported text to remove the overrides, then reimport the view.

Subscribe

Here is an irc log:

[22:03] <timplunkett> dereine: two questions about http://drupal.org/node/1242892
[22:03] <Druplicon> http://drupal.org/node/1242892 => Where is "Use default" button? used to revert override to default (master) values => Views, User interface, major, active, 20 comments, 5 IRC mentions
[22:03] <timplunkett> one, what needs to be done to move the issue along?
[22:04] <timplunkett> two, how would the code actually work when it's decided to do it :)
[22:05] <dereine>  there are several issues with the override button
[22:05] <dereine> a) you can't simply revert back to default without overriding the default data
[22:05] <dereine> if you had overriden changed and submit the default is changed
[22:05] <dereine> (just tries to summarize it)
[22:05] <timplunkett> right
[22:06] <dereine> b) and there is the problem that the overrides for access and cache are totally not how you expect them
[22:06] <timplunkett> http://drupal.org/project/issues/search/views?issue_tags=override-problem
[22:07] <timplunkett> dereine: some of those are bugs, some are currently "works as designed" yet we want to change how it works to make it more useful
[22:07] <timplunkett> like b) is a bug
[22:07] <timplunkett> but a) functions the way it should. it's just bad functionality
[22:07] <dereine> timplunkett: do you have an idea how to bring the just revert back to default feature back?
[22:08] <dereine> timplunkett: indeed i think most of the time you actually want to not override the default
[22:08] <dereine> b) should be tackled with http://drupal.org/node/1174588
[22:08] <Druplicon> http://drupal.org/node/1174588 => Override on page access changes all displays => Views, Code, critical, needs review, 14 comments, 4 IRC mentions
[22:09] <dereine> timplunkett: as far as i remember you talked about adding a new button?
[22:09] <timplunkett> yes
[22:09] <-- jalama has left this server (Ping timeout: 245 seconds).
[22:09] <timplunkett> dereine: http://drupal.org/node/1242892#comment-5024776
[22:09] <Druplicon> http://drupal.org/node/1242892 => Where is "Use default" button? used to revert override to default (master) values => Views, User interface, major, active, 20 comments, 6 IRC mentions
[22:10] <dereine> i'm wondering whether it would be more consistent/easier to use to have a third option in the select
[22:10] <dereine> but it's probably also confusing to submit without chaing something
[22:10] <timplunkett> yes
[22:11] <dereine> but a select seems to be a bad UI for a toggle-mechanism
[22:11] <timplunkett> the options in the select just change the behavior of the submit button. they don't affect the data directly
[22:11] <timplunkett> it should be a button in between apply and cancel
[22:12] <timplunkett> well
[22:12] <timplunkett> "Apply (all displays)" changes to "Apply (this display)" when you change the dropdown
[22:12] <timplunkett> if there was a third option, and the text changed to "Reset to default", that would work for me
[22:13] <timplunkett> no new button, keep the select list dropdown, make the behavior clear
[22:13] <dereine> oh that's a good idea
[22:13] <dereine> ping merlinofchaos
[22:16] --> jalama has joined this channel (~jalama@cpe-75-185-6-195.columbus.res.rr.com).
[22:17] <dereine> 'All Displays', 'Revert to all displays', 'This @display...'
[22:17] <dereine> timplunkett: what do you think about this naming?
[22:17] <timplunkett> dereine: well the current ones are appended to Apply. I'm not sure that "Apply (Revert to all displays)" makes sense
[22:18] <dereine> timplunkett: oh i'm first thinking of the select part
[22:19] <timplunkett> oh yeah i think thats fine

Here is a first version of the patch

As this patch + test shows it does not work as expected.

Manual testing

* override the title (set a new value)
* "choose" revert to all displays and input some new title
* submit and you will see the default value
* press f5 and you will see the new title
* arg

Okay you have to store the changed view in the cache.

Additional some changes according to a code review of chx.

This patch only shows the revert option on overridden sections.

Tim suggested to move default_revert to the bottom.

Ups forgot to update to the string change.

Let's get it in.

We've been using this patch on our sites, and it's a huge help. It still applies, and it'd be great to get this in.

+++ b/includes/admin.incundefined
@@ -2474,14 +2474,23 @@ function views_ui_standard_submit($form, &$form_state) {
     // the default display and saving values specific to this display.
-    $display = &$form_state['view']->display[$form_state['display_id']];

Mh this change might cause problems. See the reference patch.

+++ b/includes/admin.incundefined
@@ -2490,7 +2499,7 @@ function views_ui_standard_submit($form, &$form_state) {
-    $display = &$form_state['view']->display[$form_state['display_id']];

Same problem here.

Rework the status to not forget the patch.

With reference patch i mean #1199328: Add typehints and remove obsolete reference indicators for objects

With some feedback of bojanz and timplunkett i commited this patch to 7.x-3.x

Yeah one big step to 7.x-3.0
Thanks for everything helping on this issue.