Создание правильных тем для MODx. Мой опыт.

Всем привет.

Данная статья может вызвать резкую вибрацию в районе точки G и полыхание седалищ у высококвалифицированных специалистов MODx и некоторых других людей по следующим причинам:

1. Я не графоман и не жажду писать орфографически правильно, но и по албанский стараюсь не писать.
2. Я не считаю себя великим разработчиком и каждый день стараюсь совершенствоваться.
3. Я имею право на свое мнение и именно им хочу поделиться. Принять его или нет — ваш выбор.
4. Я пишу MODx — потому что это красиво, а я хочу чтобы MODx был красивым.
5. Будет много букв, осилят только самые стойкие.

Посему прошу отнестись к данной статье «с пониманием» и не разводить срач в комментах. Погнали!


Предисловие
Я довольно долго работал с системой под названием Wordpress. Некогда это была довольно приятная система и работа с ней не вызывала желания пойти топить котят. Но времена меняются, WP стал конструктором, где клиент страждущий экономить на всем — создает сайт, покупает за 15-20$ (или качает ломанную) тему и ждет что за 500 (условно 500) рублей, ему сделают «несколько небольших правок», после которых этот экономный клиент наконец-то получит веб-сайт своей мечты.

На деле же, эти несколько небольших правок приводят тебя в мир дивных документаций готовых 20-ти долларовых тем. И хорошо если тема действительно качественная и есть хорошая документация, которая позволит тебе понять, как кастомизировать эту тему без правки исходников. Но мы живем в жестоком мире, где зачастую нет не то что документаций, а даже сраных комментариев в файлах темы. И даже при наличии лучшей в мире документации, у разработчика уйдет тонна времени — чтобы понять что-то в этой теме и реализовать правки клиента.

При переезде с WP на MODx, я наконец-то набрал полные легкие воздуха. Среда разработки в MODx более дружелюбна к разработчику и даже сторонние компоненты имеют некий единый стандарт, который требует MODx. И что самое приятное, многие разработчики делились своим опытом, своими наработками и своими знаниями с другими людьми. Благодаря им, мой путь работы с MODx привел меня к тому, что буквально через 2 недели после переезда с WP на MODx, я собрал свой первый магазин и сделал это за денежку (пусть и небольшую). Этот сайт уже 3-й год стабильно работает без моей опеки. Пережил уязвимости MODx, имеет далеко не базовый функционал. Что-то я решил платными компонентами, где-то пришлось писать свои классы доставки и оплаты. Но суть в том, что на базе экосферы и стандартного функционала MODx я сделал рабочий магазин, который по сей момент приносит клиенту деньги. И при разработке этого магазина не пострадал ни один котенок!

Сейчас я немного стал уходить от работы с MODx и решил напоследок поделится своим опытом с другими разработчиками. Надеюсь этот опыт хоть сколь-нибудь будет вам полезен.

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

Спустя какое-то время, я заметил компонент который написал Илья Уткин — siteExtra. А спустя время я через поиск нашел статью Васи про его среду разработки которая называется App, и даже посмотрел видео-презентацию с митапа в Минске. Объединив эти два решения, я создал свой билдер, с помощью которого я создавал сайты.

Я написал огромное количество резолверов для работы с MODx. Это и резолвер для кастомизации форм, для создания TV (migx) на лету, редактирование и создание виджетов, резолвер для работы с источниками файлов, резолверы для работы со сторонними компонентами, резолверы для создания и настройки групп пользователей со всеми правами, настройками и зависимостями а так же создание и удаление пользователей на лету и т.д. У меня есть даже сайт, который практически целиком и полностью создан без админки.

Написание того же резолвера на создание пользовательских групп занимает больше времени чем создание оных через админку, однако написав такой резолвер лишь 1 раз, впоследствии вы не только значительно сэкономите время на создании всех этих групп и других вещей, но и сможете версионировать эти действия через Git. Согласитесь, на больших проектах, особенно на тех, которые у вас на поддержке — это не будет лишним...?

Так вот, однажды, я захотел изменить дизайн своего личного сайта. Так вышло, что вместе с дизайном мне бы пришлось поправить пару сниппетов, создать один новый, а другой удалить. Добавить пару новых источника файлов и т.д. И я взглянул на билдер и понял, что я могу сделать новый дизайн сайта в рамках текушего билдера. Но придется некоторые манипуляции делать ручками. А это не очень хорошо! И я начал продумывать варианты, при которых удаление и установка новой темы — не потребует рукаблудства. А что если новая тема не зайдет и будет хуже? Я хочу иметь возможность вернуть старую тему…

