[Regression] Editing a media entity now always redirects you to a media overview list

Created on 25 October 2018, over 6 years ago
Updated 18 October 2023, over 1 year ago

Problem/Motivation

#2974203: Redirect back to media list after creating a media entity β†’ caused a fairly serious regression for an unknown (presumably small) percentage of site admins. Although the title (and all of the discussion) focused on "redirect ... after creating a media entity", the patch that landed touches MediaForm::save() such that all uses of a media form, including edit, get this forced redirect.

Steps to reproduce

  1. Clean install of Drupal 11.x
  2. Install the media module
  3. Visit: /admin/config/media/media-settings
  4. Enable the Standalone media URL
  5. Visit: /admin/content/media
  6. Add a simple media entity (image)
  7. Visit the media entity canonical url (/media/1) Admittedly, this is the rare step, but it happens, and the fact that media entities have a canonical view route means we need to support this case.
  8. Click the "Edit" tab, make any changes.
  9. Press "Save". <- Everyone expects to go back to the "View" tab, not sent off to an admin listing page.

Regardless of the behavior after adding a new entity (and if that should become a setting), it seems like editing an existing entity should never do this redirect, unless destination says so (which all the edit links on the media overview list already provide).

Content editor assumptions

view -> edit -> view : good
other -> edit -> other : good
view -> edit -> other : bad

Proposed resolution

Pick one:

A) Revert #2974203: Redirect back to media list after creating a media entity β†’ . Patch in comment #3.

B) Fix the logic added in #2974203 to only happen on new entities, not when editing existing entities. Different behavior for edit vs. add cases. Patch in comment #4.

C) Add a single per-bundle setting for a shared redirect for both add and edit.

D) Separate per-bundle settings for redirect after add vs. edit.

E) Site-wide config setting to decide? Where?

F) Other?

Remaining tasks

Discuss possible solutions and pick one.
Implement.
Fix tests.
Commit.

User interface changes

Unknown.
At least fix the regression.
Possible new setting(s) to control behavior.

API changes

Hopefully none.

Data model changes

Possible new setting(s) to control behavior.

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
MediaΒ  β†’

Last updated 1 day ago

Created by

πŸ‡ΊπŸ‡ΈUnited States dww

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¬πŸ‡§United Kingdom nlisgo

    I'm going to see if I can recreate this issue in 11.x.

  • πŸ‡¬πŸ‡§United Kingdom nlisgo

    I have been able to recreate the issue in 11.x. Given the lack of activity on this issue we should prioritise fixing for 11.x and backport if needed.

    I will adapt the steps to recreate for 11.x

  • πŸ‡ΊπŸ‡ΈUnited States benjifisher Boston area

    I added a usability review for this issue a long time ago (Comment #14). One alternative that has come up since then is to let the user decide by providing a secondary submit button. Here is a screenshot showing that pattern for taxonomy. (The screenshot uses the Umami demo profile and browser tools to simulate a narrow screen.)

    I have not looked at this issue in a long time until today. Using two submit buttons here might not be a good idea. I mention it only as an idea worth considering, not a recommendation.

Production build 0.71.5 2024