[infabo]

Problem

Creating a child content element inside a long or nested container returns editors to the top of the Page module after the new-content wizard or record editor closes. This is disruptive when the insertion point is outside the viewport.

This pull request is limited to container-specific new content element URLs. Editing existing records and deleting records are not changed.

Solution

• Add the existing insertion target as a fragment to the return URL of the new-content wizard.
• Add the same fragment to the direct record-editor return URL when a single content type is allowed.
• Preserve the fragment for the creationOptions.saveAndClose direct-creation path introduced on current master.
• Use the parent container as the target when inserting at the top of a container column.

The new record UID is not known when these URLs are built, so the closest stable target is the existing element before the insertion point, or the parent container for insertion at the top.

Verification

• Functional coverage for wizard, direct-editor, and direct-creation redirect URLs.
• Acceptance coverage proving that creating a child and closing the editor preserves the Page module position.
• Focused functional test on current master: 6 tests, 42 assertions.
• PHP-CS-Fixer dry run passes for the affected files.
• GitHub Actions provides the complete TYPO3/PHP matrix and acceptance coverage.

AI disclosure

This pull request, including its implementation, tests, and description, was updated with OpenAI Codex using the GPT-5 model. The resulting changes were reviewed and verified with the checks listed above.

[achimfritz]

Hi @infabo
nice, but TYPO3 core adds also no anchor to the delete URL (right?), so i think we should not introduce a behaviour that differs from core, why not also make a core patch?

[infabo]

Hi @achimfritz

why not also make a core patch

I am not going to "advertise" that feature to core maintainers. Submitting a core patch is kind of effort, you have to persuade core members of the "why this is needed". A very difficult part.

In first place, the main reason, this PR should fix the close/save not returning to the correct position in page layout view again. This is an established and known core behaviour - and should also be functioning inside a container.

Would you merge this PR when I remove the "delete" handling? Nobody would miss it anyways and it simplifies the PR.

Thanks

[achimfritz]

Hi @infabo , I'm not seeing it, i have testet v14:

• the edit link is not toched by EXT:container, so it has the same behaviour as core
• the new content element link, is build in EXT:container. But i did not see the anchor on core elements, when i create an CE at the very buttom of the page, i will not been redirect to the element (but stay on top of page), what is my mistake?

[achimfritz]

any news?

[infabo]

I am sorry, I did not understand your questions. Or how your questions are related to my previous comment.

[achimfritz]

Sorry if my questions were unclear, let me try again.

I (honestly claude in this case) compared the behavior with TYPO3 core v14 (EXT:backend, GridColumnItem / GridColumn):

Action	Core (regular columns)	EXT:container today
Edit (save & close)	returns to the element (anchor in returnUrl)	same, the edit link is not touched by EXT:container
Hide / unhide	returns to the element	same
New content element	no anchor, returns to top	same as core
Delete	no anchor, returns to top	same as core

So right now, EXT:container behaves exactly like core. In particular, I can't reproduce "saving returns to the top" on v14: editing a child inside a container and using save & close brings me back to that element.

That's why I'm asking for concrete steps, e.g.:

• Setup: TYPO3 version, container configuration, page content (how many elements, where the child is)
• Action: what exactly you click (edit / new / delete, which button)
• Expected: where you expect to land
• Actual: where you actually land

If save & close inside a container really doesn't return to the element in some setup, that's a bug and we'll fix it.

The other two parts (anchors after creating and deleting) are new behavior that core doesn't have for regular columns either. Also, the anchor after creating points to the element before the new one, not to the new element. We'd rather not change this only for container columns. That would be a good improvement for core, so the behavior is consistent across all columns.

[infabo]

If save & close inside a container really doesn't return to the element in some setup, that's a bug

That's why I have created this patch and submitted the PR. I admit, it went over the top because I wanted to "gold plate" (delete, create handling). I'll try to setup a clean install and try to reproduce the original issue I have observed and return with a modified PR.

The most important infos I can provide directly from my memory:

• it were nested containers
• some containers have quite many content elements inside, which won't fit the viewport

[infabo]

Update from Codex (OpenAI, GPT-5) — AI-assisted implementation and verification on behalf of @infabo.

Thanks for the detailed comparison. Your table is correct, and the previous description conflated editing an existing child with creating a new child. The PR does not modify existing-record edit links, so there is no save-and-close bug for existing records addressed here.

I have now:

• removed the delete URL override and its acceptance test;
• merged current master / 4.1.1 into the branch;
• narrowed the title, description, implementation, and tests to new-content creation only;
• covered the new creationOptions.saveAndClose direct-creation redirect as well.

The concrete scenario behind the remaining change is:

• Setup: TYPO3 13.4, a long Page module view, and nested containers (in the originating project, a carousel container contains item containers, which in turn contain regular content elements), with enough records that the inner insertion point is outside the initial viewport.
• Action: use the new-content button inside the inner container, select a content type, then save and close the newly created record.
• Expected: return to the insertion context in the inner container.
• Actual without this change: the container-specific new-content URL has a return URL without a fragment, so the Page module returns to the top.

Because the new record UID does not exist when the URL is built, the patch anchors to the insertion target (the preceding element), or to the parent container when inserting at the top. That explains why it cannot point to the newly created element itself.

I agree this is also relevant to regular core columns. The remaining rationale for this PR is that EXT:container builds these new-content URLs itself in NewContentUrlBuilder; no delete behavior or existing-edit behavior remains in the diff. If you still prefer handling the behavior exclusively in Core for consistency, please say so and we can take that route.

Local verification on the updated branch: the focused functional suite passes with 6 tests / 42 assertions on PHP 8.5 and TYPO3 13.4.36; PHP-CS-Fixer dry run passes. The new GitHub Actions run is currently action_required and needs approval from a repository maintainer before the full matrix can start.