Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
In Drupal 8.5.0-beta1 I am automatically returned to the Views index /admin/structure/views
after saving a View. This did not happen in 8.4.4. The individual View's page was still shown after saving, which was preferable behaviour.
Comment | File | Size | Author |
---|---|---|---|
#16 | 2945243-16.patch | 1.62 KB | Lendude |
#16 | interdiff-2945243-15-16.txt | 867 bytes | Lendude |
#9 | remove-edit-operation-redirect-2945243-9.patch | 643 bytes | msankhala |
Comments
Comment #2
idebr CreditAttribution: idebr at ezCompany commentedThis behavior was added in #2767857: Add destination to edit, delete, enable, disable links in entity list builders
Comment #3
Nick Hope CreditAttribution: Nick Hope commentedThank you @idebr. I'm a little surprised this was changed by design. When working on a complex view, and regularly saving it while monitoring the results in another browser window, it's irritating to keep getting returned to
/admin/structure/views
. A setting on/admin/structure/views/settings
to maintain the old behaviour would be welcome: e.g. "Stay on View configuration page after saving". I'll change this to a feature request and change the title.Comment #4
jdvc CreditAttribution: jdvc commentedI second Nick's sentiment completely on this one. Any kind of advanced views configuration causes you to save repeatedly. It would be great to have this setting available to revert to the original functionality.
Comment #5
Nick Hope CreditAttribution: Nick Hope commentedComment #6
msankhala CreditAttribution: msankhala as a volunteer and at Srijan | A Material+ Company commentedThis can be fixed by removing
?destination=/admin/structure/views
parameter fromEdit
buttons URLs on admin/structure/views page.Comment #7
msankhala CreditAttribution: msankhala as a volunteer and at Srijan | A Material+ Company commentedComment #8
Nick Hope CreditAttribution: Nick Hope commentedWhere in the Drupal code would I be able to patch that?
Comment #9
msankhala CreditAttribution: msankhala as a volunteer and at Srijan | A Material+ Company commentedDefault operation for any kind of entity is being generated from
\Drupal\Core\Entity\EntityListBuilder::getDefaultOperations()
method which ensures that operation link has destination query parameter in url. For views ui list builder operation list is being generated from\Drupal\views_ui\ViewListBuilder::getDefaultOperations()
.I think it makes sense to remove destination query parameter for
Edit
operation.Here is the patch.
Comment #10
Nick Hope CreditAttribution: Nick Hope commentedThe patch in #9 works for me. Thank you very much @msankhala.
Comment #12
idebr CreditAttribution: idebr at iO commentedClosed #3055691: Get rid of ?destination param on Views admin listing links as a duplicate issue.
Comment #13
gonssalThe patch works as expected, thank you @msankhala.
This is indeed a very annoying behaviour when working on a complex view that you inevitably will be saving constantly while tweaking it.
I'm not changing to RTBC because I think an additional button saying something like "Save and continue editing" would be a better option.
Comment #15
anoopjohn CreditAttribution: anoopjohn at Zyxware Technologies commentedI can confirm that patch still applies correctly for 8.9.x.
However it does not look like it is introducing a setting or anything. It is changing the behaviour of how edit views links functions by removing the destination querystring. Is that what we are looking to do here? It definitely is better UX to not have to come to the views listing all the time when you are developing a view and you have to manually removing the querystring.
Comment #16
LendudeHuge +1 on this.
I don't think we need a setting for this. Since it is possible to lose the destination parameter through normal use of the Views UI without leaving the context of editing a view (just go to a different display then the default one), I think the use of a destination parameter just introduces an inconsistency in UX. As per usual, Views is the odd one out here, other entities don't have this problem, so I think it makes sense to make an exception here for Views compared to other entities.
This adds a test that we are only removing the destination from the edit link, not the delete link.
Comment #17
dwwAnother huge +1. This is a constant source of frustration and confusion. I was thinking of opening an issue about this, and was very happy to find it already done. ;)
The fix is 1 line, clear, and correct. Just in case, there's a well-formed comment to explain why. ;) Thanks @msankhala!
There's now test coverage, which is also small, concise, clear, and correct. Thanks @Lendude! ;)
It's not clear why @anoopjohn re-uploaded the identical patch from #9, so I'm hiding that from the summary.
#16 applies cleanly to 8.8.x, 8.9.x and 9.0.x branches.
I also tested manually, working as expected.
RTBC! :)
Thanks,
-Derek
Comment #18
dwwAlso, this seems more like a task, if not a bug fix. We're restoring more usable behavior that we used to have in core. A usability regression was introduced by #2767857: Add destination to edit, delete, enable, disable links in entity list builders (which makes sense for other entity types, but not for views). Fixing that regression isn't a feature. So let's split the difference and call it a task. ;)
Cheers,
-Derek
Comment #19
Dave KopecekI can confirm that #16 worked for me. Thank you!! Unpatched this is maddening for site builders.
Comment #20
alexpottCrediting @Nick Hope for filing this issue.
Committed and pushed e49e554766 to 9.0.x and f95865303d to 8.9.x. Thanks!
Comment #24
cheng75 CreditAttribution: cheng75 as a volunteer and at Google Code-In commentedThe patch applies cleanly for me . It is working as expected