Дело было не в бабине...

(;

Так. Чуток раскопал. Внешние ключи там не помогут, так как там происходит просто update ....__site_content set deleted=1 where blablala. И соответственно, на данном этапе просто не может происходить нарушения внешнего ключа.
Далее работа модуля останавливается, то есть помеченным на удаление остается действительно только один ресурс, без дочерних. А дальше пользователь админки жмет на очистку корзины, где ресурс уже физически удаляется из базы. И вот тут могло бы уж помочь наличие внешних ключей, но их там при установке Evo не создано.
В принципе, здесь хорошим решением было бы как раз эти ключи создать  запросом в базу данных, но это уже на запиливание ядра evo походит, и я не знаю, куда грамотно этот запрос корячить, чтобы при следующем обновлении и обновлении с других версий он правильно выполнился.

я этот баг давно зарепортил

надо будет исправить как-нибудь, но это очень редкое явление на самом деле

Это вот это?

ну что можно родителя удалить, а дети останутся

Ну если внешними ключами можно пользоваться (а вот тут я не знаю, так как вроде же Эво теперь позиционируется как совместимый не только с MySQL), то можно попробовать alter table в какой-нибудь скрипт запихать, чтобы эти ключи создал, и проблема уйдет. Если внешне ключи нельзя использовать, то тут да, уже побольше кода написать надо.

https://github.com/evolution-cms/evolution/issues/1965
Это?

да

А где непосредственно в коде выполняется delete from modx_site_content при очистке корзины? Можно было бы туда проверку  добавить на существование дочерних не удаленных. Правда, ее рекурсивно вних по дереву придется сделать, чтобы на всех уровнях вложенности проврить.

надо не проверки делать, а просто допилить docmanager

Хотя, если в новой версии Эво InnoDB таблицы уже используются, то туда так и просится alter table с созданием внешних ключей. Но не знаю, как такое поведет себя ан других НЕ MySQL базах, которые в списке поддерживаемых заявлены.

Ну кроме докменеджера документ на удаление может быть помечен и другим способом.

И у ДокМенеджера проблемное место еще, это еще запись вида 235** при необходимости удаления всех вложенных ресурсов в 235, но нет возjжности записи вида к примеру "^235", позволяющего исключить ресурс. А часто получается, что нужно вычистить все ресурсы внутри какого-то одного, но его самого при этом не удалять. Он помечается лишним, потом начинаются пляски с его восcтановлением без восстановления дочерних. При этом в некоторых версиях было так, что если его через контекстное меню восстановить, то заново восстановятся все вложенные. Соответственно, скорее всего так и возникают ситуации с "потерянными" ресурсами в базе.

не вижу проблемы удаляем все а потом нужные востанавливаем

Кстати, я не нашел, де теперь размещаются на гитхабе файлы ДокМенеджера. Дополнительный синтаксис в способ задания ресурса типа вышеописанного я смог бы туда добавить. То есть например сделать так, чтобы запись вида '235** ^235 ^237**' означала "применить изменения ко всем вложенным записям в ресурс 235, кроме ресурса 235 и ресурса 237 со всеми в него вложенными".

грубо выполнии 235** -> удалить и потом 235 -> востановить

и все удалены все дочерние но сам документ не удален