чанки modx что это

MODX чанки (chunks)

В прошлых уроках мы разобрали различный синтаксис модх парсера и fenom, а также перенесли HTML шаблон в MODX Revo (там можно скачать шаблон на основе которого пойдут дальнейшие уроки). Сейчас код шаблона статичный и чтобы что то поправить нужно править код — начнем это исправлять. В данном уроке разобьем код на отдельные части — MODX чанки, чтобы в будущем с кодом шаблона было проще работать.

Что такое

MODX чанки – это контейнеры для HTML/CSS/JS-кода (нельзя добавлять php-скрипты, вернее можно но они будут игнорироватся, для этого есть сниппеты). В чанке можно вызывать другие чанки, tv и сниппеты (можно вкладывать другие элементы).

Где хранятся

Чанки, хранятся в БД, в таблице modx_site_htmlsnippets (где modx_ — это префикс таблиц, который задан во время установки движка).

Как создать

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

Переходим во вкладку «Элементы» и кликаем:

Как вызывать

Выводятся чанки в шаблоне при помощи следующей конструкции:

Чанк с параметрами

Допустим у нас есть чанк «info», со следующим содержимым:

Он имеет 2 плейсхолдера: [[+name]] и [[+mesCount]]. Передать значения данным плейсхолдерам можно при помощи указания соответствующих параметров вызову чанка:

В результате, получим следующее содержимое:

Условия в чанках

Условия и другие phx фильтры / модификаторы MODX можно использовать в любых специальных тегах. Например, нам нужно вывести чанк в чанке (один или другой) в зависимости от идентификатора родителя текущего ресурса.

Внимание! Будьте осторожными, условия могут сильно увеличить время генерации страницы.

Натягиваем шаблон — логика разбивки шаблона

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

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

Выносим весь код шаблона (у на пока только один шаблон базовый, смотрите урок Перенос HTML шаблона в MODX Revo) в отдельный чанк tpl и вызываем чанк tpl в самом шаблоне [[$tpl]] или .

Если сейчас перейти на главную страницу — у нас не чего не поменялось — она также открывается с перенесенным html дизайном. Далее открываем чанк tpl и вырезаем из него весь контент который меняется в чанк tpl.1, а на месте вырезанного кода вставляем вот такую конструкцию [[$tpl.[[*template]]]] или тоже самое на fenom:

Для чего все это?

Тэг «template» выводит id примененного шаблона, а выше приведенная конструкция обращается к соответственному чанку и выводит его. Так мы в дальнейшем сэкономим кучу времени при внесении изменений в верстку сайта.

В дальнейшем мы будем создавать дополнительные шаблоны (для типовых страниц, для статей, для портфолио и т.д.), вызывать во всех будем чанк tpl — там у нас шапка, подвал и другие элементы которые присутствуют на всех остальных страницах. У каждого нового шаблона будет свой id, следовательно, мы будем создавать дополнительные чанки tpl.2, tpl.3, …, tpl.7 и уже в них вносить недостающий контент. Забегая вперед, у нас получится примерно такая структура.

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

Понравилась статья? Можно поблагодарить автора: отправив ему донат на

Источник

MODx: ресурсы, чанки и какие-то телевизоры

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

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

Статья ориентирована в основном на Revolution и отражает основные отличия в синтаксисе её от предшественницы, но для обратной совместимости буду вставлять иногда аналогии с Evolution.

Ресурсы (Resources)

Зачастую ресурс представляет собой страницу сайта. Кроме того существуют другие типы ресурсов, такие как, ссылки, сами файлы, и т.д. По умолчанию тип нового ресурса — документ, точнее представление одной страницы вашего сайта.

Шаблоны (Templates)

Параметры

Используются для вывода значений полей ресурса.
Вызов осуществляется так:

Полный список полей можно посмотреть в документации здесь.

TV параметры

