"container:deleteChildrenWithWrongPid" doesn't fix the error due to core behavior

[DenisMir]

We tried to delete some broken children with the help of the "container:deleteChildrenWithWrongPid" command.

Unfortunately this doesn't work when the page of this child elements is already deleted. The reason for this is that the TYPO3 DataHandler's cmd map like $cmd['tt_content'][54]['delete'] = 1; does not work when the page is already deleted. It just skips setting the elements itself to deleted = 1. So in the end they just keep being deleted = 0 and the containers integrity check stays red for these elements.

I'm not sure if this is fixable it would just be nice to get some feedback in the command documentation. So other users are aware of this problem.

[achimfritz]

Hi @DenisMir, use https://github.com/lolli42/dbdoctor to fix general inconsistencies.

[DenisMir]

Thank you very much for the hint. I will have a look at the dbdoctor.

[achimfritz]

@DenisMir can i close this issue?

[DenisMir]

Yeah the issue can be closed. I'm sorry I forgot about giving feedback. After cleaning it up manually everything is fine and the integrity check is green.

[instruccionesaldorso]

@achimfritz @DenisMir I faced the same problem described here.
In my case, I got 7 records with pid = -1.
And upgrade wizard is being repeated over and over again, detecting the same wrong pid records (through CLI o through BE Upgrade Wizard in the Install Tool)
Example:

WrongPidError: container child with uid 13629 (page: -1 language: 2) but tx_
      container_parent 1045 has pid 120 language: 2

I guess that DataHandler cannot mark my tt_content with uid 13629 as deleted = 1, due to pid being -1 (page deleted?).

Instead of checking https://github.com/lolli42/dbdoctor extension, would it be safe just running a database query that marks that records as deleted?

UPDATE tt_content SET deleted = 1 WHERE uid IN (13629,......);