Explicitly set returnUrl params on element edit pages#18680
Open
brandonkelly wants to merge 3 commits into5.10from
Open
Explicitly set returnUrl params on element edit pages#18680brandonkelly wants to merge 3 commits into5.10from
returnUrl params on element edit pages#18680brandonkelly wants to merge 3 commits into5.10from
Conversation
i-just
requested changes
Apr 9, 2026
Contributor
There was a problem hiding this comment.
that's the only issue I found when testing:
- clean installation running branch for this PR
- create a couple of sections (Blog, My Channel); the entry type can contain all the defaults and only the title
- create a custom page called “Pages”
- add a Blog section to it
- go to CP > Pages > Blog; add an entry to it & fully save
- ensure you’re still in CP > Pages > Blog and edit the entry from the previous step
- choose “save as a new entry” alternative action
- press “Create new entry” (or “Delete draft”)
- you're redirected to the Entries > All entries page; you should be redirected to the Pages > Blog
not sure if this is expected behaviour:
- the setup listed above
- create an Entries field
- add that field to the entry type used by “My Channel”
- ensure you have an entry in that channel and that it has an entry from the Blog section selected in the Entries field
- go to CP > Entries > My Channel and edit the entry from the previous step
- double-click or use the actions menu to edit the entry listed in the Entries field, then open it in a new tab
- press “Save”
- you’re redirected to the Entries > My Channel index page
I get why this is happening, but I’m not sure if this is expected from the user’s POV.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Currently after saving a full-page element edit form, the browser is redirected to the referrer URL, so long as it doesn’t look like the URL to the same exact element’s edit page.
That can lead to some awkward behaviors, depending on how you get to the element edit page to begin with. For example, if you press “Save and continue editing” or “Save and add another” from an element’s edit page, the subsequent page will redirect back to the initial edit page (see #18679).
This PR drops the automatic redirection based on the referral URL, in favor of explicitly setting a
returnUrlparam on element edit pages, when accessing the page from an element index.It also updates the “Save and continue editing”, “Save and add another”, and “Revert content from this revision” actions to maintain the
returnUrlparam, so the original element index URL will be remembered even as authors interact with those actions.Related issues