ТелевизорДополнительное поле или переменная шаблона (TV) — это настраиваемое поле, или, точнее это настраиваемое поле для ресурсов MODx. TV-параметры используются для расширения стандартных полей ресурса. Каждый ресурс в MODx имеет определенное количество полей по умолчанию см. выше в разделе про ресурсы.
Если встаёт задача добавить некоторые дополнительные поля на страницу, например, выпадающий список названий месяцев или дополнительное изображение, или любой другой тип пользовательских данных, это можно сделать добавив TV-параметр соответствующего типа. MODx позволяет иметь практически неограниченное количество TV-параметров.
TV-тег заменяется соответствующим значением заполненным пользователем при обработке ресурса. Так же каждый такой параметр привязан к какому либо шаблону и может использоваться лишь в совокупности с ним.
Вызов осуществляется так:

TV параметры можно использовать как чанки добавляя им параметры. Например если есть TV-параметр ‘intromsg’ со значением:

Полный список фильтров можно посмотреть тут. Кроме того фильтры можно применять к чанкам и сниппетам.

Комментарии

Чанки (Chunks)

Чанк — кусок статического текста который можно встроить в шаблон, в другой чанк, либо вызвать в снипете. Чанк обладает теми же свойствами что и шаблон за исключением того, что не содержит TV-параметров и не может быть назначен ресурсу напрямую.
Чанк не может содержать какой-либо исполняемый код, но в нём можно вызывать сниппеты для вывода динамического контента.
Вызов чанка осуществляется так:

В чанк можно передавать параметры. К примеру мы создадим чанк с таким содержанием:

Сниппеты (Snippets)

Сниппет — ​PHP код который исполняется во время обработки шаблона MODx. Результат работы его может быть расположен либо на месте его вывода, либо в плейсхолдерах, специальных тегах определяющими куда поместить те или иные результаты.

Вызов сниппета осуществляется так:

Размещение плейсхолдера:

Как и чанки в сниппеты можно передавать параметры, например так:

Чтобы указать системе не кешировать сниппет требуется добавить восклицательный знак перед именем:

Синтаксис тегов

Каждый тег MODx Revolution может содержать в себе другие теги MODx. Для того что бы код был более менее читаем разрешено размещать код тега на нескольких строках придерживаясь такого общего формата (в скобках мои комментарии, которые писать не надо =)):

Источник

В этой статье рассмотрим понятие, назначение и применение чанков в MODX Revolution. Кроме этого познакомимся с тем, как выполняется обработка и управление чанками в сниппетах через API.

Что такое чанк

Например, чанк (его содержимое), который используется для вывода меню сайта:

Кроме этого чанки в MODX Revolution также используются в качестве шаблонов для вывода результатов работы сниппета.

Например, чанк (tpl.Tickets.list.row), который используется в качестве шаблона сниппета getTickets :

Внутри чанках, как и во многих других элементах MODX Revolution (шаблонах, TV-параметрах, полях ресурса), нельзя непосредственно размещать php-код. Размещение в этих элементах динамического содержимого осуществляется посредством вызовов сниппетов, которые исполняют хранящийся внутри них PHP-код.

Где хранятся чанки

Работа с чанками в админке MODX

Чанки в админке MODX Revolution расположены на левой панели во вкладке «Элементы».

Создание чанка

Кроме этого система MODX позволяет хранить содержимое чанка во внешнем файле. Для этого необходимо установить галочку в поле статичный, выбрать источник файлов и указать его расположение.

Редактирование чанка

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

Как использовать чанки в MODX

Вставка чанка в шаблон или содержимое ресурса осуществляется с помощью следующего тега MODX:

Во время обработки страницы, парсер MODX заменит тег чанка его содержимым.

Чанк и его параметры

Чанки в MODX могут иметь параметры. Например, рассмотрим чанк «intro», имеющий следующее содержимое:

Он имеет 2 плейсхолдера: [[+name]] и [[+messageCount]]. Передать значения этим плейсхолдерам можно с помощью указания соответствующих параметров вызову чанка:

В результате, получим следующее содержимое:

