Как узнать версию modx
Знакомство с MODX
В наши дни выбор систем управления контентом (CMS) настолько велик, что невольно теряешься. Причем, качество системы не зависит от того платная она или нет, а принятое решение затем надолго вас привязывает к выбранной CMS.
Предлагаю вашему вниманию перевод статьи английского веб-разработчика Марка Дженкинса, открывшего для себя MODX после многих лет разработки в различных системах.
Вначале идет перевод статьи, затем — некоторые комментарии по тексту. 
Я только что закончил свой второй проект на платформе MODX, и думаю, самое время изложить свои мысли. У меня сложилось такое впечатление, что в web-индустрии MODX преимущественно не имеет широкую известность, отчасти поэтому, в целях просвещения, я и пишу эту статью.
Что такое MODX?
MODX – это система управления контентом с открытым кодом. Она построена на основе PHP и MYSQL, поэтому работает практически на любом сервере. Как и в WordPress существуют две версии: MODX Revolution (как wordpress.org, версия для скачивания и установки на ваш сервер) и MODX Cloud (как wordpress.com).
MODX – непритязателен: не важно, где располагаются шаблоны, как они организованы или где размещается контент. Это гибкая система, позволяющая работать как вам угодно.
Где можно использовать MODX?
Выбор систем управления сайтами (CMS) довольно широк. Раньше я пользовался WordPress, Perch, Expression Engine и Kirby, так же как Shopify и Magento для интернет-магазинов. Я использую WordPress и Perch на постоянной основе и обе системы доказали свою надежность и простоту использования.
Отсюда возникает вопрос: «Зачем вообще я должен вникать в MODX?»
Думаю, будет честно, если скажу, что я довольно хорошо знаком с WordPress, т.к. делал в этой системе практически все: блоги, 5-ти страничные сайты, мульти- региональные сайты с сотнями страниц. Разрабатывая на WordPress большие сайты, я сталкивался со многими трудностями, например: структура постоянных ссылок и систематика могут быть ограничены. Хотя в последние годы CMS значительно улучшилась, но все же чувствуется, что это не подходящий инструмент для работы с огромными и сложными сайтами.
Именно здесь MODX предстает во всей красе. Пока WordPress собирает структуру (пользовательские типы постов, систематика, темы) MODX предлагает пустую оболочку, готовую подстроиться под любые ваши потребности.
То, с какой легкостью MODX работает с шаблонами, впечатляет. Не нужно создавать шаблоны с заданным именем файла или размещать их в определенной папке, а синтаксис MODX обеспечивает чистоту и доступность кода.
Я перехожу с WordPress. Сложно будет переучиваться?
Во-вторых, MODX использует свой синтаксис тегов. Поначалу, я думал, зачем вообще разработчики MODX заморачиваются над созданием своего синтаксиса, но попробовав на практике, стало понятно. Он позволяет содержать код шаблона чистым и понятным (по крайней мере, лучше, чем эти ужасные непоследовательные функции WordPress).
Совместимость с Git
Есть ли недостатки у MODX?
Как я уже отмечал в этой статье, изучить MODX несложно. Некоторое время займет привыкание к терминологии и способам реализации тех или иных вещей.
Документация достаточно хорошая, хотя в поисках ответов на некоторые вопросы вам придется постараться. Шансы найти ответ по возникшей проблеме в WordPress, вероятно, в несколько раз выше, т.к. численность сообщества MODX поменьше.
Тем не менее, я нашел сообщество в Твиттере, которое оказалось очень полезным. Отправив несколько вопросов группе #MODX, я каждый раз получал хотя бы один ответ, который направлял меня в нужном русле.
Процесс установки MODX более сложный, чем у WordPress. Например, чтобы установить систему локально, я клонировал наш репозиторий, затем скопировал туда файлы MODX, настроил файлы конфигурации, запустил установку, подправил некоторые файловые разрешения и снова запустил установку. По сравнению с WordPress, поднятие и запуск MODX немного витееваты.
О системе MODX
MODX (читается «мо́дэкс») — это бесплатная профессиональная система управления содержимым (CMS) и фреймворк для веб-приложений, предназначенная для обеспечения и организации совместного процесса создания, редактирования и управления контентом (то есть содержимым) сайтов.
MODX распространяется бесплатно по лицензии GPL с открытым исходным программным кодом (Open Source). Это означает, что систему MODX может использовать каждый: как для личного использования, так и для коммерческого распространения сайтов, построенных на данной системе управления.
MODX написана на программном языке PHP и использует для хранения данных СУБД MySQL или MS SQL. Система управления MODX может быть установлена на большинстве веб-серверов (например, таких как IIS, Apache, Lighttpd, nginx и Zeus), а контрольная панель системы (или админ-зона) работает практически во всех современных браузерах.
Версия MODX
MODX Revolution
На текущий момент это новейшая версия системы управления сайтами MODX, которая активно развивается и поддерживается командой разработки.
Если вы не уверены, какую версию MODX использовать, рекомендуем выбрать MODX Revolution.
MODX Evolution
На сегодня MODX Evolution используется параллельно с Revolution. Вероятно, для начинающих разработчиков начало работы с Evolution может показаться проще.
Некоторое время назад разработчики заявили об остановке работы над проектом Evolution, чтобы сконцентрироваться только на Revolution. Тем не менее впоследствии разработка Evolution перешла в руки сообщества и продолжила свое активное развитие. При выборе MODX Evolution для новых проектов желательно учитывать, что в целом функциональные возможности Revo выше Evo.
«Джентльменский набор»
Несмотря на то, что MODX может работать почти на какой-угодно операционной системе, возможно, будет полезно учесть следующие рекомендации при установке и работе с MODX:
Краткая история MODX
Разработчики Реймонд Ирвинг (Raymond Irving) и Райан Треш (Ryan Thrash) начали работу над проектом MODX CMS в 2004 году как модуль DocVars для системы управления сайтами Etomite и дополнением Реймонда для веб-пользователей.
В марте 2005 года все ссылки на MODX были удалены из форумов Etomite одновременно с требованием основателя Etomite прекратить поддержку MODX в них. С этого момента MODX становится форком Etomite.
К маю 2005 года форумы MODX были запущены онлайн и Джейсон Ковард (Jason Coward) присоединился к команде руководства проектом.
В 2007 году Реймонд покинул проект на дружественных условиях. В следующем году Шон МакКормик (Shaun McCormick) присоединился к команде руководства проектом.
В 2008 году пользователи MODX создали новый логотип и новый дизайн для проекта MODX CMS.
В 2010 году была выпущена первая версия MODX Revolution, которая являлась полностью переписанной версией MODX.
Гид по CMS MODX для новичков!
Система управления контентом MODX это сравнительно новая система. Многие не знают про неё или боятся её, хотя система очень крута. В статье мы расскажем вам про CMS MODX.
Что такое MODX
Modx – это бесплатная система управления содержимым/контентом и фреймворк для Web-приложений. Ее разработка стартовала в 2004 году. На сегодняшний день представлены две версии движка: Evolution и Revolutoin. Разработчики уже прекратили поддерживать первую (но осталась поддержка сообществом пользователей). В данный момент актуальна только вторая версия. Именно над Modx Revolution теперь активно работают создатели.
Преимущества MODX
В ТОПе Рунета CMS Modx надежно закрепилась в пятерке лидеров. И речь идет о рейтинге всех систем: как коммерческих, так и с открытым исходным кодом. Modx принадлежит к категории Open Source, а значит, дает возможность создавать как сайты, так и веб-приложения.
К плюсам Modx можно отнести:
С помощью Modx можно добавить на страницу много полезных модулей: опросы, форум, чаты, блоги, подписку, фотогалереи, баннеры, интернет-магазин, платежные системы и прочие.
Большинству новичков ошибочно кажется, что система обладает весьма ограниченным рядом настроек. Но на самом деле это не так. Любой опытный веб-мастер знает, что Modx предоставляет огромное количество возможностей, которые за умелой оптимизацией панели администратора можно сразу и не разглядеть.
Использование шаблонов в ModX
Данная CMS не предусматривает работу с готовыми макетами. Но решение все равно есть: подгонять для ModX html-шаблоны. Поэтому, если вы владеете HTML и CSS, вам без проблем удастся настроить дизайн, пусть для этого и понадобится некоторое время.
Сейчас в Сети полно различных html- и css-шаблонов, в том числе бесплатных. Можно найти даже сборки, подготовленные специально для ModX.
Настройка шаблонов делается по такому алгоритму:
Как создать интернет-магазин в ModX
Система прекрасно подходит для реализации этой задачи, поскольку встроенные модули позволяют создавать интернет-магазины всех типов и масштабов. Эти инструменты ничуть не хуже многих платных аналогов. Они включают в себя такие функции:
Чаще всего интернет-магазины создают в ModX с использованием модуля MiniShop, который легко превращает обыкновенный веб-сайт в хорошую торговую площадку. В дополнение ко всему он позволяет связывать товары по разным характеристикам, публиковать справочную информацию от производителей, добавлять неограниченное число складов, встраивать функцию «статус заказа» и процедуру регистрации пользователей.
Многие разработчики подготавливают и распространяют уже готовые сборки с определенным набором модулей. Но всегда можно заказать индивидуальный вариант, подходящий под конкретные условия и пожелания клиента.
Недостатки CMS ModX
Во всем есть свои минусы, и Modx – не исключение. Но хотя в данном случае их нельзя назвать критичными, желательно все-таки учесть эти нюансы перед установкой системы на сервер:
Что касается второго пункта, решение мы уже находили – использовать CSS-шаблоны. Вот только справиться с настройкой этих файлов для использования в Modx под силу только опытным мастерам, хорошо знающим Modx-теги. В итоге, позиционируемая простой, система на самом деле заставляет новичков столкнуться с труднопреодолимыми препятствиями.
Терминология Modx отличается от той, которая используется в прочих CMS. Это вряд ли можно считать существенным недостатком, просто придется привыкать к тому, что веб-страницы здесь называются ресурсами, а чанки – это часто используемые фрагменты HTML-разметки.
Выводы
Система управления контентом Modx соединила в себе такие качества как функциональность, простоту в использовании и кроссбраузерность. Тем, кому версия Revolution покажется сложной, рекомендуем начать со знакомства с Modx Evolution. Не нужно бояться, что разработчики ее забросили: в пользовательском сообществе достаточно профессионалов, всегда готовых оказывать техподдержку движка.
Modx предоставляет веб-мастерам полную свободу выражения. С помощью системы можно создать сайт любого масштаба и типа: от одностраничного ресурса с описанием единственной услуги до полнофункционального интернет-магазина или крупного корпоративного портала. Но весь спектр возможностей Modx доступен только тем, кто знает хотя бы базу HTML/CSS, поэтому полным новичкам работать с движком будет непросто.
Защита Modx Revolutoin находится на высоком уровне. Так что миф об уязвимости систем с открытым исходным кодом, так активно распространяемый многими веб-студиями, не стоит принимать за правду. Modx Evolution в этом плане действительно чуть слабее. Именно поэтому для создания сайтов с платежами лучше все-таки пользоваться активной версией – Revolution.
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 со значением по умолчанию
Собственно разработка ведётся в папке 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-версии сайта соответствовала продакшену.
Да, полностью избавиться от копипаста у меня не получилось.
Заключение
Таким образом, мне удалось организовать рабочий процесс, который бы устроил, в первую очередь, меня. В реальной работе эта схема ещё не применялась, поэтому подводных камней пока не обнаружено. Может быть более профессиональный взгляд читателей увидит существенные недостатки, поэтому прошу написать об этом в комментариях. И кстати, это моя первая статья, и я бы хотел узнать насколько доступно и ясно мне удалось изложить свои мысли, буду благодарен за конструктивную критику.
MODX 3: Alpha 3 и план релизов
Это не дословный перевод, а скорее компиляция информации аж из целых трех заметок, вышедших на днях на англоязычных ресурсах. Хотя многие, кто активно участвует в жизни сообщества, об этом и так уже знают. Тем не менее, давайте пройдемся еще раз по новостям.
Сразу дам все ссылки на источники, если кто желает читать в оригинале на английском:
График выпуска версий MODX 3
Ни для кого не секрет, что разработка MODX 3 заняла намного больше времени, чем можно было бы представить. Проведя последние несколько месяцев в работе над наиболее важными задачами, мы, команда разработчиков MODX, подошли к этапу, на котором основное внимание стоит уделить стабилизации и выпуску этого проклятого релиза. 🙂
Команда сосредоточилась на том, чтобы сохранить как можно большую обратную совместимость, перед тем, как перейти к бета-версиям. Мы ценим любой вклад, включая тестирование, все issues и pull requests, которые мы получили во время второго альфа-цикла.
Имея в виду выше сказанное, на прошлой неделе был предложен и одобрен всеми ключевыми участниками, участвующими в процессе, следующий график. Вот ключевые даты:
4 ноября (или примерно) мы начнем заморозку кода, после которого никакие новые функции или улучшения не будут приняты в версию 3.0. Заманчиво конечно продолжать добавлять улучшения, особенно когда релиз находится в разработке так долго, но в какой-то момент мы все должны провести черту и отложить новые функции и улучшения до следующей версии, в данном случае до версии 3.1.
Да, но ведь было уже….
Вы правы, ранее уже обещали выпустить MODX 3 и даже даты называли, но не сдержали обещания, так что некоторый скептицизм вполне закономерен.
На этот раз ситуация отличается тем, что мы, наконец, достигли точки, в которой нет каких-то серьёзных блокирующих изменений или большого рефакторинга, которые нужно завершить. Мы сейчас думаем не столько о будущем развитии, как просто о том, чтобы получить достаточно помощи от сообщества, чтобы к концу января этот выпуск был признан стабильным.
Конечно, список идей и желаний, особенно с теми дикими обещаниями, которые давались в прошлом, огромен. Но на данный момент MODX 3 считается «достаточно хорошим», поэтому мы можем сместить фокус разработки на стабильность и совместимость. После выхода версии 3.0 мы можем перезарядиться и начать искать более амбициозные цели и реализовывать все то, что было когда-то запланировано.
Мы взялись работать в довольно жестких временных рамках, особенно в отношении релизов MODX, и мы полагаемся на активную помощь сообщества.
Нам нужна ваша помощь с тестированием
Как и в случае с любой альфа- или бета-версией, мы надеемся, что участники сообщества опробуют последнюю версию и убедятся, что всё работает должным образом. Если вам интересно, как помочь, есть более подробная статья о том, как тестировать код MODX.
Когда можно будет запускать в production?
Мы рекомендуем и даже настаиваем использовать альфа- и бета-версии только в изолированных тестовых окружениях или в промежуточных окружениях (stage), а новые проекты начинать уже с версий RC, ближащая из которых должна быть доступна в январе.
После выпуска 3.0.0-pl рекомендуется сначала обновить существующие сайты в тестовом окружении. Особенно те, которые содержат много собственных функций или специфический код, всё из-за критических изменений в версии 3.0.
Вызов для агентств от Марка
Если вы отвечаете за команду, которая создает сайты с помощью MODX, у modmore есть вызов для вас – активизироваться и принять участие в финальном спринте.
Порекомендуйте своей команде выделить хотя бы один день в неделю для работы над MODX 3, а не над клиентскими проектами. Выделите время и начните с клонирования одного или двух клиентских сайтов в тестовой среде, чтобы протестировать новые сборки MODX 3, а после сообщить о проблемах и неработающих дополнениях. А при возможности, потратить немного времени на внесение исправлений в ядро и дополнения. Как только технические проблемы и совместимость будут решены, привлеките ваших редакторов или маркетологов для тестов, либо попробуйте протестировать более сложный сайт.
Понятно, что клиентские проекты важны и дают выручку, но как можно более плавный запуск MODX 3 также принесет большую пользу вашим клиентам. Клиентам определенно понравится и новый дизайн и новые функции. Тем не менее MODX 3 действительно нуждается в дополнительном тестировании и чем раньше, тем лучше.
Для агентств, которые решат эту задачу в течение как минимум 6 недель, условно считая с сегодняшнего дня и до выпуска 3.0.0-pl, modmore предлагает единовременную 30% скидку на дополнения или 3 бесплатных месяца подписки на SiteDash.
Задача довольно проста:
Напишите на почту в течение 2 месяцев после выпуска MODX 3.0.0-pl, чтобы запросить скидку или подписку на SiteDash. Единственное ограничение скидки – это то, что она предназначена для разовой покупки лицензий дополнений и должна быть использована в течение года; нет никаких ограничений на то, какие лицензии и сколько.
Если вы фрилансер или хотите решить эту задачу в свободное время, вы, конечно, также можете принять участие и получить вознаграждение для себя. 🙂
Мы также рекомендуем (но не требуем), чтобы вы публично заявляли о том, что принимаете участие в испытании. Напишите об этом в Твиттере, прокомментируйте в сообществе или поделитесь им в блоге своей компании или профиле LinkedIn, в зависимости от того, что вам больше подходит. Мы будем следить за вашим прогрессом и напоминать вам, если покажется, что вы не успеваете. Но что более важно, ваше обещание может убедить других присоединиться и это повысит уровень тестирования, которое очень необходимо для MODX 3.
Если вы с пониманием относитесь к этой задаче, но у вас действительно нет свободного времени для компании, просто подумайте о том, чтобы заплатить кому-нибудь еще, чтобы он отработал 4 часа от вашего имени. По сравнению с общей заработной платой агентства, добавление 4 часов в неделю — относительно небольшое вложение, но влияние на MODX 3 будет огромным.
В сообществе есть отличные независимые разработчики, которые были бы рады потратить больше времени на работу над MODX, если бы представилась такая возможность (если это вы, дайте о себе знать, чтобы агентства могли вас найти), Так что это отличный способ по-прежнему сделать значимое влияние на MODX 3, даже если у вас нет времени для работы.
Наконец, все пожертвования, которые мы получим до выпуска 3.0.0-pl, также будут направлены на развитие MODX 3. Мы бы предпочли, чтобы другие люди так же получили возможность поучаствовать в MODX, но мы с радостью добавим дополнительное время к 8-12 часам в неделю, уже указанным в нашем календаре (Марк 4-8 часов, Айзек и Мюррей по 2 часа каждый) по ставке 36 евро в час – 60% от стандартной почасовой ставки. Если мы получим больше пожертвований, чем мы физически можем потянуть, мы предложим вознаграждения за решение конкретных проблем и/или X часов в неделю другим разработчикам.