Неожиданно для себя публикую материал об основах работы в системе modx, больше, конечно же, как шпаргалка, но в тоже время как отдельный материал.
И спустя 3 года после его написания (оригинал я написал 12 февраля 2018 году), приходиться чуть его обновить (полностью), чтобы не позориться.
Несмотря на то, что эта статья вышла у меня на сайте еще в 2018 году - после того, как мне пришлось вплотную столкнуться, с чистого нуля, с modX - мне стало стыдно за этот материал, но я решил его не удалять, а чуть исправить. Я прошу прощения у всех, кто это все читал ранее.
Modx - даже не знаю как назвать, CMF или CMS - условимся, что это все же фреймворк, т.к. в "голом" виде, по сути gui оболочка для php, расширяемая php компонентами для работы, словно одна из популярных cms, но на минималках. Из коробки вы получаете платформу, цель которой вы сами придумываете - будет это или сложный проект или небольшая визитка, а может блог. Поняв принцип и работу MODX, вам будет легче в будущем перейти на уже очень серьезные php frameworkи, типа laravel или Yii.
Рассматривая MODX с бэкэнда, а точнее зайдя в админку (здесь и далее я буду так называть manager), мы увидим, что слева у нас есть такие подменю, как ресурсы и элементы. Элементы - шаблоны, чанки, TV и сниппеты. ЧТОТЫТАКОЕ??? Ресурсы - это, по сути, и есть страницы (разделы) сайта, которым вы или мы присваиваем шаблон (а так же опредяем тип ресурса. Для joomla авторов - это, по сути, пункты меню). Ресурс необязательно может быть html страничкой и вообще страничкой. Его можно сделать и xml, и текстовым, и скрытым, и вообще контейнером. Шаблон ресурса - уже есть одежда страницы сайта с нужной базовой разметкой (как платье). В будущем вы поймете, как это удобно, когда каждому ресурсу можно применить разные шаблоны или разные наборы параметров и полей. Как правило, а точнее, как я по традиции делаю - минимум 4 шаблона: главная страница, шаблон с двумя и одной колонкой, шаблон для списка (например блог или новости). Важно помнить, хоть это и сложно - шаблон это скелет, структура, дизайн. Руки чешутся все возможные вызовы сниппетов делать именно в шаблоне. Но нет. Забегая вперед, для этого лучше создать дополнительные поля и в ресурсах через них выводить сниппеты или чанки. Чанк - куски html кода в шаблонах. Во всех, практически, обучениях и документациях, в чанки рекомендуют оборачивать вывод результата из сниппета (опять же для joomla авторов чанк - модуль). Сниппеты - куски php кода. Точнее даже будет сказать - это контейнер для размещения в нем чистого php. И вот, чтобы в нем не указывать echo '', приличные modx-разработчики делают эхо через вывод в чанк. например $output = $modx->getChunk('ИмяЧанка', array('Переменная для сниппета' => $переменная или данные из кода,....)); return $output; - Это частый (популярный) случай вывода данных. Кстати, когда я впервые делал стандартный вывод из БД данных я столкнулся с проблемой - как правильно выводить из цикла while, т.к. данный код выше возвращал только последние данные. На просторах я вычитал про хитрость точки перед равно. $output .= $modx->getChunk(' .... - Я пользуюсь именно этим вариантом, хотя как правильно - хз. Итак, мы видим, что указывается в какой чанк передавать результат php кода, в самом чанке, переменные выводятся как [[+name]]. И это считается правильным подходом, который рекомендуется даже в официально документации, где-то здесь. На самом деле раз столкнувшись с написанием сниппета и попробовав "разделить" результаты от кода, вы поймете как это удобно. Сниппет у вас только код, а чанк - возможность красиво все вывести и показать, если у вас целая команда, то с оформлением чанков справится любой дизайнер-верстальщик, которому не нужно знание php, в то время как программист может спокойно работать с сухим php кодом, не задумываясь о том, как красиво или не красиво выводятся данные. Об этом я еще далее напишу.
Грубо говоря формат страниц любого сайта сайта на modx -> это Ресурс который подтянул шаблон, сниппет и чанки.
Ну и немаловажно, чанки можно создавать и для упрощения дизайна шаблонов. Например: создать отдельный чанк для навигации, отдельный для шапки и подвала сайта. Это очень удобно и для будущей правки, и для структуры, и для общего понимая конструкции каждой страницы. Главное не переусердствовать. Любое понятие чанка или сниппета вызывается в шаблоне, словно include и может быть кэшированным или нет. Кэш, одно из важных механизмов MODX - не забывайте об этом. Если у вас код выполняться будет не с динамическими данными, его лучше все вызывать закешированным. А если сниппет будет выводить постоянно меняющиеся данные - то тогда перед вызовом ставим !. О том как это работает легко можно понять, поковырявшись в папке cache.
Теперь о документации. Основной сайт, конечно же https://docs.modx.com/ - он поддерживает русский язык и содержит все основные данные и понятия. Все, можно эту статью закрывать. На самом деле, после того, как в 2020 я столкнулся вновь с разработках на modx причем с нуля, я перечитал свою же эту статью и мне стало грустно. И стыдно. И грустно. Особенно грустнее, что у этого материала было очень много просмотров, жалею вас мысленно и еще раз прошу прощения. Мне же очень сильно помог этот сайт https://www.riwkus.pro/ , неизвестной девушки-программиста (как я понял ее зовут Марина), где расписаны не только базовые вещи, но и доступно описаны принципы работы с основными необходимыми компонентами. Поэтому выражаю ей и сайту огромную благодарность за весь контент, после которого теперь точно эту мою статью можно закрыть и обплевать. Ну и конечно же, сайты главных modx программистов https://bezumkin.ru/ , и https://ilyaut.ru/ , и https://modzone.ru/ , и многие другие (о них я еще вспомню). Именно эти сайты у меня закреплены в закладках и исчитаны до дыр в коде.
Но вернемся ко мне. Еще один и немаловажный параметр - TV поля. Если не ошибаюсь, любой и joomla и wordpress девелопер сталкивался и должен понять, что это. По простому - это дополнительные поля для заполнения в ресурсе с их выводом в шаблоне. Я сейчас опишу стандартные и вы сразу поймете.
Заполнили вы название страницы, вот так вывели [[*pagetitle]] в шаблоне. Заполнили главный текст - [[*description]] – вот так вывели в шаблоне. И т.д.
[[*introtext]] – аннотация документа
[[*content]] – содержимое документа
[[*alias]] – псевдоним документа
А если вам стандартных этих полей не хватает, то вы можете создать любые свои и применить их к шаблонам. И после чего, заполняя ресурс, вы можете уже заполнить и их, не забыв сделать привязку. [[*ПараметрTVилиполе]] – выводя их значения в шаблоне. Практически все привязывается к шаблону, а шаблон привязывается к ресурсу.
Кстати, сейчас заметил, насколько сильно я привык к modx, что невольно пытаешься нажать Ctrl+S, что сохранить изменения. Ага, чуть не забыл, в модх очень классно продумано сохранение любого документа - привычное Ctrl+S. Удобно и шикарно.
Теперь поговорим о тегах. Любое понятие в шаблоне или чанке вызывается через двойные скобки [[ ]] , даже комментарии в коде. например [[--здесь комментарий]]. Передача каких либо параметров через & , а значения параметров `значение`. Вы с этим столкнетесь, но как пример [[!score? &champ=`7`]] - здесь я вызвал сниппет score не кэшируемым образом и передал туда переменную с значением 7. Соответственно в сниппете я стандартным образом ее ловлю, в виде $champ. (очень похоже на GET_[''] или POST_['']).
Стандартные теги:
[[$Чанк]] - вызов чанка
[[!Сниппет!]] (кешируемый или не кешируемый) – вызов сниппета.
[[+Переменная+]] – обращение к переменным именно уже в чанках для снипетов, то что я писал выше. Правильно называются они, в терминологии Modx - плейсхолдеры.
А так же - все различные поля ресурсов (ссылка на официальную документацию).
Например, при построении меню пригодятся
[[*id]] – идентификатор (номер) документа
[[~id]] – URL указанного документа
Очень часто вы будете видеть такие слова, как "код для fenom". Феном - один из парсеров, а точнее шаблонизаторов, кода modx. Когда вы напишите сайт\материал\сниппет\шаблон, чтобы его увидил весь мир, запускается парсер modx, цель которого обработать все эти ваши [[]] и вывести читаемый текст посетителю. И вот считается добрым правильным тоном дискутировать и ругаться по поводу медленный\нагружаемый\неудобный\неправильный парсер :-) И на крупнейшем ресурсе профессионалов modx в России modx.pro есть альтернативный парсер fenom, который очень популярен и очень часто пишут код под него. Он не единственный, есть еще twiggy и другие. Я же еще не настолько преисполнился в modx, чтобы переходить на альтернативный шаблонизатор, поэтому использую стандартный (но уже преисполнился, чтобы написать тут статью свою). Однако же решать использовать или нет, нужно в самом начале пути, чтобы потом при переписывании кода не сломать к чертям весь свой проект и не сидеть ночь, вытаскивая резервные копии.
Раз уж я заговорил о шаблонизаторе, необходимо вообще рассказать про расширение modx. Я обязательно косвенно затрону тему написания компонентов, а точнее про пространство имен, чуть далее, но нельзя не сказать, что простота и легкость написание кодов и плагинов, само собой порождает и написание расширений modx крупными разработчиками, для облегчения работы в modx. Как и в любой CMS, в modx можно установить пакеты готовых плагинов и модулей для работы и у каждого из разработчиков сайтов на modx, есть свой любимый стандарт таких расширений (Пакеты->Установщик пакетов). Мой такой:
Ace - редактор кода с подсветкой, завершением тегов, дублированием строк и т.д. аки добрый notepad++ - мастхэв для чанков и сниппетов. Я вообще вначале думал, что это предустановлено в modx.
Collections - Архиважное дополнение, если вы планируете вести на сайте новости или блог. Его работа проста и одновременно важна. Он группирует дочерние ресурсы у родителя и позволяет вам их легко редактировать и создавать внутри. Во сказал. Простым языком, когда вы пишите новости или блог, у вас рано или поздно будет очень много ресурсов, которые еще и разбиты по категориям. В итоге слева в меню вы получите огромные разворачиваемые списки без удобной сортировки и поиска. Коллекции позволят вам вывести все это в простом списке, на одной странице, где вы сами можете сформировать вид этого списка, например вывести ТВ-параметры с сортировкой по ним, или дату написания, или изображения - все как вам удобно, создавая и редактируя при этом. В меню ресурсов слева не будет длиннющего списка, а будет просто троетире.
Console - хорошее дополнение для разработчика сниппетов. Позволит внутри админки вывести консоль для отладки php кода, при этом может еще и сохранять ваши черновики. Особенно полезно, когда вы работаете не ночью, код по вашему правильный, но вы сомневаетесь и боитесь поломать существующее. А так проверили, успокоились, код внесли в сниппет. Меня еще часто выручало для проверки "помню\не помню" функций и базовых вещей на php, типа формата даты. Однако же может еще и пригодиться, если спустя годы вы решите переписать сниппет, то "собирать" его можно в этой консоле - вредные советы от spooky.. Поговаривают это для таких лентяев как я, которые не работают в докере, локальных копиях и различных IDE редакторов, типа netbeance или phpshtorm.
pdoTolls - его можно и в начало списка, пренеполезнейший компонент, который как раз таки и включает феном, но во многом ускоряет работу, переписывает стандартные функции, например не getresources, а pdoresource и т.д. С помощь него удобно выводить и статьи красиво и вкусно, и меню, и еще много чего.
MIGX - пакет для меня очень сложный, что я не знаю, как правильно его описать. Короче он позволяет нестандартно выводить поля тв. Зачастую его используют для создания различных каруселей, слайдшоу статей и т.д. Очень мощный инструмент. Не такой сложный в работе, как его понимание и цели.
controlErrorLog - выводит ошибки в работе в админке, вместо копания в файле /cache/logs/
AdminTools - набор полезных булочек для разработчика, где есть возможность делать заметки (только сохранять нужно по отдельной кнопке) и добавлять в избранное
VersionX - делает бэкапы ваших сниппетов и чанков
AjaxSnippet - для аякс вызовов сниппетов, если не готовы написать такой вызов сами :-) Скажу честно, я им пользуюсь, когда вызов сниппета по аяксу очень простой.
CookieConsent - как вы знаете, к сожалению, практически на каждом сайте надо указывать, что он использует кукисы. А так как кукисы не собирает только HTML страничка с HelloWorld, то ставить такой пакет необходимо (опять же, если вы сами свой не напишите).
GetPage, getResources - если вы не хотите пользоваться PdoTools (кстати один из плюсов pdotools, что он может разбивать на странички с ajax пагинацией)
Hits - количество просмотров на странице (типа данную статью посмотрели N раз)
Localizator - если будете делать мультиязычность, но лучше это делать через пространство имен и лексиконы, кому как нравится
MobileDetect - тоже важный, для меня мастхэв, компонент для отображения конструкции для мобильных или десктоп версии. Это, кстати, титанически и неоцененный компонент. С его помощью вы можете для мобильной версии вывести абсолютно другую верстку и контент. Скажем для компьютера вы выводите из сниппета все данные, и значения в чанке, а в мобильной версии в чанке укажете только самые важные данные или сокращенные. Работает просто - благодаря тегам standard и mobile. Единственное, говорят нужно постоянно обновлять, чуть ли не вручную.
phpThumbOn (или of) - для создания миниатюр (вы указываете с помощью него какого размера выводить загруженную картинку и он создает миниатюру)
SeoPro - для ленивых SEO мастеров программистов - по сути показывает, как выглядит ресурс в поиске, сколько символов нужно, сколько осталось.
tagElementPlugin - прикольное дополнение для быстрого редактирования сниппета в шаблоне, выделили и горячие клавиши нажали и тут же внесли изменения
TinyMCE Rich Text Editor - конечно же, редактор текста для ресурсов. Тру не тру, а текст для сайта лучше заполнять в редакторе. Чтобы он не стер вам коды modx или свой хтмл, необходимо будет отредактировать js файл в assests, но я забыл какой, погуглите сами :-) Еще раз ACE- редактор кода для сниппетов и чанков, TinyMCE - редактор текста для ресурсов.
Был еще ajaxmanager, который позволяет быстро загружать снипеты и чанки, не перезагружая страницы и менюшки, но после того, как он мне во все ресурсы коллекций продублировал код родителя - пришлось удалить и сидеть ночь, вытаскивая резервные копии.
и еще много дополнений, каждый найдет для себя свой или посмотрит рейтинг на modstore - один из самых крупных сообществ https://modx.pro/ со своим магазином дополнений.
Вот, например, список компонентов от моих любимых сайтов Riwkus и IlyaUtkin.
Когда вы начнете плотно общаться с modx вы сами выйдете на все эти сайты, найдете полезные для себя ресурсы, познакомитесь виртуально с такими гигантами разработок и гуру Modx, как Василий Наумкин, Илья Уткин - которые и являются авторами многих дополнений выше и сделали огромный вклад в развитие ModX, в частности в России. И многих других разработчиков крупных дополнений и сайтов. Кто знает, может и вы создадите свой проект и свое дополнение, которое станет популярным во всем мире. Modx позволит вам реализовать даже самый сложный проект. Ну а я не могу не выразить им всем отдельную виртуальную благодарность в рамках этой статьи.
Самое важное, я не поговорил о настройках modx. Системных, разумеется. Их там очень много и чтобы не давать вредные советы, начните изучение с официальной документации. https://docs.modx.com/current/ru/getting-started Еще раз, официальная документация на русском языке.
Теперь поговорим о сниппетах, а точнее о некоторых особенностях, а если быть еще точнее, о некоторых особенностях особенностей, с которыми мне пришлось столкнуться.
В любом сниппете можно вызвать другой сниппет или ресурс - $modx->getObject('modResource', ID); или $modx->runSnippet('название сниппета');
Да, для простоты и удобства, если шаблоны вы можете называть по-русски, например "главный шаблон" "вывод новостей", то все остальное лучше называть латиницей и не использовать тире. Вообще у меня при разработке на пхп сложилось негласное правило нигде не использовать тире и цифры, а только "_".
Что значит modResource выше? - Любой сторонник и программист ООП использует классы. Даже банально вызов mysql я использую через класс mysqli. Разумеется, у modx есть свои классы как для своих таблиц все они расписаны и есть во всех документациях, так и для механизмов. Все вызывается через $modx-> ...
В Сниппетах можно использовать значения из настроек. Например, доступ к API библиотеке, в виде ключа и секрета, я храню в настройках, а использую в сниппете, как getOption или вот практический пример, для удобства я создал еще одну Базу данных, куда подгружается контент из апи, чтобы не нагружать БД modx и разграничить их в доступе (вредный совет?), в системных настройках я прописал данные для соединения, а в сниппете
$modx->getOption('api_db_host',NULL,'default value'),
беру из опций значение api_db_host
Если же вы пишите свой компонент, то, разумеется, лучше, а точнее необходимо, создавать свои классы. Как для таких вот вещей, так и для класса таблиц, а потом их вызывать. Например
Структура запросов:
если мне необходимо я добавляю отдельный пакет
if(!$modx->addPackage('название', $modx->getOption('core_path').'путь до компонента и модели', '')) { return 'невозможно загрузить';}
запрос
$query = $modx->newQuery('Класс');
далее мы смотрим условия какие нам нужны, например:
$query->where(array( 'id' => '$userid',));
сортируем встроенными возможностями
$query->sortby('поле','DESC');
выставляем необходимый лимит
$query->limit(150);
Важно, для запросов к базе в modx очень большая библиотека xPDO, очень грамотная, очень продуманная. И да, я обещаю сам себе переписать некоторые костыли в формат xPDO. К сожалению каждый раз я пишу стандартный Mysqli вызов (тоже многие спорят xpdo груженный или нет).
самое страшное, с чем я намучался - Left Join , для него нам нужно сделать SELECT, через getselectcolums,
$query->select(array($modx->getSelectColumns('Таблица1', 'Таблица1'),$modx->getSelectColumns('Таблица2', 'Таблица2'),$modx->getSelectColumns('Таблица3', 'Таблица3','',array('поле1','поле2'))));
$query->leftJoin('Таблица1', 'Таблица1', array('Таблица1.id =Таблица2.user'));$query->leftJoin('Таблица3', 'Таблица3', array('Таблица1.id = Таблица3.id'));
Я немного отошел, от темы, подробно об этом в официальной документации - там же все стандартные запросы в modx
Кстати, у Ильи Уткина, очень много полезных шпаргалок по тонкостям работы в сниппетах
У него же можно и прочесть, что такое getcollection ($modx->getCollection('Класс', $query);) и примеры по любым запросам в снипетах
И Еще материал с хабра про запросы.
С этим всем я столкнулся с самописными чужими компонентами. Когда вы начнете сами писать свой код, свой компонент или свой плагин, вы сможете создать свою базу знаний по своим часто встречающимся работам. К слову, не поленитесь, если не хотите писать много комментариев в коде, создайте свой личный закрытый wiki по проектам, где описывайте свои часто встречающиеся методы работы, чтобы потом или вы сами легко разобрались, или переданный вами проект другой программист смог понять, почему у вас здесь стоит sleep(2); а тут XPDO, а не EXISTS (SELECT). рррр
Про вывод полученных данных из сниппета я уже писал, но еще раз. Не следует в сниппетах делать echo, print и т.д. для этого есть чанк. Чтобы в чанк что-то передать используется вызов $modx->getChunk , указываете название чанка или его айди и массив передаваемых значений. после формирования переданных данных делаем return.
Если это в каком-либо while, то вызываем с точкой (не утверждаю, что это правильно)
Пример
while ($data = $result_sql_m->fetch_assoc()) {$output .= $modx->getChunk('ListTeamId', array( 'name' => $data['name'], 'stadium' => $data['stadium'])); }
return $output;
Но можно и наоборот, чтобы в сниппет получить значение плейсхолдера также вызываем $modx->getPlaceholder
И да, еще раз, для гибкости написания используйте в сниппеты значения переменных, которые будете передавать из вызова сниппета (разумеется обработайте, если они не заданы). Это очень удобно и избавит вас от возможности плодить кучу сниппетов, которые будут отличаться лишь одним запросом или куском кода. Пример:
$p = isset($test) ? " $test : "";
$sql = "SELECT * FROM table WHERE p_id = $p";
а в ресурсе я, соответственно, вызываю [[!сниппет? &title=`заголовк` &p=`7`]]
таким образом я использую один сниппет для разных ресурсов, где только меняю параметр, что выбирать из таблицы. Это один из слабеньких примеров, разумеется возможности гораздо шире.
Ну и еще про чанки. В чанках, что получить переданные данные, мы используем +, например [[+name]]. можно использовать различные условия
[+numbooks:is=`5`:or:is=`6`:then=`Здесь 5 или 6 книг`:else=`Не уверен, сколько книг`]]
скрыть элемент, если условие верно
[[+numbooks:lt=`1`:hide]]
Можно выводить информацию о пользователе
[[!+modx.user.id]] - Выведет ID пользователя
[[!+modx.user.username]] - Выведет логин пользователя
Полное имя: [[!+modx.user.id:userinfo=`fullname`]]
Но самое главное, можно проверять пустое ли значение или нет [[+title:!empty=`[[+title]]`]] или [[+time:ifempty=`Пока нет информации `]]
Чтобы в чанке показать ваш TV параметр, добавляйте tv. , вот пример вывода изображения из дополнительно тв поля с использованием phpthumbon [[+tv.fc_logo:phpthumbon=`&w=50&h=50;`]]
и т.д. Огромный мануал по этим и всем фильтрам тут. Официально по пользователям - тут
Теперь про пространство имен. В modx есть очень полезная для разработчика вещь - это пространство имен. (здесь и далее - вызывается нажатием на шестеренку в админке). Вы можете создать свое окружение, где указываете пусть для всех файлов своего компонента (причем неважно пишите ли вы компонент или нет). Сейчас объясню, чем это полезно. равно как и наборы параметром, пространство имен позволит вам разграничить свое и чужое, поможет связать свои наработки в единое целое. Вы указываете пути до основных папок, где будут хранится статичные файлы, как например классы. Мой же кейс пример - указав пути, я создал лексиконы для основных языков и сделал перевод. Точнее как - api, к которому я обращаюсь, возвращал данные на английском языке. Не знав бы про пространство имен, я бы использовал конструкцию switch case, а значения передавал бы в функцию. например function localize($eng) { switch ($eng) { case 'IN PLAY': return играют';break; .... и так далее. Все это разрастается, неудобно, функция растет, растет время обработки, каждый раз все сверяется, ищется - ужас. Благодаря тому, что создал именно пространство, я в указанной папке "путь к ядру и путь к активам", создаю папку lexicon и в ней языковую ru. В ней же файл default.inc.php и перечисляю значения $_lang['IN PLAY'] = 'играют'; Круто и классно! восторг! А самое прикольное (но неправильное), что можно даже специфические к modx вещи заносить, например - текст, - все это будет прочитано и преобразовано как нужно. Но стоп, modx не был бы modx, если бы не было альтернатив. Не смотря на то, что составление словаря языка более правильно, вы можете это все сделать и в админке, в разделе Управления Словарями и выбрав созданное пространство имен, вы увидите все из файла, но и можете внести прямо из админки данные, не заходя по фтп в папку и не правя файл. Правда все это будет храниться в БД. А помните про наборы параметров? вы можете создать специфические для вас которые можно будет использовать в написанных вами компонентах (признаюсь, пока не осилил надобность).
Что мне еще пригодилось из гибкости - я всегда в modx создаю отдельный ресурс, который будет доступен только для администратора. И в нем я создаю табинацию и тестирую сниппеты в живом дизайне, не видимом для посетителей. Или же вывожу в удобном различную информацию для директора и даю ему этот доступ и для его авторизации вывожу пункт в меню (для меню я не использую автоматический wayfinder, а делаю его вручную). Очень часто сильно меняю внешний вид для мобильной и десктопной версии, хоть вебью вешай и в google play регистрируй как приложение.
А вообще теперь немного соединю воедино и опишу свой живой пример.
Итак, установив modx, установил необходимые мне пакеты, создал пространство имен, создал ресурс карта сайта, создал robots.txt, создал лексиконы. Создал необходимые шаблоны. Во всех шаблонах все, что в head, footer и в navi вынес в отдельные чанки. Создал несколько чанков для отладочних скриптов или стилей css. Начал со сниппетов. Сперва создал общий сниппет с важными и одинаковыми функциями. протестил его. Начал создавать последующие сниппеты, вызывая главный. Когда все работало без ошибочно, начал создавать свой класс, где в __construct записал основное для формирования. Создал чанки для вывода. Создал отдельный чанк для своих js. Создал тв параметры для определенных шаблонов. Создал коллекции для шаблонов. Один из тв полей - называется правая колонка. В него я буду вставлять сниппет, генерирующий информацию для правой колонки. Тв можно создавать разные, включая выборку с разделителем. О том как их выводить отдельный таб при создании (какой разделитель использовать). В виде коллекции обозначил необходимые мне столбики для возможности сортировки. Кстати, все свои сниппеты, чанки и тв, помещайте в категории. В ресурсах с помощью pdoPage вывел коллекции. В шаблонах указал, где какие сниппеты и параметры. Где необходимо создал логгирование (например, при ошибках получения информации из базы я логгирую в отдельный файл). Подключил необходимые мне api, настроил их. В чанках применил виды для мобильной и не мобильной версии (ввиду того, что современные планшеты fullHD и выше, я уже не вижу смысла для tablet делать отдельный вид). Проверил готовый сайт в pagespeed, gtmetrix, расстроился, заварил кофе, подумал, оптимизировал. Добавил сайт в вебмастеры, установил метрику, затаив дыхание смотрю на посещаемость. :-)
И не повторяйте моих ошибок, всегда делайте в копиях. а не "наживую". Не забывайте про безопасность и читайте литературу. Помните, modx обновляется, php обновляется, все обновляется. идите в ногу со временем, переписывайте и улучшайте код, не забывайте про бэкапы.
Это пока первое, что пришло в голову сохранить себе на сайт в виде шпаргалок и полезных ссылок. Ну и репозитории знаете же, основной для России - https://modstore.pro, основной для modx вообще - вот https://modx.com/extras/package/ (здесь вообще все дополнения, сортируйте по updated или downloads)
На справедливость и правильность кода выше не претендую, создал больше для себя, узнал количество просмотров, переписал еще раз.
