`typo3cms container:sorting --apply` never finishes about container HOT 9 CLOSED

Hi @lsascha

we had records pointing to itself causing an infinite loop. Just double check if you have some of those:

select * from tt_content  where uid = `tx_container_parent`;

It could also occur that you have dangling pages in your tree. Pages that are not deleted = 1 but it's parent page is gone.

Just add var_dump($containerRecord['uid']); or something at e.g. https://github.com/b13/container/blob/master/Classes/Integrity/Sorting.php#L112 to see progress and get to the uid causing the issue.

Cheers

from container.

I have an issue when updating to v2.0.

When i first run typo3cms container:sorting it correctly shows a bunch of entries like

container uid: 8991, pid 1465 must be fixed
container uid: 8992, pid 1465 must be fixed
container uid: 8995, pid 1465 must be fixed
container uid: 8997, pid 1465 must be fixed
container uid: 8998, pid 1465 must be fixed
container uid: 9000, pid 1465 must be fixed
(...)
container uid: 9311, pid 1503 must be fixed
container uid: 9312, pid 1503 must be fixed

But when i then finally run typo3cms container:sorting --apply its just stuck forever and never finishes. Even with multiple runs. (already ran for over 1 hour) Don't see any error logs or anything helpful.

It's a slow process.
While the command was executing, I tried running typo3cms container:sorting |wc -l a couple of times, and the count of containers which needs fixing decreases slowly.
At some point it finishes.
But for me container:sorting still returns some that needs fixing. The reason might be what @stefanisak or @achimfritz mentioned.

from container.

Hi @lsascha
looks like a inconsistence database, i saw something similar and found tt_content-elements with sys_language_uid = 0 but l18n_parent != 0 (setting l18n_parent of this elements to 0 fixes this for me). Maybe the dbdoctor may be helpfull for you https://github.com/lolli42/dbdoctor . You can also try to enable datahandler logging in Code https://github.com/b13/container/blob/master/Classes/Integrity/Sorting.php#L101 (should not be done on production systems)

from container.

@lsascha
I found that I had two containers where the first had the second as parent, and the second had the first as parent - that's in an infinite loop.
This SQL can find if this is the case.

select con1.uid, con2.uid FROM tt_content con1
JOIN tt_content con2 ON con2.uid = con1.tx_container_parent
WHERE con1.CType LIKE 'container%' AND con1.tx_container_parent != 0 AND con1.uid = con2.tx_container_parent

from container.

In my case there where containers which pointed to a non-existing page. That was because I switched from EXT:gridelements to EXT:containers without a big cleanup of the database. To get rid of these zombie content elements:

DELETE c FROM tt_content AS c 
LEFT JOIN pages AS p 
ON c.pid = p.uid 
WHERE p.uid IS NULL OR p.deleted = 1

from container.

It's a slow process. While the command was executing, I tried running typo3cms container:sorting |wc -l a couple of times, and the count of containers which needs fixing decreases slowly. At some point it finishes. But for me container:sorting still returns some that needs fixing. The reason might be what @stefanisak or @achimfritz mentioned.

This one saved my day. It is really a slow process due to the slow data handler. It took me hours to complete. But checking with wc -l does make it easier to know how far it is already.

from container.

Thing is that Sorting never continues once it encounters a container which has one of its children as parent container. Thus you never get any output. Only a freezing system due to OOM unless you apply a command timeout. ;-)

In our case this is exactly what happened. Notice that we did never use Gridelements here, so that cannot be the root cause. Also we unfortunately did trim the TYPO3 history too eagerly up until recently so we cannot see anymore how this came to be.

We now did apply the following SQL query as migration to "fix" the broken containers by marking the them as deleted:

UPDATE tt_content c1
LEFT JOIN tt_content c2 ON c2.uid = c1.tx_container_parent
SET c1.deleted = 1, c2.deleted = 1
WHERE c1.deleted = 0
AND c2.deleted = 0
AND c2.tx_container_parent = c1.uid

There may be other ways to "fix" this but these containers are not visible in the Page module anyways (most likely due to the circular reference) so editors won't notice the difference.

from container.

Hi Guys,

i have added a new option enable-logging for the command, that enables datahanders logging. Enable this and have a look into the TYPO3 Log Module (EXT:container 2.3.1, s 1f0b4f2)

hope this helps

from container.

Not sure why this was closed since logging alone won't fix the issue. Please consider reopening and wait for further feedback. 🙏

from container.