или в содержимом чанка:

Условия в чанках

Условия и другие фильтры MODX можно использовать в любых специальных тегах этой системы.

Например, внутри чанка в зависимости от идентификатора родителя текущего ресурса вывести один или другой чанк.

Но с фильтрами в MODX надо быть очень осторожными, т.к. они могут сильно увеличить время генерации страницы. Это происходит потому, что условия в тегах MODX работают не так как обычные условия в php. Например, в вышеприведённом примере оба чанка вызовутся, не зависимого от того какой идентификатор имеет родитель текущего ресурса. А уже только потом будет определяться какой из этих чанков будет выведен на страницу. Поэтому в MODX они и называются фильтрами. А теперь давайте представим, что в этих чанках есть вызовы некэшируемых сниппетов. В результате в не зависимости от идентификатора родителя текущего ресурса эти вызовы будут выполняться как в первом, так и во втором чанке. Это может привести к значительному увеличению времени генерации страницы и нагрузке на сервер. В таких случаях лучше фильтры не использовать, а выполнять эти действия с помощью сниппета.

Обработка чанка с помощью API

Чанки часто выступают в качестве шаблонов для вывода результатов работы сниппета. Обрабатывается чанк в сниппете через функцию getChunk().

Например, рассмотрим, как использовать чанк «rowTpl» в сниппете.

Чанк «rowTpl», имеет следующее содержимое:

Содержимое (php-код) сниппета, который получает все опубликованные ресурсы на сайте и выводит их в таблицу. Для вывода данных отдельного ресурса (одной строки таблицы, состоящей из 2 ячеек) используется шаблон rowTpl.

Источник

MODX Revolution встречает Fenom

В последнее время в англоязычном сообществе MODX много рассуждений на тему «как нам жить дальше». Все на перебой обсуждают грядущую (через несколько лет, полагаю) мажорную версию 3, а мы пока улучшаем своими дополнениями текущую.

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

Процедура не требует изменений в работе сайта, просто обновите pdoTools до версии 2.0 и можно использовать новый синтаксис. Самое приятное, что теги MODX отлично соседствуют с Fenom и работают вместе без каких-либо проблем. Простой пример для затравки:
Под катом огромное количество информации о парсере pdoTools, которую я еще ни разу не собирал в одном месте.

Принцип работы

Обработка чанка

В классе pdoTools для этого есть 2 метода, очень похожих на таковые в классе modX:

Варианты чанков

Итак, оба метода pdoTools поддерживают следующие виды имён чанков:

@INLINE или @CODE

Один из самых популярных вариантов — указание тела чанка прямо на странице. Например:

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

То есть, если вызвать сниппет на странице вот так:

Вы можете использовать фигурные скобочки в качестве обрамления плейсхолдеров во всех чанках pdoTools — он сам превратит их в [[+]] при загрузке.

По этой же причине у вас никогда не будут работать вызовы сниппетов и фильтров в INLINE чанках. Вот так работать не будет:

А вот так — без проблем

Помните об этом нюансе при использовании INLINE чанков.

Многие люди обвиняют MODX в том, что он не умеет хранить чанки в файлах и вынуждает лишний раз работать с базой данных. Это и неудобно для системы контроля версий, и медленнее.

С версии 2.2 MODX предлагает использовать для этих целей статичные элементы, но по ряду причин, этот способ всё равно может быть менее удобен, чем прямая работа с файлами.

pdoTools открывает такую возможность при указании @FILE:

Вы можете указать свою собственную директорию для файлов через параметр &tplPath :

Файл будет загружен из файла /core/elements/resources/mychunk.tpl от корня сайта.

@TEMPLATE

Этот тип чанка позволяет использовать шаблоны системы (т.е. объекты modTemplate) для оформления вывода.

Если указан пустой шаблон и в выбранных записях есть поле template с id или именем шаблона, то запись будет обёрнута в этот шаблон:

Это такой аналог сниппета renderResources.

