-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Item after Container failed #458
Comments
Did you execute |
Recently switched from gridlelements to containers v2.3.1 on a Typo3 10.4 installation and have users experiencing the same issue. How often does this command need to be run and where can I find documentation on what it does? Also, I have the |
Do you still have gridelements installed? Looks like this could cause conflicts #475 (comment) |
Installed but deactivated. Do I need to fully uninstall it? I inherited a legacy site from many years ago and we use the Extension Manager. |
As far as I understand it, you need to run Except you have any other script or tool, that manipulates the tt_content.sorting field. If you can ensure, it's not EXT:gridelements which manipulates the field, I'm pretty sure there is any other script or extension in your project, that does it. |
This issue looks like it got duplicated by #500. We encounter the same issue. I guess this bug got introduced via 149 with a1cc4de.
I don't know why it should lead to broken sorting, right now it seems the other way around. And the proposed fix also seems to revert that change. I will now test the suggestion to execute the command (multiple times as the instance has nested containers). That might solve the issue as the last element then might have a higher sorting value which would than be used for pasting. |
Executing the command didn't solve the issue. There is a functional test ensuring that moving properly works. So I guess the command is for some reason unable to properly fix the broken sorting in our instance. |
@DanielSiepmann it would be helpful to provide a simple dump of the corresponding tt_content records, do reproduce the bug on a vanilla TYPO3 instance |
A colleague of mine will further investigate. |
I don't know if this fits the case exactly. I once analyzed this for a case in one of our projects. We were unable to move a certain content element before the previous content element in the project. |
This still happens. I have a similar problem in TYPO3 11.x and EXT:container 2.2.4 currently.
Whats even worth is. I executed the sorting command. After the sorting it worked until a new child got created. After the creation of any new child on the page, the next element outside of the container went directly on top of the page. Is there a permanent solution for that? I cant execute the command every time a new child was created. |
Hi @garbast , i cannot reproduce this (on a vanilla TYPO3 with EXT:container_examples) (TYPO3 11, container:2.2.4, PHP 8.1) (i have clicked the "+ Content" Button, to create element after container, right?) can you give and min. sql dump of the tt_content table, before (and after?) the new element after the container is created? (any other extensions installed?) |
Its not possible to move a Content Element after a B13 Container
Latest version b13 Container
TYPO3: 12,4,7
The Issue happens in:
Classes/Hooks/Datahandler/CommandMapBeforeStartHook.html Line 145.
The Fix is:
(add after line 145)
if ((int)$value['update']['tx_container_parent'] > 0) {
$target = $this->containerService->getAfterContainerElementTarget($container);
} else {
continue;
}
garbast@cfdb180
The text was updated successfully, but these errors were encountered: