К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами Пожалейте тех, кому потом придется с такой галереей работать.

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

2.Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/

Не хочется вас расстраивать, но никак. В процессоре удаления документа (именно отметки документа как удаленный) modResourceDeleteProcessor нет проверки результата выполнения процессора. Раз и два. Поэтому, максимум что вы можете, это не перед удалением, а уже после удаления (сабжевое событие OnResourceDelete) восстановить документ ($resource->deleted = 0; $resource->save()). К слову, если вы планировали отловить событие и прервать выполнение процессора, чтобы документ не был удален, то вы не то событие дергаете. OnResourceDelete срабатывает на fireAfterDelete, то есть в тот момент, когда запись уже сделана. Что-то там прерывать бессмысленно уже. Для этого надо было юзать OnBeforeDocFormDelete, которое вызывается в fireBeforeDelete. Кстати, тут еще одна засада: при удалении документа «удаляются» и его дочерние документы. Поэтому здесь без останова плагина просто не обойтись. Иначе, перебирать все дочерние, смотреть когда были удалены и отменять удаление тем, которые были удалены секунду назад — это мегакостыль. В общем, надо писать и слать пуллреквест в ядро. P.S. читайте код. Как можно писать плагин для процессора, не читая код самого процессора? Угадайка?

Событие OnResourceDelete генерируется после фактического удаления (так же, как и OnDocFormDelete). Запрет удаления ресурсов нужно реализовывать на уровне прав. А именно, присвоить неудаляемым ресурсам определённую группу, и запретить определённым (или всем) пользователям удалять ресурсы этой группы.

Вы правы, $id передается по умолчанию. Теперь осталось понять как остановить работу не самого плагина а самого события(прервать удаление) т.к. return и break останавливают именно плагин. Задача стоит так что определенные ресурсы нельзя удалить…

Да, действительно. Тогда у него ошибка на этой строке и генерируется: при удалении ресурса из админки modx->resource не существует (не проинициализирован)

По поводу события — оно генерируется, галка стоит и вручную выводу сообщение в лог ошибок modx что бы проверить попал ли в это событие. По поводу $id сейчас попробую вывести его

$resource — ссылка на объект modResource, представляющий собой удаляемый ресурс Все верно. $modx->resource — это только во фронте, когда документ уже получен.