Значит в чем-то ином дело. Смотреть код нужно.

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

(;

Так. Чуток раскопал. Внешние ключи там не помогут, так как там происходит просто 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 базах, которые в списке поддерживаемых заявлены.

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

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

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

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

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

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

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

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

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

https://github.com/extras-evolution/DocManager

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

Восстанавливать нужные через докменеджер приходится. Так как если в дерево ткнуть, то ресурс восстановится опять вместе с дочерними.

Восстанавливать нужные через докменеджер приходится. Так как если в дерево ткнуть, то ресурс восстановится опять вместе с дочерними.

ну да логично

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

Так и происходит сейчас. Но клиент умудрился все это как-то наоборот сделать. И удалил родительские, а дочерние оставил :)

Так и происходит сейчас. Но клиент умудрился все это как-то наоборот сделать. И удалил родительские, а дочерние оставил :)

Ну это класика 🙂

Так а все-таки. Мы можем внешние ключи добавить, или в списке баз данных, на кторых должно работать ЭВО, есть какие-то, которые их не поддерживают?

Внешние ключи добавить вот просто так не можем

Это будет версия 4

Внешние ключи добавить вот просто так не можем

Почему?

Да потому что вытворяют всякую хуйню, через апи мало кто делает

На тв уникальный ключ давно добавил, а проблемы до сих пор у некоторых возникают

С пользователями вот тоже

Да с кодировками в базе проблемы часто вижу, а тут вдруг движок поменять

Да потому что вытворяют всякую хуйню, через апи мало кто делает

Так а что можно такого вытворить, чтобы этому внешняя таблица помешала? Ну не даст она удалить запись или ее id сменить просто так. Ну так это и к лучшему, наверное...

Движок менять нужно у таблиц, в этом проблема

Так InnoDB и так уже по умолчанию в третьей версии.

Это если с нуля ставить

Движок менять нужно у таблиц, в этом проблема

Если это обнвление с 1.x, то да. А в третьей я проверял, если с нуля ставить, то уже InnoDB у всех таблиц сразу.

Поддержка совместимости версий вся навернется.

Ну так а обновление на 3.х достаточно глобальный скачок изменений, пользователи вроде это понимают, что что-то может отвалиться. Смена на InnoDB таблиц здесь не настолько сильным потрясением кажется, как всё остальное :)

Поддержка совместимости версий вся навернется.

Если правильно помню то смена первой цифры в версионность = сломанная совместимость 🙂

Если правильно помню то смена первой цифры в версионность = сломанная совместимость 🙂

Это когда нет хвостов, а тут прямо заявлена поддержка. (;

Это когда нет хвостов, а тут прямо заявлена поддержка. (;

Это в 2.x заявляли

В 3.x я говорил что я ломаю безвозвратно 🙂

Это в 2.x заявляли

Аааа. (:

Ловкий ход.

Ну ведь заявили, что всякие AjaxSearch и иже с ними не поддерживаются больше...

Если @Dmi3yy обещал совместимость, то с его и спрос 🙂 Я не обещал это точно 🙂

А толку от этих заявлений, если до сих пор дитто ставят

А поговорить?

А толку от этих заявлений, если до сих пор дитто ставят

+ да нет большого смысла

serious_t91 (146.03) увеличил карму Pathologic93 (6105.5)

Так а совместимость на самом деле очень даже хорошая. Просто совместимость она же не всего и вся, а только определенного списка компонентов. А их перечислить поштучно можно.

А толку от этих заявлений, если до сих пор дитто ставят

Дитто от внешних ключей не сломается, кстати :)

Подскажите кто с FormLister. Взял пример с доков самый первый, в &to указал почту куда нужно отправлять, после отправки приходит благодарность за обращение на ту почту что указал в форме, но само письмо с данными формы никуда не приходит...

ссSender?

ссSender?

?

1 стоит

ccSenderTpl?

Там все просто должно быть. reportTpl придет на тот адрес, который указан в to. А ccSenderTpl придет на тот адрес, который указали в поле email при заполнении формы.

все из дока

@CODE:Спасибо за обращение, [+name.value+]

так приходит только благодарность, спасибо за обращение

но само письмо с данными формы не приходит никуда, не понимаю почему

может я не так обьясняю или вы поняли о чем я?

а в reportTpl что? Контроллер какой используется - Form?

может я не так обьясняю или вы поняли о чем я?

Возможны оба варианта.

Восстанавливать нужные через докменеджер приходится. Так как если в дерево ткнуть, то ресурс восстановится опять вместе с дочерними.

Я такие операции в связке с едитДокс делаю. Массово удалил ветку, а родителей восстановил без дочерних через ЕД, проставив в нужное поле нули.

контроллер не менял, вообще ничего из стандартной доки не менял кроме почты &to

А какую доку вы называете стандартной?

А какую доку вы называете стандартной?

не так выразился, из формы с доков

https://docs.evo.im/04_extras/formlister/500_examples/001_prostaya_forma.html

вот эту взял и все, не могу понять почему письмо не приходит с данными заполненной формы

проблема в сервере может быть

а адреса в одном домене или разных?

Я бы на локалке проверил, создаются ли в sendmails файлы с содержимым писем.

Но вообще, раз у вас не "вообще не приходит", а "куда-то приходит, а куда-то не приходит", то я бы искал разницу. Например, протестил форму, введя в качестве емейла тот же адрес, который указан в to. Или поменял их местами.

Maybe this works? &to=`[+email.value+]` &autosender=`info@mymail.ru` &automessageTpl=`...`

And check Configuration > [(emailsender)]

а адреса в одном домене или разных?

вообще странно работает. С одной формы начало и то и то приходить, хотя изменений не было, точно так же скопировал на вторую форму, она таким же макаром работает, то есть благодарность приходит, а содержимое формы нет)