При выводе шаблона можно указывать и набор параметров (как у сниппетов):

Тогда значения из этого набора будут вставлены в шаблон.

Обычные чанки

Это режим по умолчанию, который загружает чанк из базы данных:

Точно так же поддерживаются и наборы параметров:

Метод getChunk

Объявление этого метода выглядит так:

Третий параметр fastMode вырезает все оставшиеся необработанные плейсхолдеры, чтобы не было лишних тегов на странице. Если этого не сделать, то парсер будет пытаться рекурсивно разобрать эти теги (до 10 итераций по умолчанию), что может привести к замедлению работы.

Рекурсивный парсер — это одно из достоинств MODX и специально оставленные теги очень часто встречаются в логике работы сниппетов системы. Поэтому fastMode отключен по умолчанию и использовать его нужно, только если вы уверены в том, что делаете.

Парсер pdoTools не будет вызывать системный парсер, если смог самостоятельно разобрать все плейсхолдеры. Если же в чанке остались какие-то вызовы фильтров или сниппетов, то работа передаётся в modParser, что требует дополнительное время на обработку.

Метод parseChunk

А этот метод объявлен вот так:

Он также создаёт чанк из указанного имени, разбирая @BINDING, если есть, а потом просто заменяет плейсхолдеры на значения, без особых обработок.

Это самый простой и быстрый способ оформления данных в чанки.

Обработка страницы

Если pdoParser включен в настройках, то он вызывается и для обработки всей страницы при выводе её пользователю.

