Сниппет multiTV отображает содержимое переменной multiTV. Разместите примерно такой вызов сниппета. Параметр tvName — Имя TV-параметра, который содержит multiTV
Формат: TV-параметр
Значение по умолчанию: пусто
Примечание: Обязательный параметр. Имена столбцов multiTV будут получены из конфигурационного файла
Пример:
docid — id документа, содержащего multiTV
Формат: id документа
Значение по умолчанию: Id текущего документа
Примечание: Необходим при вызове в шаблоне Ditto.
Пример:
tplConfig — Массив ключей в конфигурационном файле, который содержит шаблоны вывода конфигурации
Формат:
Значение по умолчанию: нет
Примечание: Будет с префиксом templates
Пример:
outerTpl — Шаблон внешнего блока
rowTpl — Шаблон вывода строки
display — количество отображаемых строк
Формат: число | all
Значение по умолчанию: 5
Примечание: all — показать все
Пример:
offset — количество первых строк, которые необходимо пропустить
Формат: число
Значение по умолчанию: 0
Примечание:
Пример:
rows — разделенный запятыми список номеров строк, которые должны быть отображены
Формат: число | all
Значение по умолчанию: all
Примечание:
Пример:
randomize — случайный порядок вывода строк
Формат: 0 | 1
Значение по умолчанию: 0
Примечание: Отключает параметры reverse и orderBy
Пример:
reverse — Обратный порядок отображения строк
Формат: 0 | 1
Значение по умолчанию: 0
Примечание: Отключает orderBy параметр
Пример:
orderBy — имя столбца и порядок направления сортировки
Формат: name:type direction
Значение по умолчанию: name:text asc
Примечание: Тип может быть text или date
Пример:
toPlaceholder — Вывод данных в плейсхолдер
Формат: имя плейсхолдера
Значение по умолчанию: нет
Примечание: Будет создан плейсхолдер с именем, указанным в значении параметра [+element+] . Отдельные элементы выводятся плейсхолдерами, где к имени добавляется номер строки [+element.1+] . Нормальный вывод сниппета подавляется.
Пример:
toJson — Вывод результатов в формате json
Формат: 0 | 1
Значение по умолчанию: 0
Примечание:
Пример:
published — режим отображения документов
Формат: 0 | 1 | 2
Значение по умолчанию: 1
Примечание: отображать только multiTV из опубликованных (1), неопубликованных (0) или любых (2) документов
Пример:
emptyOutput — вернуть пустую строку, если multiTV пуста, иначе возвращает внешний шаблон
Формат: 0 | 1
Значение по умолчанию: 1
Примечание:
Пример:
noResults — Текст выводимый если нет результата
outputSeparator — строка вставляемая между двумя шаблонами строк
Формат: строка
Значение по умолчанию: пусто
Примечание:
Пример:
firstClass — Класс первого элемента
Формат: имя класса
Значение по умолчанию: first
Примечание: Содержимое плейсхолдера row.class для первого элемента
Пример:
lastClass — Класс последнего элемента
Формат: имя класса
Значение по умолчанию: last
Примечание: Содержимое плейсхолдера row.class у последнего элемента
Пример:
evenClass — Класс для четных элементов
Формат: имя класса
Значение по умолчанию: нет
Примечание: Содержимое плейсхолдера row.class для четных элементов
Пример:
oddClass — Класс нечетных элементов
Формат: имя класса
Значение по умолчанию: нет
Примечание: Содержимое плейсхолдера row.class для нечетных элементов
Пример:
paginate — показывать пагинацию
Формат: 0 | 1
Значение по умолчанию: 0
Примечание:
Пример:
offsetKey — Pagination offset parameter key
Формат:
Значение по умолчанию: page
Примечание:
Пример:
fieldname»
3 урок Корпоративный сайт на MODX Revolution. Вывод изображений слайдера через TV поля, ТВ на MODX
ModX Revo — Урок №3.1 Шаблоны. Вывод ресурсов и создание TV поля
Плейсхолдеры outerTpl
| wrapper | место вывода всех строк |
| rows.offset | содержит количество строк от начала, которые не отображаются |
| rows.total | содержит количество всех отображаемых строк |
| docid | значение параметра docid или id текущего документа |
| pagination | содержит постраничное разбиение, если параметр включен |
Стоп войны против Украины
Россия начала полномасштабную войну против Украины!
❌ На 27.02 погибло 4500 российских солдат, много раненых, много в плену.
❌ Если ваши родные, служат в российской армии (возможно вы думаете, что они на учении — по этому они без связи), то скорей всего их отправили на войну в Украину.
❌ Вы можете проверить, нету ли ваших родных-служащих среди убитых и пленных на сайте https://200rf.com (скорей-всего сайт откроется с помощью VPN)
❌ Очень много неопознанных, так как небыло или уничтожены документы
Источник: modx-gu.ru
MIGX: экспресс-руководство
Эта статья — пошаговое экспресс-руководство для того, чтобы использовать MIGX на сайте, созданном на MODx Revolution, прямо сейчас. Мы пробежимся по самым основным этапам создания MIGX-полей, чтобы у вас не сложилось впечатления, что MIGX — это сложно и долго.
Автор материала
Артем Зернов . Веб-разработчик, создатель проекта Лектория, эксперт MODX Revolution, директор веб-студии OpenColour. Youtube-канал OpenModx.
8 минут на прочтение
Теги по теме:
Зачем нам MIGX на сайте?
Если вам необходимо в каком-либо блоке на сайте вывести несколько элементов одного типа, не обязаетльно одинаковых по стилю, но очень схожих по своему назначению, то в большинстве случаев, для этих целей как нельзя лучше подходит бесплатный компонент MIGX, особенно, если вы заранее не знаете, сколько таких блоков-элементов будет на странице.
Помимо прочего данный компонент также позволяет добавлять и редактировать значения, хранимые в кастомных таблицах БД, но это выходит за рамки экспресс-руководства.
Первое, что пришло бы в голову: организовать такие элементы как набор заранее подготовленных TV (например, вы можете сделать заранее 20 TV для заголовков и 20 TV для описаний, но это крайне неоптимально и неудобно ). Как раз, чтобы не заниматься такими глупостями, но при этом не тратить большое количество времени на создание дополнительных таблиц в БД и настройке админки, чтобы эти поля редактировать, был придуман MIGX с возможностью добавлять такого рода дополнительные поля:
Подготавливаем конфигурацию
После установки MIGX в админке появится новый одноименный пункт меню. Именно туда нам и нужно. На вкладке «MIGX» добавляем новую конфигурацию, нажав на «Добавить элемент».
Самое главное дальше, не испугаться такого количество вкладок и полей. Мы будем заполнять только необходимые и их не так много. Вкладки и поля, которые нам не пригодятся для примера выше, мы будем пропускать. Таким образом, у вас появится первый навык применения MIGX для простых списковых TV-полей. В дальнейшем вы сможете изучить MIGX более подробно для применения его в более сложных случаях.
Даем имя нашей конфигурации. Ее можно назвать произвольным образом. Главное, дайте ей осмысленное название, которое отражает ее назначение.
Добавляем поля всплывающего окна редактирования
На вкладке «Formtabs» мы можем настроить содержимое формы, которая будет открываться при добавлении нового элемента или редактировании существующего. Сначала мы добавляем вкладки формы (tabs), а затем на каждую вкладку добавляем поля.
Сначала добавляем новую вкладку:
Затем внутри новой вкладки добавляем поля один за одним, нажимая «добавить элемент»:
В нашем случае нам требуется всего 2 поля:
- Для заголовка (поле типа text)
- Для описания (поле типа textarea–текстовая область или richtext–текстовый редактор)
Если вы хотите добавить в окно редактирования значения поле, тип которого совпадает уже с каким-то ранее подготовленным дополнительным полем (TV), то вы можете использовать имя этого TV в поле Input TV. Например, у вас уже есть TV для ввода даты и времени под названием myDateTime, для этого вам достаточно будет в поле Input TV ввести «myDateTime» и нажать «Выполнено», оставив остальные поля пустыми.
В поле Input TV type вводится тип поля. Список типов можно посмотреть на странице документации modx.
После того, как мы выполнили добавление поля title, повторяем такую же процедуру для поля description, указав его тип как textarea или richtext
После этого считаем, что добавление полей для всплывающего окна добавления и редактирования записей мы завершили.
Теперь нужно определить, какие поля будут отображаться в таблице списка.
Добавляем колонки таблицы
В разделе «columns» настраиваются колонки таблицы, которые будут отображаться на месте TV в админке. Сюда добавляются, как правило, колонки, соответствующие полям из вкладки «Formtabs» и дополнительные колонки для прочих целей (например для вывода кнопок редактирования записи или отображающие какие-то сводные данные).
Нам необходимо добавить колонку для вывода поля title.
Если мы хотим иметь возможность редактировать значение прямо из таблицы, кликнув дважды на само значение, можно на вкладке Cell Editor указать тип редактора значений:
Аналогичную процедуру повторяем для поля description, указав в поле Field значение description. Затем, мы можем добавить для удобства еще одну колонку, в которой выведем три кнопки: Редактировать, Дублировать, Удалить.
Для этого добавляем еще одну колонку, задав ей заголовок «Действия», поле Field оставляем пустым, так как она не содержит никаких данных. А во вкладке «Renderer» нам необходимо выбрать функцию this.renderRowActions.
А для того, чтобы выбрать, какие именно действия необходимо отобразить в этой колонке, на вкладке Columnbuttons указываем те действия, которые хотим отобразить:
На этом можем считать, что наша первая конфигурация MIGX готова. Мы опустили рассмотрение многих полей, так как в данном кейсе они не используются, иначе бы данный мануал нельзя было назвать экспресс-руководством.
Сохраняем нашу конфигурацию и приступаем теперь непосредственно к созданию TV-поля.
Подробнее про MIGX
Кстати, почти такой же пример с подробным разъяснением способов его реализации я разбираю в курсе по созданию лендинга на MODx Revolution.
Источник: lectoria.pro
Расширение системных (и не только) таблиц в MODX Revolution
2015-03-22 в 18:52, admin , рубрики: modx, modx revolution, xpdo
В настоящий момент занимаюсь переделкой одного новостного портала на MODX Revolution. Так как посещаемость на сайте бывает до 100 000 человек в сутки, вопрос производительности здесь один из самых важных. С учетом того, что на текущий момент в базе более 75 000 статей, при неправильном (и даже при традиционном подходе к разработке на MODX) тормоза сайта практически гарантированы, а если частота посещений превысит время выполнения запроса, то сервер вообще ляжет. Вот часть приемов задействованных здесь для решения этих проблем я и опишу в этой статье.
1. Долгая генерация кеша.
Наверняка многие знают, что при обновлении кеша MODX проходится по всем документам и набивает карту ресурсов в кеш контекста. Если кто не в курсе, подробно я писал про это здесь. И хотя в MODX начиная с версии 2.2.7 (или в районе той) можно в настройках отключать кеширование карты ресурсов (системная настройка cache_alias_map) проблема эта решается только частично — MODX не кеширует УРЛы документов, но структуру с ID-шниками фигачит все равно, перебирая все документы из базы данных. Это приводит к тому, что во-первых, кеш-файл контекста разрастается, а во-вторых, скрипт может просто не выполниться за 30 секунд и кеш-файл побьется, что может вообще привести к фатальным ошибкам и сделать сайт нерабочим.
Но даже если сервер все-таки в состоянии дернуть все документы и набить все в кеш, давайте посмотрим на сравнительные цифры на один запрос при разных настройках. Цифры эти будут весьма относительные ибо многое зависит от настройки сервера и на разных серверах потребление памяти у одного и того же сайта будет разное, но в сравнении эти цифры дадут представление о разнице состояний. Для оценки потребления памяти буду вызывать getdata-процессор на получение 10-ти статей.
Итак, вариант первый: Полное кеширование карты ресурсов включено.
Размер кеш-файла контекста: 5 792 604 байт.
Потребление памяти при запросе: 28,25 Mb
Время: 0,06-0,1 сек.
Вариант второй: Полное кеширование карты ресурсов отключено (системная настройка cache_alias_map == false).
Размер кеш-файла контекста: 1 684 342 байт.
Потребление памяти при запросе: 15,5 Mb
Время: 0,03-0,06 сек.
Вариант третий: Полностью отключено кеширование карты ресурсов патчем cacheOptimizer.
Размер кеш-файла контекста: 54 945 байт.
Потребление памяти при запросе: 4,5 Mb
Время: 0,02-0,03 сек.
И это всего лишь на 75 000 ресурсов. На сотнях тысяч разница будет гораздо ощутимей.
Есть конечно тут и минусы. Например не будет работать Wayfinder, который строит менюшку на основе данных карты алиасов. Здесь придется самому менюшку собирать. Я чаще всего использую menu-процессор, про который писал здесь (см. раздел 2. Замена Wayfinder).
2. Низкая производительность из-за TV-параметров документов.
А вот это основная и наиболее интересная причина написания данного топика. Наверно нет ни одного MODX-разработчика, который бы не использовал телевизоры TV-поля. Они решают сразу две проблемы: 1. добавляют пользовательские поля документам, 2. дают различные интерфейсы для их редактирования в зависимости от типа поля.
Но есть у них и серьезный минус — все они хранятся в одной таблице. Это добавляет сразу несколько проблем:
1. Нельзя управлять уникальностью значений на уровне базы данных.
2. Нельзя использовать различные типы данных для различных TV-полей. Все данные TV-полей содержатся в единой колонке value с типом данных mediumtext. То есть мы и большего объема данные не можем использовать, и числовые значения у нас будут храниться как строчные (что накладывает дополнительные требования к формированию запроса с сортировкой), и сравнение данных из различных колонок у нас не по фэншую, и вторичные ключи не настроить и много-много еще всего неприятного из-за этого.
3. Низкая производительность при выборке из нескольких таблиц. К примеру, у нас для одного документа есть несколько TV-полей, из которых хотя бы 2-3 поля практически всегда заполнены. Хотим мы получить в запросе сразу данные и документов и полей к ним. У нас есть два основных варианта формирования запроса на это:
1. Просто приджоинить таблицу TV-шек.
$q = $modx->newQuery(«modResource»); $alias = $q->getAlias(); $q->leftJoin(«modTemplateVarResource», «tv», «tv.contentid = .id»); $c->select(array( «tv.*», «.*», ));
Но здесь есть серьезный минус: в результирующую таблицу мы получим C*TV число записей, где C — кол-во записей в site_content, а TV — количество записей в таблице site_tmplvar_contentvalues для каждого документа в отдельности. То есть, если у нас, к примеру, 100 записей документов и по 3 записи TV на каждый документ (в среднем), то мы получим в итоге 100*3 = 300 записей.
Так как по этой причине в результате на один документ приходилось более одной результирующей записи, то на уровне PHP приходится дополнительно обрабатывать полученные данные чтобы сформировать уникальные данные. Это у нас и в getdata-процессоре выполняется. А это так же увеличивает нагрузку и увеличивает время выполнения.
Вот у меня в этом новостном портале как раз и было в среднем по 3 основных записи на документ. В итоге ~225 000 записей ТВ. Даже с оптимизацией запросов выполнение с условиями занимало 1-4 секунды, что очень долго.
2. Джоинить каждое TV-поле по отдельности.
Примерный запрос:
$q = $modx->newQuery(«modResource»); $alias = $q->getAlias(); $q->leftJoin(«modTemplateVarResource», «tv1», «tv1.tmplvarid = 1 AND tv1.contentid = .id»); $q->leftJoin(«modTemplateVarResource», «tv2», «tv2.tmplvarid = 2 AND tv2.contentid = .id»); // . $c->select(array( «tv1.value as tv1_value», «tv2.value as tv2_value», «.*», ));
Такой запрос отработается быстрее, так как в результирующей таблице будет столько же записей сколько и записей документов, но все равно нагрузка будет не маленькая когда счет записей пойдет на десятки и сотни тысяч, а а количество ТВ-шек перевалит за десяток (ведь каждая ТВ-шка — это плюс еще один джоининг таблицы).
Безусловно самый лучший вариант в данном случае — это хранение ТВ-значений в самой системной таблице site_content, то есть каждое значение хранится в отдельной колонке этой таблицы.
Если кто думает, что это очередной урок по изъезженной теме CRC, то это не совсем так. Традиционно нас учили расширять имеющиеся классы своими и там дописывать нужные нам колонки (а то и вовсе таблицу собственную прописывать). Но этот путь не оптимальный. Главная проблема здесь — это то, что мы расширяем как-то то класс, но не меняем его самого.
Расширения касаются только расширяющего (а не расширяемого) класса, а так же тех расширяющих классов, которые будут расширять наш класс. Запутанно, но сложно проще сказать. Объясню. У нас есть базовые класс modResource. Его расширяют классы modDocument, modWebLink, modSimLink и т.п. Все они наследуют от modResource мапу таблицы.
Если мы расширим нашим классом класс modResource, то в нашем классе будут новые колонки которые мы допишем, но их не будет в классе modDocument, так как он не расширяет наш класс. Для того, чтобы информация о новых колонках появилась во всех расширяющих modResource классах, информация эта должна быть в самом классе modResource. Но как это сделать не трогая самих системных файлов. На самом деле частично об этом я писал еще более двух лет назад (статью перенес сюда), но только сейчас это реализовал в боевом режиме. Делаем так:
1. Создаем новый компонент, который будет подгружаться как extensionPackage (подробно об этом писал здесь).
2. Создаем новые колонки в таблице site_content через phpMyAdmin или типа того.
3. С помощью CMPGenerator-а генерируем отдельный пакет с мапой таблицы site_content. В этой мапе будет и описание ваших новых колонок и таблиц.
4. Прописываем в вашем пакете в файле metadata.mysql.php данные ваших колонок и индексов (пример такого файла можно увидеть и в нашей сборке ShopModxBox).
К примеру у меня этот файл выглядит примерно так
array( «fields» => array( «article_type» => array( «defaultValue» => NULL, «metaData» => array ( ‘dbtype’ => ‘tinyint’, ‘precision’ => ‘3’, ‘attributes’ => ‘unsigned’, ‘phptype’ => ‘integer’, ‘null’ => true, ‘index’ => ‘index’, ), ), «image» => array( «defaultValue» => NULL, «metaData» => array ( ‘dbtype’ => ‘varchar’, ‘precision’ => ‘512’, ‘phptype’ => ‘string’, ‘null’ => false, ), ), ), «indexes» => array( ‘article_type’ => array ( ‘alias’ => ‘article_type’, ‘primary’ => false, ‘unique’ => false, ‘type’ => ‘BTREE’, ‘columns’ => array ( ‘article_type’ => array ( ‘length’ => », ‘collation’ => ‘A’, ‘null’ => true, ), ), ), ), ), ); foreach($custom_fields as $class => $class_data) < foreach($class_data[‘fields’] as $field =>$data)< $this->map[$class][‘fields’][$field] = $data[‘defaultValue’]; $this->map[$class][‘fieldMeta’][$field] = $data[‘metaData’]; > if(!empty($class_data[‘indexes’])) < foreach($class_data[‘indexes’] as $index =>$data)< $this->map[$class][‘indexes’][$index] = $data; > > >
Внимательно его изучите. Он добавляет информацию о двух колонках и одном индексе в таблицу site_content.
Давайте убедимся, что колонки действительно были добавлены. Выполним в консоли этот код:
$o = $modx->newObject(‘modDocument’); print_r($o->toArray());
Увидим вот такой результат:
Array ( [id] => [type] => document [contentType] => text/html [pagetitle] => [longtitle] => // Тут еще куча колонок перечислено // и в конце наши две колонки [article_type] => [image] => )
Вот теперь мы можем работать с системной таблицей с нашими кастомными полями. К примеру, так можно писать:
$resource = $modx->getObject(‘modResource’, $id); $resource->article_type = $article_type; $resource->save();
В таблицу для этого документа будет записано наше значение.
Создание своих колонок и индексов на чистом MODX.
Понятное дело что при таком подходе у нас возникает проблема миграции с такого кастомного сайта на чистый MODX, ведь там в таблицах нет наших кастомных полей и индектов. Но на самом деле это как бы и не проблема совсем. Дело в том, что как мы генерируем мапу из таблиц, так и таблицы, колонки и индексы мы можем создавать из мап-описаний классов. Создать колонку или индекс очень просто:
// Получаем менеджер работы с базой данных $manager = $modx->getManager(); // Создаем колонку $manager->addField($className, $fieldName); // Создаем индекс $manager->addIndex($className, $fieldName);
При этом не надо никакие данные колонок и индексов указывать кроме как их названия. Эти данные xPDO получит из нашей мапы и использует при создании описанной колонки или индекса.
Если вы свой компонент соберете в нормальный установочный пакет, то там можете прям прописать скрипт чтобы при установке пакета сразу были созданы в таблицах ваши кастомные колонки и индексы.
Рендеринг ваших кастомных данных в TV-полях при редактировании документов.
Как я и говорил выше, удобство TV-шек заключается в том, что для них созданы различные управляющие элементы (текстовые поля, выпадающие списка, чекбоксы, радиобоксы и т.п.). Плюс к этому в родном редакторе форм можно разграничить права на те или иные ТВ-поля, чтобы кому не покладено не мог видеть/редактировать приватные поля.
На самом деле можно, если очень хочется, но все же приватные поля не будут мозолить глаза кому не поподя. И вот как раз эти механизмы и не хотелось бы терять, ибо иначе придется фигачить свои собственные интерфейсы на управление этими данными, а это весьма трудозатратно. Хотелось бы все-таки для редактирования таких данных использовать родной редактор ресурсов.
Идеального механизма здесь нет, но боле менее пригодный вариант я отработал. Смысл его заключается в том, чтобы на уровне плагина в момент рендеринга формы редактирования документа подставить TV-поле со своим кастомным значением, а при сохранении документа перехватить данные TV-шки и эти данные сохранить в наши кастомные поля. К сожалению, не получается здесь вклиниться как положено (просто потому что API не позволяет), так что мы не можем повлиять на передаваемые процессору документа данные, из-за чего данные ТВшки все равно будут записаны в таблицу ТВшек, но это не проблема — просто после сохранения документа автоматом подчистим эту табличку и все. Вот пример плагина, срабатывающего на три события (1. рендеринг формы редактирования документа с подстановкой TV-поля и кастомными данными, 2. получение данных и изменение объекта документа перед его сохранением, 3. чистка ненужных данных).
Посмотреть код
event->name) < /* Рендеринг ТВшек */ case ‘OnResourceTVFormRender’: $categories = foreach($categories as $c_id => foreach($category[‘tvs’] as /* Рендеринг тэгов */ if($tv->id == ‘1’)< if($document = $modx->getObject(‘modResource’, $resource))< $q = $modx->newQuery(‘modResourceTag’); $q->select(array( «GROUP_CONCAT(distinct tag_id) as tags», )); $q->where(array( «resource_id» => $document->id, )); $tags = $modx->getValue($q->prepare()); $value = str_replace(«,», «||», $tags); $tv->value = $value; $tv->relativeValue = $value; $inputForm = $tv->renderInput($document, array(‘value’=> $tv->value)); $tv->set(‘formElement’,$inputForm); > > /* Рендеринг картинок */ else if($tv->id == 2)< if($document = $modx->getObject(‘modResource’, $resource))< $tv->value = $document->image; $tv->relativeValue = $document->image; $inputForm = $tv->renderInput($document, array(‘value’=> $tv->value)); $tv->set(‘formElement’,$inputForm); > > /* Рендеринг статусов */ else if($tv->id == 12)< if($document = $modx->getObject(‘modResource’, $resource))< $tv->value = $document->article_status; $tv->relativeValue = $document->article_status; $inputForm = $tv->renderInput($document, array(‘value’=> $tv->value)); $tv->set(‘formElement’,$inputForm); > > > > break; // Перед сохранением документа case ‘OnBeforeDocFormSave’: $resource = /* Тэги. Перед сохранением документа мы получим все старые теги и установим им active = 0. Всем актуальным тегам будет установлено active = 1. После сохранения документа в событии OnDocFormSave мы удалим все не активные теги */ if(isset($resource->tv1))< $tags = array(); foreach((array)$resource->Tags as $tag)< $tag->active = 0; $tags[$tag->tag_id] = $tag; > // $tags = array(); if(!empty($resource->tv1))< foreach((array)$resource->tv1 as $tv_value)< if($tv_value)< if(!empty($tags[$tv_value]))< $tags[$tv_value]->active = 1; > else< $tags[$tv_value] = $modx->newObject(‘modResourceTag’, array( «tag_id» => $tv_value, )); > > > > $resource->Tags = $tags; $tags_ids = array(); foreach($resource->Tags as $tag)< if($tag->active)< $tags_ids[] = $tag->tag_id; > > $resource->tags = ($tags_ids ? implode(«,», $tags_ids) : NULL); > /* Обрабатываем изображение */ if(isset($resource->tv2))< $resource->image = $resource->tv2; > /* Обрабатываем статусы */ if(isset($resource->tv12))< $resource->article_status = $resource->tv12; > break; /* Сохранение документа */ case ‘OnDocFormSave’: $resource = /* Удаляем все не активные теги */ $modx->removeCollection(‘modResourceTag’,array( ‘active’ => 0, ‘resource_id’ => $resource->id, )); /* Удаляем TV-картинки, так как они сохраняются в системную таблицу Удаляем TV-статусы, так как они сохраняются в системную таблицу */ $modx->removeCollection(‘modTemplateVarResource’,array( ‘tmplvarid:in’ => array( 1, // Тэги 2, // Картинки 12, // Статусы ), ‘contentid’ => $resource->id, )); break; >
Благодаря этому плагину кастомные данные рендерятся в форму редактирования документа и обрабатываются при его сохранении.
Итог
Из 225+ тысяч записей в таблице дополнительных полей осталось только 78. Конечно не все ТВшки будут фигачиться в системную таблицу (а только те, что используются для поиска и сортировки), и какие-то данные конечно будут в таблице ТВ-полей, но нагрузка все же серьезно снизилась, а запросы стали попроще.
Источник: www.pvsm.ru