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

В этом уроке будет рассказано как упаковать дополнение в транспортный пакет, который затем можно будет легко установить через «Управление пакетами». Упаковывать будем всё, что относится к, разработанному нами, дополнению: сниппет; файлы из core/components/ и assets/components/; действия; пункт в меню и пространство имен нашей CMP (страницы компонента); значения по умолчанию для сниппета с поддержкой интернационализации (i18n). А также добавим резольвер, который создаст пользовательские таблицы в БД.

Данная статья в большей части является переводом урока с официального rtfm, а именно компонента «Login», но с вставками переводчика. На лучший перевод не иду, но суть в итоге должна быть понятной. Тем не менее, перевода на русский я до сих не нашёл.
Данный урок, хоть и называется «базовым», имеет много взаимосвязанных частей. В данном уроке мы будем обсуждать, какие страницы надо создать, какие чанки (фрагменты кода) и сниппеты нужно опубликовать на страницах для полноценной авторизации пользователей.

Номера в скобках — это ID ресурсов. Это page_id, у вас он может отличаться. Здесь они выбраны просто для удобства.

Задумали мы с другом один сервис, решили реализовать на MODx Revolution. Причины такого решения, равно как и сам проект лежат далеко за рамками этой статьи, возможно (читай обязательно) я напишу об этом позже. Сегодня я хочу поведать, как решалась конкретная задача.

Итак, необходимо реализовать “социальный” элемент в виде личных сообщений юзеров. Поиски готовых дополнений для MODx ничего толкового не дали, как и гугление на эту тему. Правда, некие проблески все-таки были, но явно не в том направлении. Ну совсем не хотелось использовать ресурсы (которые документы) не по назначению. И тут я обратил внимание на то, что в самом MODx, что называется “из коробки”, уже реализована система сообщений, с одним маленьким “но”: пользоваться ими можно только в админке, куда пускать юзеров вообще не предполагается. Даже никаких намеков на сниппеты для использования во фронтэнде. Тут-то я и решил копнуть глубже.

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

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

По мне неясным причинам (если кто-то значет истинную причину и почему ее не устраняют — скажите, буду очень благодарен), при использовании Opera для администратировании сайта на MODX Revolution в момент сохранения ресурса появляется окно «вечной» загрузки.

Это окно можно убрать одним способом — обновив страницу. А так как административная часть работает по принципам «AJAX» это очень замедляет работу.

Баг проявляется на момент написания статьи в последней версии Opera 11.10, MODX Revolution 2.1.5-pl (advanced) и Ext JS Library 3.4.0.

Предлагаю временное решение этого вопроса (до выхода новой версии Ext JS Library в состав пакета MODX Revolution или пока MODX (или Opera) это не пофиксят).

Топик рассказывает о настройке быстрого и недорогого хостинга для MODx Revolution. В принципе, вещи тут описаны общие, так что информация подойдет для любой CMS. Позже была смонтирована и видеоверсия этой инструкции.

На всякий случай, приложу видео, как должна работать админка MODx Revo.

Для быстрой и комфортной работы желательно:

• Быстрый браузер — Google Chrome. Админка Revo работает в нем молниеносно
• Хороший интернет-канал. Тут без вариантов, нужно всем и всегда.
• Качественный хостинг — про него и пишу.

В конце поста есть ссылки на скрипты для автоматической установки MODx с созданием юзера, хоста nginx, процесса php5-fpm и базы дынных.

Начинаю делать серию видеоуроков по созданию интернет-магазина на MODX Revolution + Shopkeeper. Пока видео без голосового сопровождения, но думаю и так будет всё понятно.
Из первой части вы узнаете как:

• Установить и настроить MODX Revolution;
• Создать шаблоны сайта;
• Создать меню;
• Создать и настроить контекст для каталога товаров;
• Установить Shopkeeper.

Третьего дня задали задачу — написать скрипт для переезда с Битрикс на MODx. Задача показалась интересной, тем более, что с Битрикс толком ни разу не работал.



Ничего не могу написать про саму систему, так как даже в админку не заходил — работал только с базой данных. Кстати, это 322 таблицы, против 68 у MODx.

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

Абсолютно бесплатно, на сутки вы получаете свежеустановленный сайт на облаке Selectel с админскими правами.
Это как бы демо-сайт, только для для одного человека и с возможностью полноценной работы. Доступ вы получите в течении 10 — 15 минут через какое то время, ибо — Хабраэффект.