При использовании этого парсера все чанки и дополнения MODX обрабатываются немного быстрее. Всего лишь «немного» потому, что он не берёт на себя условия и фильтры, обрабатывая только простенькие теги, типа [[+id]] и [[

Помимо возможной прибавки скорости, вы получаете еще и новые возможности по удобному выводу данных из разных ресурсов.

Теги fastField

В конце 2012 года общественности был представлен небольшой плагин с добавлением новых тегов парсеру MODX, который затем вырос в компонент fastField.

Все теги fastField начинаются с # и дальше содержат или id нужного ресурса, или название глобального массива.

Вывод обычных полей ресурсов:

ТВ параметры ресурсов:

Поля товаров miniShop2:

Массивы ресурсов и товаров:

Можно указывать любые поля в массивах:

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

Теги fastField можно сочетать с тегами MODX:

Шаблонизатор Fenom

Поддержка шаблонизатора Fenom появилась в pdoTools с версии 2.0, после чего он стал требовать PHP 5.3+.

Он работает гораздо быстрее, чем родной modParser, и если вы перепишите свой чанк так, что в нём не будет ни одного тега MODX, то modParser и вовсе не будет запускаться. При этом, конечно, одновременная работа и старых тегов, и новых в одном чанке допускается.

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

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

Если вы планируете включить Fenom глобально для всего сайта, вам нужно проверить, на всех ли страницах он нормально работает.

Синтаксис

Для начала советую прочитать официальную документацию, а дальше мы рассмотрим синтаксис применительно к MODX.

Все переменные от сниппетов передаются в чанк как есть, поэтому переписывать старые чанки на новый синтаксис — сплошное удовольствие.

Для использования более сложных сущностей, в pdoParser предусмотрена служебная переменная , которая даёт безопасный доступ к некоторым переменным и методам системы.

Помимо этого вам доступны переменные:
<$_modx->config> — системные настройки

<$_modx->user> — массив текущего пользователя. Если он авторизован, то добавляются и данные из профиля:

<$_modx->context> — массив с текущим контекстом

<$_modx->resource> — массив с текущим ресурсом, это вы уже видели в примерах выше

<$_modx->lexicon> — объект (не массив!) modLexicon, который можно использовать для загрузки произвольных словарей:

Плейсхолдеры с точкой

Fenom использует точку для доступа к значению массива, а MODX обычно выствляет так плейсхолдеры из массивов. Соотвественно, для тегов [[+tag.sub_tag]] аналогов в Fenom не предусмотрено.

Поэтому для подобных плейсхолдеров вам необходимо использовать вторую служебную переменную — :

Вывод сниппетов и чанков

Переменная <$_modx>на самом деле представляет собой простой и безопасный класс microMODX

Поэтому сниппеты и чанки вызываются так:

Как видите, синтаксис практически полностью повторяет PHP, что открывает новые возможности. Например, можно указывать массивы, вместо JSON строк.

Если для вызова сниппета используется родной метод MODX, то для вывода чанков запускается pdoTools, и вы можете использовать все его возможности:

Примеры выше немного безумные, но вполне себе работают.

Управление кэшированием

В объекте доступен сервиc modX::cacheManager, который позволяет вам устанавливать произвольное время кэширование вызываемых сниппетов:

А еще вы можете запускать системные процессоры (если прав хватит):

Проверка авторизации

Так как объекта с пользователем в <$_modx>нет, методы проверки авторизации и прав доступа вынесены непосредственно в класс:

Остальные методы

Эти методы должны быть знакомы всем разработчикам MODX, поэтому просто покажу их на примерах:

Расширение шаблонов

Использование шаблонизатора Fenom позволяет включать одни чанки (шаблоны в другие) и даже расширять их.

Например, вы можете просто подгрузить содержимое чанка:

Подробнее про читайте в официальной документации.

Гораздо более интересная функция — шаблонов, она требует включенной системной настройки pdotools_fenom_parser.

Пишем базовый шаблон «Fenom Base»:

Он включает обычные чанки (в которых, кстати, обычные плейсхолдеры MODX от компонента Theme.Bootstrap) и определяет несколько блоков , которые можно расширить в другом шаблоне.

Теперь пишем «Fenom Extended»:

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

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

Тестирование производительности

Создаём новый сайт и добавляем в него 1000 ресурсов вот таким консольным скриптом:

Затем создаём 2 чанка: modx и fenom со следующим содержимым, соответственно:

И добавляем два консольных скрипта тестирования. Для родного парсера MODX

Так как pdoTools понимает оба синтаксиса, для него 2 теста — в режиме тегов MODX, и в режиме Fenom.
В скриптах есть указание limit = 10, дальше в таблице я привожу цифры с его возрастанием:

А теперь, давайте немного усложним чанки — добавим в них генерацию ссылки для ресурса и вывод menutitle :

Как видите, обработка чанков через pdoTools во всех случаях быстрее.
При этом заметно, что у чанков Fenom есть некоторый минимум для старта, который обусловлен необходимостью компиляции шаблона.

Заключение

Большое спасибо хабраюзеру aco за замечательный шаблонизатор!

Источник

MODx Revo workflow. Организация рабочего процесса, контроль версий и деплой

Все основные элементы системы MODX, такие как чанки, шаблоны, сниппеты и т.д, хранятся в БД, из этого появляется проблема осуществления контроля версий за этими элементами, а также сложности с разделением на development и production версии сайта.

Содержание

Введение

На момент написания этой статьи я имел опыт веб-разработки чуть более года. Мне повезло, я начал свой путь в этой сфере именно с MODX Revo, но несмотря на все плюсы этого фреймворка, со временем я начал сталкиваться и с минусами. Пока что я не работал в команде над большими сложными проектами и не знаю как обычно люди справляются с указанными выше сложностями. В интернетах я не нашёл какого-либо конкретного решения, и это поспособствовало созданию своего workflow, который я хочу представить в этой статье. Сразу оговорюсь, я не придумал ничего принципиально нового, а просто собрал разбросанные по интернету куски информации в одно руководство как устроить свой рабочий процесс при работе с MODX Revolution.

Что нам понадобится.
— Git
— npm + Gulp
Для работы я использую IDE PHPStorm.

Development и Production версии сайта

Не буду долго рассуждать и скажу сразу, я предлагаю использовать один экземпляр сайта, в котором мы воспользуемся механизмом контекстов MODX Revo. Стандартный контекст web будет содержать релизную версию сайта. Плюс мы создадим ещё один контекст dev, работу с которым вынесем в поддомен. Таким образом, нам нужно:
— домен example.com, работающий в контексте web
— поддомен dev.example.com, работающий в контексте dev
При деплое мне нужно, чтобы изменения сделанные в контексте dev, каким бы то ни было образом сливались в web.

Создаём контекст dev

Эта часть работы начинается с того момента, когда у вас уже установлен движок и необходимые компоненты и настроены доменные имена, т.е. при обращении по обоим адресам example.com и dev.example.com открывается одна и та же стартовая страница MODX (корневая директория обоих доменов общая).

Теперь заходите в админ-панель → системные настройки → контексты и создайте новый контекст. Ключ укажите dev, имя — как угодно, я назвал Development. В контекстном меню слева у вас появится новый контекст. Первым делом создайте для него ресурс, а потом зайдите в настройки контекста (правой кнопкой по контексту → редактировать → настройки контекста) и задайте настройки
— site_start
— error_page
— unauthorized_page,
указав в них ID созданного ресурса. Это нужно, чтобы система не падала с ошибкой, если при работе в контексте dev не будет найдена какая-либо страница.

прим. Я создал контекст dev (Development) и переименовал стандартный контекст Website на Production, ключ стандартного контекста остался прежним — web.

Теперь в папке core/elements/common/plugins/ (создайте необходимые папки) создайте файл switchContext.php со следующим содержимым

Поясню, что делает плагин. При работе с сайтом через админку, т.е. в контексте mgr, ничего не делает. При работе с фронтальной частью сайта на домене dev.example.com переключает контекст на dev. При работе на фронт-енде на основном домене тоже ничего не делает. Но в случае, если исполнение скрипта каким-то образом попадает в default, то выводит ошибку в лог. Такое может случиться, например, при переносе сайта на новое доменное имя, и это сообщение призвано облегчить жизнь тому разработчику, который будет разбираться, почему после переноса ничего не работает. Когда я проверял описанную здесь схему работы на удалённом сервере, я как раз забыл исправить доменные имена в этом плагине и по ошибке в логе сразу понял что не так. В очередной раз сам себе сказал «Спасибо».

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

Через админ-панель создайте новый плагин, который будет подтягивать созданный файл

повесьте запуск плагина на событие OnHandleRequest.

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

Контроль версий

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

При этом, мы будем также контролировать файлы, получаемые в результате сборки (assets/web/ и core/elements/web/), чтобы иметь возможность откатиться после неудачного деплоя. Такая структура папок будет объяснена ниже.

Схема работы

Когда я выше говорил о Develpoment и Production версиях, я предложил использовать один экземпляр сайта. Это также предполагает отсутствие его локальной копии (не путать с локальным git-репозиторием проекта). Мы будем править файлы на локальной машине, но при этом в нашем локальном рабочем каталоге будут только файлы и папки, не относящиеся к движку. Мы будем вносить правки в имеющиеся файлы, затем делать upload этих файлов на сайт. После выполнения какой-либо задачи делаем коммит в локальном репозитории, после чего, если нужно, пушим изменения на GitHub, или где вы там собираетесь держать проект.

Теперь я расскажу, как я предлагаю устроить версионирование основных элементов системы — шаблонов, чанков, сниппетов и плагинов, и описать рабочий процесс через IDE PHPStorm в связке с панелью администрирования MODX. В этом нам поможет легендарный pdoTools и используемый им шаблонизатор Fenom.

Как известно, парсер pdoTools позволяет подключать внешние файлы прямо в теле чанка, и именно эта фича лежит в основе всего устройства контроля версий.

Необходимо выставить настройке pdotools_fenom_parser (Использовать Fenom на страницах) значение Да

Компонент pdoTools имеет системную настройку pdotools_elements_path со значением по умолчанию elements/. Что ж, соответственно, создаём папку elements/ (если ещё не создана) в папке core/ движка и внутри создаём следующую структуру папок:

Собственно разработка ведётся в папке dev/ при этом действует важное правило для всей команды: «Никто и никогда не должен проводить никакие правки в папке web/». При деплое всё содержимое папки dev/ копируется в web/ с помощью Gulp. Папка common/ содержит общие для обоих контекстов файлы, например, плагин переключающий текущий контекст, описанный выше.

Такая структура папок позволяет при подключении внешних файлов при помощи шаблонизатора Fenom использовать значение плейсхолдера [[*context_key]] примерно так

В первой строке мы складываем в переменную $ctx ключ текущего контекста (dev или web), а во второй строке используем это значение в пути к файлу. Это и позволяет иметь две версии сайта на одном движке.

прим. Подключения чанков в файле шаблона

Помимо файлов, содержащих основные элементы системы, нам также нужно вести контроль версий файлов вёрстки и js. Как правило, эти файлы расположены в папке assets/ следующим образом.

По старой схеме предлагаю создать следующую структуру

Связываем ресурсы с шаблонами

Шаблоны создаём в папке core/elements/dev/templates/, в которых подключаем чанки из папки core/elements/dev/chunks, используя синтаксис шаблонизатора Fenom. При этом, создавая файл шаблона, мы также должны создать соответствующий ему шаблон в админ-панели. Только мы не будем создавать статический шаблон, так как не можем указать конкретный путь к файлу, потому что он зависит от контекста, в котором шаблон используется. Вместо этого в теле шаблона мы пропишем одну единственную строку

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

прим. Подключение файла шаблона

Создаём плагины

При таком подходе разработки следует отдельно оговорить внедрение в систему новых плагинов.
Аналогично ситуации с шаблонами, плагины создаём в папке core/elements/dev/plugins/, в которых пишем логику работы плагина. Далее, заходим в админ-панель и создаём соответствующий ему плагин (НЕ статический!), в котором подключаем файл плагина через include следующим образом

Не забываем, конечно, в админ-панели задать события, на которые вешается плагин. Если нам нужен плагин, общий для обоих контекстов, в переменную context складываем значение «common», как это было сделано в плагине switchContext.

Деплой

Приводу пример gulp файла. Здесь я описал лишь одну задачу для копирования файлов из core/elements/dev в core/elements/web/, остальные таски, наверняка, сможете написать и сами.

т.е. переводим продакшн-файлы в состояние до сборки и начинаем разбираться что не так.

прим. Пример дерева коммитов.

Выше описанное относится к деплою шаблонов, чанков и сниппетов, а также файлов вёрстки, но что же у нас с ресурсами?

А что с ресурсами?

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

В dev контексте вы создаёте соответствующий контейнер, добавляете пару экземпляров архивных новостей, создаёте чанки, если нужно шаблон и т.п. В результате на домене dev.example.com появляется новый раздел. После одобрения заказчиком, вы производите деплой, описанный выше, но нового раздела на продакшене, конечено, не появится, хотя все файлы будут приведены к необходимому виду. Конечно, это произойдёт, потому что созданный раздел (имеется в виду совокупность созданных ресурсов) будет находиться в контексте dev и не будет доступна в контексте web.
— И что делать?
— Копипаст, товарищи, увы.
А точнее перенос. Мы просто переносим созданный раздел в контекст web, а после повторно создаём его копию в dev, чтобы структура dev-версии сайта соответствовала продакшену.
Да, полностью избавиться от копипаста у меня не получилось.

Заключение

Таким образом, мне удалось организовать рабочий процесс, который бы устроил, в первую очередь, меня. В реальной работе эта схема ещё не применялась, поэтому подводных камней пока не обнаружено. Может быть более профессиональный взгляд читателей увидит существенные недостатки, поэтому прошу написать об этом в комментариях. И кстати, это моя первая статья, и я бы хотел узнать насколько доступно и ясно мне удалось изложить свои мысли, буду благодарен за конструктивную критику.

Источник