Я начал продумывать возможные этапы и варианты смены тем на лету, без необходимости внесения масштабных правок. Удалил текущую тему, установил новую, доработал шаблон, раскидал TV поля в новом шаблоне — профит.

Этап 1. Разбор сайта на MODx.
Что же такое сайт на MODx? Зачастую это:

• Ресурсы (тикеты, товары, категории и т.д.), менеджер файлов — то с чем работают менеджеры.
• Шаблоны, чанки, сниппеты, плагины, категории, системные настройки — то, с чем работать должны именно разработчики.
• Компоненты, Источники файлов, TV, контексты, кастомизация форм и т.д. — все, что делает возможным расширить базовый функционал сайта.
• Шаблон — html,css,js.

Я не буду сейчас расписывать каждую функциональность MODx (да там есть еще куча других вещей). Я описал самую базу, то, что составляет наверное 85-90% всех работающих на MODx сайтов. А теперь проговорим каждый пункт словами.

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

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

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

Этап 2. Что-то непостоянно, а что-то вечно.
При разработке нового дизайна, вы скорее всего не захотите удалять TV, потому что зачастую эти поля расширяют стандартные ресурсы и в них хранится контент. И ладно если TV не много, а если у вас их штук 100? Куда проще делать новый дизайн (тему) заранее продумывая распределение контента в нём.

Вы не захотите удалять источники файлов, потому что на сайте наверняка загружено множество файлов (возможно через те же TV) и потеря путей и файлов, не самый оптимальный вариант.

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

Кастомизация форм — очень удобная штука, но…

Этап 3. Общий стандарт.
Проговаривая все эти вещи, я понял одну простую истину. MODx слишком многофункционален и слишком расширяем, чтобы создавать темы просто так. В одной теме будет 15 кастомизаций форм, в другой их будет 45. В одной теме будет 32 источника файлов, в другой будет 1. Таким образом — я выработал стандарт по которому должна создаваться базовая тема для MODx:

1. Ресурсы и медиа-файлы неприкасаемые. Тема не должна затрагивать создания или удаление медиа-файлов, источников файлов и ресурсов. Этим занимаются менеджеры.
2. Шаблоны, чанки, сниппеты, плагины, категории, системные настройки. Это то, что может и должно изменяться от темы к теме. При удалении темы, все перечисленные типы элементов этой темы должны быть так же удалены или сброшены к значениям по-умолчанию.
3. TV. Создаются и устанавливаются руками через административную часть. Зачастую, при разработке нового дизайна, контент сайта остается, значит и TV не должны удаляться.
4. Компоненты. При установке новой темы, необходимо сверять зависимые компоненты, с теми, что установлены на вашем сайте. Если компонент на вашем сайте отсутствует, тема его установит. Если он уже есть — ничего не должно происходить. Если компонент есть на вашем сайте, но в новой теме отсутствует — его можно удалить руками.
5. Контексты, кастомизация форм. Очень гибкий функционал. Необходимо дорабатывать тему на предмет создания контекстов или кастомизаций форм. В базовом стандарте темы идут без данного функционала.

Немного оффтопа чтобы все поняли о чем я говорю на данный момент статьи. У вас есть сайт на WP, статьи в базовом функционале лежат в категории «Записи». Установив новую тему, вам лишь нужно указать, где в шаблоне эти записи выводить (зачастую это указано по умолчанию).

Но конечно в WP не все ограничивается базовыми категориями. Иногда для статей создают кастомную категорию, для новостей свою кастомную и т.д. В MODx ровно так же. Базовый контент лежит в базовых полях, TV расширяют поля страницы и как и в теме на WP, вам нужно будет редактировать шаблонизацию для вывода кастомных данных.

Даже в таком конструкторе как WP — нет волшебной кнопки «make pizdato».

Этап 4. Итог мозгоштурма.
Разрабатывая любую новую тему, мы должны задавать только базовые настройки и значения. Чтобы клиент купив тему, смог её установить и работать с базовым функционалом без привлечения разработчика. Если клиент захочет удалить тему, то тема должна удалить все свои настройки и объекты, которые были установлены вместе с ней (шаблоны, чанки, плагины, сниппеты, системные настройки и т.д.). Это нужно для максимальной очистки MODx, перед установкой новой темы.

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

