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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Nick Hope created an issue. See original summary.

idebr’s picture

Nick Hope’s picture

Title: Automatically returned to Views index after saving a View » Add setting to remain on a View page after saving it
Category: Bug report » Feature request

Thank 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.

jdvc’s picture

I 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.

Nick Hope’s picture

msankhala’s picture

This can be fixed by removing ?destination=/admin/structure/views parameter from Edit buttons URLs on admin/structure/views page.

msankhala’s picture

Version: 8.6.x-dev » 8.7.x-dev
Nick Hope’s picture

This can be fixed by removing ?destination=/admin/structure/views parameter from Edit buttons URLs on admin/structure/views page.

Where in the Drupal code would I be able to patch that?

msankhala’s picture

Status: Active » Needs review
FileSize
643 bytes

Default 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.

Nick Hope’s picture

The patch in #9 works for me. Thank you very much @msankhala.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

idebr’s picture

gonssal’s picture

The 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.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

anoopjohn’s picture

I 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.

Lendude’s picture

Title: Add setting to remain on a View page after saving it » Remain on a View page after saving it
FileSize
867 bytes
1.62 KB

Huge +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.

dww’s picture

Status: Needs review » Reviewed & tested by the community

Another 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

dww’s picture

Category: Feature request » Task

Also, 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

Dave Kopecek’s picture

I can confirm that #16 worked for me. Thank you!! Unpatched this is maddening for site builders.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Crediting @Nick Hope for filing this issue.

Committed and pushed e49e554766 to 9.0.x and f95865303d to 8.9.x. Thanks!

  • alexpott committed e49e554 on 9.0.x
    Issue #2945243 by Lendude, msankhala, Nick Hope, dww: Remain on a View...

  • alexpott committed f958653 on 8.9.x
    Issue #2945243 by Lendude, msankhala, Nick Hope, dww: Remain on a View...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

cheng75’s picture

The patch applies cleanly for me . It is working as expected