Через 24 часа этот сайт будет автоматически удален.

Основная задача сервиса — дать спокойно ознакомиться с отличной системой, а также хоть немного развеять мифы о «тормознутости» и «сложности».

Хочу рассказать о новом плагине для MODX Revolution для редактирования текста (включая значения доп. полей TV) во внешней части сайта.
Используется Aloha Editor (aloha-editor.org).

Что-то блог MODX на Хабре совсем зачах, нужно его немного оживить. Хочу представить вам свой компонент, который недавно был практически полностью переписан и расширен.

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

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

Перепост из моего блога — может кому-нибудь пригодится

Начал делать новые проекты на Revo — переход с Evo происходит со скрипом, т.к. в Evo помнил все наизусть. После установки голой системы необходимо развернуть полезные пакеты, а так же немного их модифицировать, чтобы приступить к верстке и программированию. Однако дефолтные установленные пакеты при всей их гибкости не всегда помогают — в частности решить задачу альтернативной разметки строк меню.

Когда собирался писать свой топик, ломал голову куда же его писать? С одной стороны часть сайта написана на MODx, с другой стороны другая часть написана на LiveStreet, а с третьей стороны это такие костыли, что в пору в Ненормальное программирование писать. Оказалось, что Хабр готовился к такому повороту событий и сделал возможность писать сразу в несколько блогов, за что ему отдельный респект! :-)

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

Но вспомнил я про LiveStreet, о котором слышал давно-давно, и то, что он позиционируется как легкий и быстрый клон Хабра. И вот решил я отдельно социалку поднять на LS и увязать его с моим основным сайтом на MODx. LiveStreet установил и запустил за пару часов (это мое первое знакомство с этим движком).

Тут от товарища поступил вопрос:

День добрый!

Читаю статью про дружбу ModX и LS, и решил спросить вопрос, который сам никак в ModX не могу решить — как реализовать логику работы Revo в зависимости от текущего поддомена основного сайта?

