Наумов Алексей

А банальный setPlaceholders не срабатывает?

Из документации:

Note that using the setValues() method here will make the corresponding placeholders available to your email chunk; the effect of manually setting values is similar to adding hidden fields to your form.

В easyComm «создать 2 варианта отображения» вы имеете ввиду в админке? Это да… на фронтенде можно.

А прикрепить файл можно: modx.pro/components/5707-easycomm-additional-picture-field/

правда сейчас заточено под изображение. Но в принципе можно и под обычный файл сделать, правда с некоторыми правками кода easyComm…

Опишите задачу подробнее, возможно получиться решить через easyComm

Добрый день!

Честно говоря, пока у меня не получилось это реализовать. Поиск не дал мне нужных знаний, что бы понять, как это правильно сделать в MODx. Те способы, которые я испробовал не работают до конца. Но задача стоит, так что надежды не теряем!)

modx.pro/help/6121/

я там код плагина приводил в комментариях

А мож лучше не в файл, а в табличку? А в админке список вывести, для быстрого доступа.
p.s. это не критика, это предложение))) а плюсик заметке поставил))

Да, по идее сработает.

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

Ну вот тут все сложнее.

Потому что сначала выбирается 4 ресурса из БД, а потом проверяются права. В итоге видим ту картину, что вы описали. А проверять права в момент выборки нельзя.

Не сделать корректную постраничную навигацию с pdoPage и pdoResources с проверкой прав таким образом…

Копался в этом же направлении сам как-то, в итоге забил.

Вся проблема в том, что нужно открыть документацию docs.modx.pro/components/pdotools/general-settings

и найти параметр checkPermissions.

Далее вбить его в поиск на этом сайте, что бы увидеть примеры modx.pro/search?query=checkPermissions

в общем вам скорее всего нужно

&checkPermissions=`list`

Или для очистки через javascript

document.getElementById('myform').reset();

где myform — id формы.

Кстати, тоже словил «Trying to install pdoTools. Please wait...» при установке другого дополнения… видимо, что-то перестало работать.

Ну нормальная идея то в принципе, я особо не спорю, но при должном подходе.

Но по мне так лучше — дашбоард с уведомлениями о доступных обновлениях пакетов.

Вы издеваетесь что ли?

Да, как вариант.

А лучше — вынести информацию о доступных обновлениях ядра и дополнения на dashboard и отображать его только разработчику.

Если разрабатывается сложное дополнение, и добавляется серьезный функционал, или меняются основы поведения, то может сложиться ситуация, когда обновление в «1 клик» может не получится в принципе, потребуются какие-либо предварительные шаги или действия после обновления. Правда же? Ну и что теперь, этому разработчику сложного и нужного дополнения подъезды мыть?

Если в будущем администрирует сайт разработчик — это приятно и удобно, бесспорно.

Но если сайт передается клиенту и управляем им менеджер, то типовая ситуация будет такой:
1. О, что это за значек?
2. Хм, новая версия, новые возможности… установить…
3. Аааа, ничего не работает! (т.к. разработчик поменял функционал, а где-то на modx.pro написал, что перед обновлением нужно руками че нить в таблице поменять)
4. Звонок разработчику =)

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

В словарях?

Нет. Документацию читайте docs.modx.pro/components/pdotools/snippets/pdopage#Параметры

Параметр pageVarKey и ниже него totalVar.

Не очень понял… Несколько вызовов ecMessages вроде как и все:

[[ecMessages? &thread=`resource-1`]]
[[ecMessages? &thread=`resource-2`]]
[[ecMessages? &thread=`resource-3`]]

Прям в ядре компонента этого не будет. Но через плагины сделать можно: modx.pro/components/5707-easycomm-additional-picture-field/