Этап 5. Смены темы на моем личном сайте. Теория.
У меня есть мой личный сайт (ссылка в моем профиле), он был создан на моем старом билдере и как я уже написал ранее, я захотел изменить тему. Так как создавал я этот сайт без планов смены тем на лету, для того чтобы установить новую тему, было мало просто интегрировать новую верстку. Пришлось бы так же удалять текущие плагины, сниппеты, настройки, компоненты и прочие элементы системы.

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

Удалил тему — удалились все настройки темы. Остался контент, остались еще какие-то данные (пользователи, компоненты, медиа-файлы). Установил тему — шаблонизируй и радуйся.

Этап 6. Смены темы на моем личном сайте. Практика.
И так, на моем сайте нет тем а я хочу новый дизайн. Там будут новые сниппеты и парочка новых плагинов. Там будут свои шаблоны и там будет правка системных настроек. Что я сделал:

1. Я взял чистый билдер (свой старый) и сверстал сначала HTML-шаблон. Т.к. я сразу знал какие поля мне нужны (я знал сразу сколько у меня контента, что я хочу оставить а что удалить), я заранее сверстал шаблон именно для своего сайта (хотя мог бы сделать его универсальным).

2. Далее я интегрировал новый шаблон в билдер (создал шаблоны и чанки с разметкой нового дизайна) и прописал логику для сниппетов и плагинов. Все это я делал на абсолютно пустом тестовом сайте на MODx. Боевой сайт пока что работает на старом шаблоне.

3. И вот у меня уже есть сайт на новой теме. Установку всех компонентов я прописал автоматически, все TV поля я раскидал в шаблонизаторе и даже не стал их создавать на тестовом сайте. Создал все категории для элементов, навел порядок в их структуре. Разобрался с кастомизацией форм, написал резолвер который создает необходимые правила, забил хрен на словари (это всегда можно будет вспомнить и поправить).

4. И тут казалось бы — самое время пробовать установку новой темы, но я наткнулся на проблему, о которой ранее почему-то не подумал. У меня более 100 ресурсов на сайте и около 10 различных шаблонов. Руками удалить шаблон привязанный к ресурсу я не смогу. Но даже если я удалю его программно, как мне проставить новые шаблоны-то? А если ресурсов будет 10.000? 50.000 или 100.000?

Тут я нашел два варианта:

i. Написать простенький код для смены шаблонов по родителю или любому другому критерию и запустить его в консоли.
ii. Batcher — невероятно крутое решение для массового редактирования ресурсов, с очень гибкими фильтрами и сортировкой. Справится любой менеджер без участия программиста.



5. Сделал копию боевого сайта, удалил ручками все элементы (шаблоны удалил скриптом), удалил все кастомизации форм, удалил почти все компоненты и поверх старого пакета с темой, поставил новый. Оставил только контент, TV поля и медиа-файлы. Перед удалением шаблонов прописал схему их замены на новые, установил Batcher, быстро назначил новые шаблоны. И это был тот самый случай, когда все установилось с первого раза без проблем и ошибок. Даже мелких косяков не было.

После этого я перевел боевой сайт в режим «Under construction» и сделал все то же самое что и на тестовом. Включил сайт и он продолжил работать на новой теме.

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

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

И чо?
Если кто-то еще не понял зачем оно надо, объясню. Я работаю с клиентами и часто получаю от них задачи, о которых я через 2 дня уже забываю и приходится вспоминать что и где я делал. Возможность версионирования сайтов — это ключ, которым должен обладать каждый современный и уважающий себя разработчик. Ну а MODx — при всех его минусах, позволяет это делать с помощью пакетов. Согласитесь, когда вы получаете задачки по работе с сайтами на MODx, было бы отлично видеть историю его правок. Так, как это сейчас реализовано с теми же компонентами.

Да, пусть правки будут видны не все. Но все ведь и не нужны… ?!

Ну и возможность смены тем, а значит — потенциально покупки и продажи тем. Главное — выработать общую концепцию и стандарты создания таких тем. Понятно, пока что все это лишь мои мысли и тут у каждого будет свое мнение. Кто-то посчитает все это бессмысленным бредом. Но кому-то моя идея понравится. Мы люди цивилизованные и я всегда рад получить фидбек или обсудить плюсы и минусы такого подхода создания тем. Кто знает, возможно это даст инерцию к созданию бесплатных или платных тем, с возможностью гибкого редактирования и быстрой смены на другую тему. Я думаю клиенты без знаний программирования будут рады возможности смены тем, по очень близкой идеологии с WP, но более правильной (как я считаю).

Если данная статья наберет определённое количество позитивных откликов, я напишу еще одну, где наглядно покажу как я с помощью своего нового билдера, реализую смену темы сайта на MODx на лету…