Я вижу на pro-cent.ru, что в поддомен выносится название города (http://kaliningrad.pro-cent.ru/). ModX как-то помогает в обработке этого, или у Вас все руками и своим кодом сделано?

Решил дать ответ в публику, наверняка кому-нибудь тоже пригодится.

Совершенно неожиданно выдали приглашение на бету MODX Cloud. Это широко рекламируемое развитие MODX Revolution с невиданными возможностями. А на самом деле, продвинутый shared-хостинг с единой панелью управления кучей сайтов на облаке.

В перспективе, это позволит нам не распыляться, а централизованно обновлять сайты, бэкапить и просто приятно работать с клиентами.

Пока Cloud в состоянии закрытой беты, но мне удалось поглядеть — и вот обзор (в посте много кликабельных картинок).

При установке редактора TinyMCE (на момент написания статьи версия: 4.3.3 pl) по умолчанию он настраивается таким образом, что в нем нет возможности добавлять в редактируемую область разметку таблиц. Видимо это сделано для компактности и «дружелюбности», чтобы не пугать пользователей своими многочисленными возможностями (другого объяснения я найти не смог).

И так, вот что необходимо сделать, чтобы в редакторе TinyMCE в MODx Revo появились элементы редактирования таблиц:

1. Перейдите к настройкам системы ("Система" -> "Настройка системы");
2. Отфильтруйте параметры по компоненту "tinymce";
3. Найдите параметр "tiny.custom_buttons3" (цифра в конце означает строчку вывода кнопок на панели TiniMCE, на свое усмотрение можно выбрать другой аналогичный параметр "tiny.custom_buttonsN"). Добавьте в значение параметра слово "tablecontrols";
4. Для того чтобы кнопки заработали, необходимо подключить плагин для работы с таблицами. Для этого в параметре "tiny.custom_plugins" нужно добавить к списку плагинов — "table".

Данный топик наверняка будет полезен тем, у кого довольно большие проекты на MODx Revolution, так как с обычными сайтами-визитками достаточно и стандартных методов работы а-ля $modx->getObject(), $modx->getCollection() и т.п. И данные методы по сути своей не просто работа с базой данных, а еще и с объектами MODx.

При работе с большими проектами методы а-ля $modx->getCollection() для нас не лучшее решение по двум причинам:
1. Перерасход ресурсов. Данные методы не просто получают данные из БД, но еще и создают инстанции получаемых объектов. В данном случае получая информацию о 10000 документов, мы получаем 10000 объектов modResource, что не очень круто.
2. Осложняется задача подсчета получаемых записей. Помимо прямых сложностей подсчета еще на уровне запроса, даже если вы получите 10 записей одного и того же документа (к примеру), MODx вернет вам как результат только один объект modResource. И хотя часто такое устроит многих программистов (они получили уникальные объекты и рады), кого-то это не устроит, так как опять же происходит перерасход ресурсов, а по конечному результату сразу и не видно, что запрос не оптимизированный.
К тому же при работе на крупных проектах нам чаще всего нужны не сами объекты, а только информация (записи из базы данных).

Описанные здесь методы работы с БД ставят 2 задачи:
1. Дать бОльшую гибкость в написании запросов к БД.
2. Придерживаться стандартных методов xPDO, то есть избежать чистого SQL, так как чистый SQL по некоторым причинам в фреймворках вообще не кашерно (хотя бы с точки зрения возможной миграции на другой тип БД, смены названий таблиц, префиксов или еще чего-нибудь)

Наконец-то дошли руки довести до ума компонент «Фильтрация и управление фильтрами» (tagManager). Первая его версия была очень сырая, даже пришлось сделать дополнительно упрощённый вариант фильтрации. Теперь всё, что было задумано реализовано в нормальном виде и хочу рассказать об этом компоненте сообществу MODX и всем интересующимся.

Функции:

• Сортировка групп фильтров и отдельно их значений.
• Настройка активности групп фильтров и отдельных значений (чекбокс).
• Изменение значений (по двойному клику появляется поле) для всех товаров, у которых есть это значение.
• Ajax-фильтрация и сортировка товаров в каталоге.
• Выводится число товаров по каждому фильтру. Блокируется получение пустого результата поиска.
• Поддержка типов ввода TV с выбором одновременно нескольких значений — Флажки(checkbox), Список (множественный выбор).

Как истинный консерватор, я долгое время использовал исключительно MODx Evolution. Меня устраивало прежде всего наличие исчерпывающей документации, кучи статей и предельно понятной архитектуры данной версии MODx CMF. О версии Revolution я периодически читал разные статьи, но мне не хотелось менять привычную для меня систему на что-либо другое. Однако, в один прекрасный момент количество таблиц в базе данных моего мультидоменного «хомячка» на хостинге достигло устрашающих размеров. Встал вопрос о мультидоменном решении. Когда-то я вычитал о возможности создать на MODx Revolution мультидоменный сайт. Я установил движок на тестовый поддомен и начал копать глубже. Как оказалось, в самом фреймворке как такового готового решения насчёт мультидоменности пока не существует. Существует некая система контекстов. Разные контексты можно определить на разные поддомены. Только для этого нужно править файл index.php.

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

В данной статье я хотел бы рассказать насколько MODx Revolution в целом изменил мой подход к программированию.
Не знаю как кто программирует, но я считаю, что давным давно уже программирую методами ООП. К чему же в общих чертах сводилось программирование? Я писал (или брал готовые) классы под свои задачи (класс по работе с базой данных, класс по работе с шаблонами, класс еще под что-нибудь). Большинство классов были довольно большие и выполняли множество необходимых задач по своему профилю. Чаще всего по мере роста проекта многие классы разрастались, или обзаводились расширениями, или и то и другое. Так или иначе, уверен многие сталкивались с ситуацией часового разбора объекта в пару тысяч строк и несколькими десятками методов, чтобы разобраться куда можно внести очередные изменения, но так, чтобы при этом что-то другое не сломалось. Но на мой взгляд сложнее всего обеспечить гармоничное взаимодействие различных объектов между собой, особенно в плане перехвата ошибок при выполнении тех или иных действий, а главное в момент ошибки решить насколько она критичная и стоит ли прервать процесс выполнения, или можно идти дальше. А еще сюда же приписать клиент-серверные решения, чтобы стандартизировать ответы выполнения и для серверной части (с дальнейшей ее отрисовкой в шаблоны), и для Ajax-запросов.

Какой же именно инструментарий предлагает MODx Revolution для программирования логики проекта? Всего два класса: Процессор (выполняется классом modProcessor) и Коннектор (выполняется классом modConnector).
Что это такое? Процессор — отдельный файл с чаще всего одной или несколькими мелкими задачами, в результате выполнения которого ответ должен быть только положительным (что будет свидетельствовать о положительном результате выполнения), или отрицательный (желательно с конкретным сообщением об ошибке), что будет само собой говорить, что произошло что-то критически неправильно.