[BUGFIX] Fix integrity sorting in page with nested containers #512
Conversation
extcode
force-pushed
the
fix_sorting_in_page_for_nested_containers
branch
from
a2bff7f
to
f7e78be
Compare
$container->getChildRecords() only used for the condition. We can remove this, because the new getAfterContainerRecord() returns the container itself if ce has no children. We than can check if the uids are equal. This improvement allows to extract the $sorting from the condition so we only have the else block.
|
i do not understand this example, because integrity is broken, and this looks not like a sorting problem? |
|
I will take another look at the test setup. This is a customized example from a current project. From our point of view, the data in this project is not repaired correctly, so that moving content elements is not possible in certain situations. |
|
This is the scenario in our project. I hope that I now have correctly reduced the IDs and sorting to small numbers. The uids of the containers and content elements are 6 digits in the project. The numbers for the sorting are mostly 4 digits, because there is a lot of content on the pages. We cannot move the container with id:6 over the one with id:4, because for the calculation of the last child the sorting is not returned from the element id:3 but from id:2. TYPO3 should therefore move id:6 to id:2. From TYPO3's point of view, however, nothing needs to be done here because sorting:3 of id:2 is greater than sorting:2 of id:6. As far as I can see, the command container:sorting checks the integrity of the containers id:1, id:4 and id:6. The command container:sorting-in-page checks the containers one below the other and should correct the sorting for id:4 and following, because id:3 has set a higher value for sorting. With commit d1381f4 the test setup should be fixed. I debugged the $rows before and after running the command and get following changes for sorting (->). The colPos doesn't change anymore: |
Relates: #458