Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
views_ui.module
Priority:
Major
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
18 Feb 2015 at 11:19 UTC
Updated:
27 Mar 2015 at 09:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dawehnerThank you for creating an issue.
Note: fixes should be filled against the recent version of the code.
Comment #2
upchuk commentedWill take a stab at this.
Comment #3
upchuk commentedHow about this?
A check inside the validation of the display.
If the approach is good, will go ahead with writing a test.
Comment #4
dawehnerMh, while this is certainly nice to have here, i'm a bit curios whether we really don't want to have a form level validation, which stops the user from saving the form.
Comment #5
upchuk commentedAdding an error in the validation there prevents the form from being submitted as well. It's the same behaviour as with creating a Page display without specifying a path to it. Whenever the view executes, the validation will fail and you get the message in red. You can't save the form in that state either.
Comment #6
dawehnerWell, but I kinda prefer the inline validation as it has a better UX, IMHO.
Comment #7
upchuk commentedHere we go. A fix + a test.
Comment #9
dawehnerIt looks great!
Comment #10
mpdonadioYeah, I think inline validation is better UX and DX; it will help prevent weird situations like #2446783: Views preview not working without saving new display.
Comment #11
upchuk commented@dawehner, I still want to add a little test to also check if the page display is removed completely. Currently it only disables it. The patch includes a check for both disabled and non-existent and the test should reflect both :)
@mpdonadio This cannot be implemented inline. I'm sorry I forgot to add a comment about this as I discussed this on IRC with dawehner a while ago. The problem with inline validation is that the form section responsible for turning on the 'more' link is different than the one responsible for selecting a custom url or a page display or whatever. So you end up in a situation that you won't be able to turn on the 'more' link because the other section (the link selection) will be by default set on 'None' (which will error out).
Comment #12
upchuk commentedHere we are, some extra checks.
Comment #14
fabianx commentedRTBC, looks great now!
Comment #15
dawehnerI'm sorry for my slacking +1 from me.
Comment #16
upchuk commentedWhat slacking? You've been super helpful :)
Comment #17
catchWhat happens if you configure this (when the validation would pass), but then later delete the display that can be linked to?
Comment #18
upchuk commentedThe validation gets called after many actions on the view. So just like test indicates, you can configure it properly but then when the validation gets called again, it fails if there is no valid page display with a path.
Comment #19
catchHmm I see that in the test now, it's not obvious from the comment though what's happening. Upchuck talked through in irc.
1. You have a valid View
2. You disable the page display which would make the view invalid
3. When you try to save, you get the validation error - because the path no longer has anywhere to point to.
So we don't stop you disabling the page display, but we then don't let you save the view until the master is updated.
That prevents the error I had in mind, I can see people getting confused when it happens but it's consistent with the page display never having been there at all.
Would change the comment to something like:
'Confirm that the view does not validate when the page display is disabled.'But seems OK.
Comment #20
upchuk commentedHere we go.
Comment #21
fabianx commentedBack to RTBC
Comment #22
alexpottWe don't use please in our UI text.
Comment #23
upchuk commentedHere we go.
Comment #25
dawehnerPlease, don't use "please" in our UI.
Comment #26
upchuk commentedDamn it, forgot to update the test as well :)
Comment #27
dawehnerBack to RTBC
Comment #28
alexpottThis issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 0fd920c and pushed to 8.0.x. Thanks!
This would have introduced the first use of "You'll need" into core. I changed this to "You need"