В последнее время в англоязычном сообществе MODX много рассуждений на тему «как нам жить дальше». Все на перебой обсуждают грядущую (через несколько лет, полагаю) мажорную версию 3, а мы пока улучшаем своими дополнениями текущую.
Свежее событие, которым я бы хотел поделиться с широкой аудиторией — это выпуск новой версии pdoTools с шаблонизатором Fenom, которая позволит вам полностью избавиться от нагромождения тегов в условиях чанков и переписать их на простом и понятном языке шаблонизатора.
Процедура не требует изменений в работе сайта, просто обновите pdoTools до версии 2.0 и можно использовать новый синтаксис. Самое приятное, что теги MODX отлично соседствуют с Fenom и работают вместе без каких-либо проблем. Простой пример для затравки:
Несколько недель назад ведущий архитектор Джейсон Ковард (Jason Coward, «opengeek») поделился своим видением о будущем MODX на площадке Medium. Основываясь на этой информации, а также на других обсуждениях в сети, что мы знаем о MODX 3? Каков его статус, и когда мы можем увидеть что-то вживую?
Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.
Наверняка многие активные MODX-разработчики слышали про «Фабрику сайтов». Это такие ребята, которые сделали копию движка MODX Revolution, назвали ее Ф.CMS и клепают на ней сайты, выдавая за собственный движок. Но помимо того, что они взяли сторонний опенсурс-движок, они еще и «позаимствовали» различные модули сторонних разработчиков, так же переименовали их и продают как свои, не указывая никакого авторства. Среди пострадавших — andchir и bezumkin. Последний писал про эту ситуацию довольно давно и подробно.
В прошлом году мне пришлось столкнуться с парой клиентов, чьи сайты долго и безнадежно разрабатывались в Фабрике. Один из сайтов был мной переделан и по результатам был написан подробный топик, где я разбирал качество выполненной работы указанной компании. И да, переданный мне сайт был разработан на Ф.CMS, действительно очень сильно напоминающую MODX Revolution, и да, в качестве модуля интернет-магазина использовался ShopKeeper by Andchir.
В настоящий момент занимаюсь переделкой одного новостного портала на MODX Revolution. Так как посещаемость на сайте бывает до 100 000 человек в сутки, вопрос производительности здесь один из самых важных. С учетом того, что на текущий момент в базе более 75 000 статей, при неправильном (и даже при традиционном подходе к разработке на MODX) тормоза сайта практически гарантированы, а если частота посещений превысит время выполнения запроса, то сервер вообще ляжет. Вот часть приемов задействованных здесь для решения этих проблем я и опишу в этой статье.
Shopkeeper — это модуль для создания интернет-магазина на CMS MODX. В этой статье я расскажу что нового в Shopkeeper 3.0, какие новые возможности и какие отличия от предыдущей версии. Но сначала немного истории.
История создания
Первая версия Shopkeeper вышла больше 5 лет назад, в 2009 году. Тогда очень не хватало решения для создания интернет-магазина на MODX. Shopkeeper не был первым, но был довольно не плохо востребован. До сих пор кто-то использует его на MODX Evolution, хотя последняя версия для этой платформы вышла в 2011 году. Затем был выпущен SHK 2.x для MODX Revolution. Для Revo первым был компонент VisionCart, но мне он сразу не понравился запутанным интерфейсом. Его развитие похоже заглохло ещё в 2011 году. Вскоре за Шопкипером вышли ещё достойные компоненты интернет-магазинов и приятно осознавать, что всё это выпущено российскими разработчиками. Теперь пришло время Shopkeeper 3.
Больше года назад я писал про нашу готовую сборку интернет-магазина на базе MODX Revolution. Учитывая текущую обстановку с курсами валют в России (при этом необходимость указывать цены именно в рублях), я решил, что наверняка будет актуальна возможность указывать различные базовые валюты для товаров, но чтобы на сайте как бы все равно все было в рублях. Главное здесь — чтобы можно было указать валюту товара (например евро или доллары), а на сайте цена выводилась бы в рублях по курсу (возможно автоматическое обновление курсов с сайта центробанка). Это далеко не полноценный мультивалютный магазин, но зато цены всегда боле менее актуальны будут с учетом текущего курса валют.
Для реализации одного проекта возникла необходимость использовать какое-либо облачное хранилище. Суть заключается в том, что есть несколько распределенных сотрудников, каждый из которых использует специальную программу, результатом деятельности которой являются обособленные XML-файлы. Данные этих файлов необходимы для того, чтобы сформировать отчетность на сайте, где пользователи могли бы скачать доступную им информацию. Проблема в том, что сотрудники работают на своих локальных машинах и как бы с интернетом не взаимодействуют (то есть не используется какой-то единый сервер или типа того). И вот я решил задействовать Dropbox, типа настрою каждому пользователю свою папочку, куда и будут синхронизироваться их файлы, а на стороне сайта по крону буду все забирать с дропбокса и использовать для формирования отчетности. Под катом расскажу, что из этого получилось.
Пишу в данный момент для modx с использованием индивидуальных документов для каждого обычного пользователя.
Поскольку забивать этими документами админку не хотелось (если с сайтом все нормально будет, их там будет многовато и админка начнет тормозить), решил вынести их в отдельную таблицу БД, с выводом через один ресурс.
Итак, рассмотрим наши требования к документу (по крайне мере, у меня были такие):
У документа должны быть заголовок и содержание;
У документа должен быть тип (для более простого поиска документов одного типа);
У владельца документа всегда есть доступ к его редактированию и просмотру;
У владельца сайта и его юристов есть произвольный доступ к любому из документов;
Владелец сайта и те, кому он это разрешил, должны иметь возможность выдавать нужным им пользователям права на просмотр и редактирование произвольного документа;
Произвольный зарегистрированный пользователь может получить право на только просмотр либо также и редактирование произвольного документа на время либо сразу навсегда.
С MODX Revolution я работаю не так уж давно, но, тем не менее, на данный момент, для меня это CMS-жемчужина. Гибкость, расширяемость и интуитивность (Если на минутку забыть о злополучном MODX Manager), привлекают в ней всё так же, как и в самом начале.
Ниже представлены заметки, которые я делал по ходу работы с MODX Revolution на протяжении прошлого года. Эти несложные приёмы, знай я о них раньше, помогли бы мне сэкономить неимоверное количество времени. Целевая аудитория этих заметок — новички, лишь недавно разобравшиеся в том, что же такое MODX. Откровенные «велосипеды», из уважения к вам, в заметки включать не стал.
В наши дни выбор систем управления контентом (CMS) настолько велик, что невольно теряешься. Причем, качество системы не зависит от того платная она или нет, а принятое решение затем надолго вас привязывает к выбранной CMS.
Предлагаю вашему вниманию перевод статьи английского веб-разработчика Марка Дженкинса, открывшего для себя MODX после многих лет разработки в различных системах.
Вначале идет перевод статьи, затем — некоторые комментарии по тексту.
Не так давно Евгений Муравьёв выпустил совсем новую версию своего знаменитого типографа 3.0. Любому продукту надо чуть-чуть обкататься, самые первые версии как правило сыроватые, потому мы подождали версии 3.2 и начали его смотреть. Надо сказать, что в целом новый типограф оставил положительные впечатления.
Все привет, много уже было написано про обработку ajax запросов на фронтенд части сайта в MODx Revolution, есть даже несколько готовых дополнений.
В свою очередь, я хочу предложить ещё один, очень простой способ обработки ajax запросов в MODx Revolution.
Затем, что система далеко не новая, а нормальной русскоязычной документации до сих пор нет. Всё, что есть, разбросано по разным сообществам и блогам, которых несколько десятков, и любой начинающий пользователь бегает туда-сюда, задавая вопросы.
Официальная документация на русском не ведётся. Не знаю, как сейчас, но год назад у них просто не сохранялась кириллица.
Почему не сделать это на сайте n или z?
Потому, что у этих сайтов есть хозяева, у них нужно просить логины\пароли и нет никакой гарантии, что завтра сайт не пропадёт, оставив ваш вклад в кэше гугла.
Например, я пробовал писать про свои дополнения на официальном сайте, а потом они его переделали, и мой логин пароль больше не подходит. Просто зарегистрироваться нельзя — нужно получать их через письмо в поддержку. Конечно, повторно это делать нет желания.
К тому же, сообщество MODX не может похвастаться сплоченностью, и основных разработчиков просто не собрать в одном месте, чтобы они что-то там написали.
Был у меня Aloha Editor для MODX Revolution. Но поработав с ним, я разочаровался. Слишком он тяжелый (большие скрипты) и добавляет свои теги в код. Хотелось чего-то простого и универсального. В итоге на свет появился этот плагин.
Хочу представить вашему вниманию свою разработку по быстрому выводу контента на сайтах MODX Revolution.
Как известно, эта система целиком построена на собственной ORM под названием xPDO. Она очень упрощает работу, позволяет писать один универсальный код для разных БД, и еще много чего.
К сожалению, она не может похвастаться скоростью вывода (как, наверное, вообще любая ORM), поэтому я попробовал совместить её плюсы с обычным PDO, добавить лучшую работу с чанками и сделать удобную библиотеку для MODX.
Основные особенности:
Быстрая работа с БД. Все запросы составляются на xPDO, а выбираются без объектов — на PDO.
Предварительная обработка простых плейсхолдеров в чанках. Парсер MODX разбирается только со сложными вызовами.
Код чанков можно указывать прямо при вызове сниппета, загружать обычным образом или из статичных файлов.
Правильная сортировка, подготовка, обработка и вывод ТВ параметров.
Ведение подробного журнала работы сниппета с отметками времени, для отладки.
Удобная загрузка классов и множество функций, которые можно применять в своих разработках.
В комплекте 8 универсальных сниппетов, которые дают хороший базис разработчику.
Не устаю удивляться возможностям, которые предоставляет компонент MIGX от Bruno17 для MODX Revolution. Выглядит он пока неказисто и встречаются ошибочки, но критических проблем нет. Всё, что написано в этой статье, актуально для MIGX версии 2.5.8-pl (последняя на данный момент).
Многие используют MIGX для создания фотогалерей, но этим его функционал не ограничивается. Это настоящий конструктор для управления данными любых таблиц БД. Можно даже выводить список дочерних ресурсов (документов MODX) в любом контейнере. Об этом и пойдет речь в данной статье. Кое что я узнал из документации MIGDB, но, на сколько я понял, она уже порядком устарела и многое из описанного там просто не работает.
Часто, когда разработчик выбирает движок для очередного магазина, он обычно оценивает этот вопрос по нескольким критериям:
Платный/бесплатный (если платный, то сколько).
Какой функционал есть «из коробки».
Насколько легко докрутить какой-то свой функционал.
Как много он потянет товаров, чтобы на хостинг не разориться.
Насколько гибкие политики безопасности, чтобы обеспечить совместную работу различных отделов.
Какие платежные системы поддерживаются.
Под катом я расскажу о новой готовой сборке интернет-магазина, которая разрабатывалась с учетом этих критериев, и думаю, может заставить призадуматься даже искушенных разработчиков.
В конце статьи видео с кратким обзором движка и двумя способами установки
Важно!!! Забыл сказать: кто поленится посмотреть видео, но развернет у себя сборку, логин/пароль в админку по умолчанию: admin/admin.
Сразу скажу, что разворачивая данную сборку, вы сразу получаете вот такой сайт. То есть сразу есть модель каталога, регистрация/авторизация через соцсети, оплата через робокассу и т.п. (само собой на своей копии надо будет прописать в конфигах свои данные робокассы и привязать сайт к социалкам).
Основа движка (а так же довольно большая предыстория)
За основу был взят фреймворк MODX Revolution. Только не торопитесь плеваться и закрывать страницу. Это не в точности тот MODX, с которым вам возможно приходилось встречаться. Я с MODX работаю с начала 2009-го года, и знаю его вдоль и поперек. И да, я как и многие сталкивался со многими его минусами (типа шаблонов и чанков в базе данных, тормоза и т.п.). Плюс к этому до знакомства с MODX много работал с различными самописками и другими движками, и на MODX-е я остался именно за его гибкость. Да, мне не все в нем нравится, но он позволяет с легкостью многое в нем изменить, при этом не трогая самого ядра. В процессе у меня появилось несколько компонентов, которые дополняют или меняют определенный функционал MODX-а. Вот парочка наиболее важных из них: phpTemplates — позволяет статические MODX-шаблоны вызывать как обычные php-файлы. modxSmarty — Подключает для фронта шаблонизатор Smarty и дополняет его некоторыми плюшками, обеспечивая тесное взаимодействие с самим MODX-ом. shopModx — модуль для разработки интернет-магазинов.
В итоге MODX обретает не только полноценную шаблонизацию, но и гораздо бОльшую производительность. Сайты с десятками тысяч документов работают с откликом 0,02 — 0,6 секунд. Плюс к этому можно практически полностью забить на синтаксис самого MODX-а, и если вы умеете программировать на php и знаете Smarty — то здесь в разработке у вас никаких проблем не возникнет.
Но одна из самых важных вещей в MODX-е, которая точно меня держит цепями — это система пакетов (модулей для MODX-а). Она реально классная. Я даже написал модуль, который позволяет создавать свои собственные репозитории пакетов. Это особенно полезно различным веб-студиям и активным разработчикам. При этом самая вкусняшка заключается в том, что упаковывать можно не только отдельные модули, но и вообще все что угодно на сайте, хоть целиком, хоть по отдельности, хоть весь сайт вообще. Так появились снапшоты MODX-сайтов. Изначально это было реализовано только на самом modxcloud.com (официальный хостинг от разработчиков MODX-а), но совершенно без документации и каких-либо релизов ими был выложен скрипт vapor, который предназначался для того, чтобы любой мог сделать снимок своего сайта и закинуть его на modxcloud.com. При этом обратная связь как бы и не подразумевалась (то есть брать снимки с modxcloud.com и разворачивать на любом своем хостинге). Не буду вдаваться в подробности, но я взял этот vapor, модифицировал его и добавил ему еще один скрипт (import.php). Теперь с помощью этого скрипта можно как делать снимки сайтов, так и разворачивать их поверх чистого сайта. Скачать мой vapor можно из официального репозитория. И вот как раз с этим вапором я взял курс не только на отдельные модули, но и на готовые сборки сайтов.
В чем смысл таких сборок?
Смысл в том, что когда на проекте используется сразу несколько каких-то отдельных компонентов, которые совместно должны дать какой-то ожидаемый результат, важно не только их наличие, но и тонкая настройка, чтобы обеспечить наилучший эффект + максимальную гибкость. И понятно, что для этого надо не только очень хорошо их знать, но и иметь опыт применения, знать как лучше сделать, какие подводные камни бывают и т.п. А вот если дать разработчику уже готовый сайт, где уже все установлено и настроено, то потолок вхождения и объем работ снижаются в разы.
Вот эта сборка как раз и есть готовый интернет-магазин на базе моих и стандартных модулей, обеспечивая наилучшую производительность, гибкость и управляемость.
Что уже есть в этой сборке?
Добавлен компонент Billing. На этом модуле завязано все, что связано с заказами, оплатой и т.п.
Корзина перестала существовать отдельно. Теперь Корзина — это еще не оформленный Заказ (Order). Теперь даже не оформленные заказы хранятся в базе данных, что как минимум позволяет видеть кого что интересует, а так же определять реальный процент конверсии и выявлять возможные ошибки.
Компонент Basket (Корзина) остался, но почти все, что связано с самими заказами, перенесено в Billing. Basket и дальше останется отдельным модулем, а в Billing-е будет только необходимый минимум логики. Рассчет на то, что сам механизм заказа, оплаты и т.п. можно будет реализовывать в любых сторонних модулях, которые будут взаимодействовать с биллингом.
Добавлен и сверстан новый шаблон по умолчанию с использованием bootstrap. Много всяких аджаксовых плюшек и полноценное JS-API.
Добавлен табличный редактор документов.
Добавлено управление заказами.
Добавлен личный кабинет пользователя, регистрация, смена пароля, восстановление пароля и т.п.
Настроена регистрация через Login, смена/восстановление пароля и т.п.
Добавлен модуль modHybridAuth (авторизация через социальные сети). Пока четко проверены Twitter, Facebook и Google, но должны и другие работать.
Подключен сервис оплаты Robokassa.
Настроены политики безопасности:
Контент-менеджер;
Администратор магазина;
Менеджер магазина;
Продвинутый менеджер магазина.
Что дальше делать с этим сайтом после установки?
Делаете копию шаблона и меняете в нем все, что угодно. Шаблонизация на Smarty, входные данные массивами, все процессоры на классах. То есть не трогая ядра, можно переделать сайт как угодно.
Пример, как добавлять еще платежные системы
Вот у нас есть оплата через робокассу, и стоит задача прикрутить еще какой-нибудь способ оплаты. Посмотрим, как это делается.
Это базовый процессор для любых типов оплаты.
<?php
/*
Абстрактный класс на проведение оплаты.
Его нельзя вызывать напрямую, чтобы исключить случаи инжекта оплаты.
Этот класс должен расширяться другим классом конкретной платежной системы,
чтобы использовать методы проверки платежа самой платежной системы
*/
abstract class modWebPaymentsCreateProcessor extends modObjectCreateProcessor{
public $classKey = 'Payment';
protected $BillingProcessorsPath;
public function checkPermissions() {
// Проверяем подпись платежной системы
$ok = $this->checkSignature();
if($ok !== true){
$this->error($ok);
return false;
}
return parent::checkPermissions();
}
public function initialize(){
$this->BillingProcessorsPath = MODX_CORE_PATH . 'components/billing/processors/';
$this->setDefaultProperties(array(
'currency_id' => $this->modx->getOption('shopmodx.default_currency'),
));
if(!$this->getProperty('paysystem_id')){
return $this->error("Не был получен ID платежной системы");
}
return parent::initialize();
}
public function beforeSet(){
$this->setProperties(array(
"createdby" => $this->modx->user->id ? $this->modx->user->id : null,
"date" => time(),
));
return parent::beforeSet();
}
public function beforeSave(){
if(
!$currency_id = (int)$this->getProperty('currency_id')
OR !$currency = $this->modx->getObject('modResource', $currency_id)
OR ! $currency instanceof ShopmodxResourceCurrency
){
return $this->error("Не был получен объект валюты");
}
if(
!$paysystem_id = (int)$this->getProperty('paysystem_id')
OR !$paysystem = $this->modx->getObject('Paysystem', $paysystem_id)
OR ! $paysystem instanceof Paysystem
){
return $this->error("Не был получен объект платежной системы");
}
// Проверяем, если указан счет платежной системы, то надо убедиться, что
// он еще не числится в биллинге
if($paysys_invoice_id = $this->object->get('paysys_invoice_id')){
if($this->modx->getCount($this->classKey, array(
'paysys_invoice_id' => $paysys_invoice_id,
'paysystem_id' => $paysystem_id,
))){
return $this->error("Данный счет уже создан в системе.");
}
}
$this->object->addOne($currency);
$this->object->addOne($paysystem);
return parent::beforeSave();
}
/*
Обязательно надо прописывать метод, в котором будет выполняться проверка
подписи с сервера платежной системы
*/
abstract protected function checkSignature();
protected function log($msg, $level = null){
if($level === null){
$level = xPDO::LOG_LEVEL_INFO;
}
$this->modx->log($level, "[Basket - ".__CLASS__."] {$msg}");
$this->modx->log($level, print_r($this->getProperties(), true));
return $msg;
}
protected function error($msg){
return $this->log($msg, xPDO::LOG_LEVEL_ERROR);
}
/*
Логируем все ошибки процессора, на всякий случай
*/
public function failure($msg = '',$object = null) {
$this->error($msg);
if(!empty($this->object) && is_object($this->object)){
$this->error(print_r($this->object->toArray(), true));
}
return parent::failure($msg,$object);
}
public function cleanup() {
/*
// Если оплата прошла успешно, то обновляем статус заказа
*/
if($order_id = $this->object->get('order_id')){
$this->modx->runProcessor('mgr/orders/status/pay', array(
'order_id' => $order_id,
), array(
'processors_path' => $this->BillingProcessorsPath,
));
// На всякий случай сбрасываем счетчик ошибок, если вдруг в вызываемом
// процессоре были ошибки
$this->modx->error->reset();
}
return $this->success($this->getSuccessMessage(), $this->object);
}
protected function getSuccessMessage(){
return '';
}
}
return 'modWebPaymentsCreateProcessor';
Он абстрактный, и его нельзя вызвать напрямую, так как у каждой конкретной платежной системы свои механизмы проверки платежа. Но этот класс уже обеспечивает всю необходимую логику, и от расширяющего процессора ждет только одного: подтверждения правильности платежа и установки суммы и прочих данных платежа.
А вот расширяющий процессор конкретно для робокассы:
Как видно, это всего 60 строчек кода. Но в результате не только будет проведена оплата с учетом кто платил, через что, сколько и т.п., но и будет автоматически изменен статус заказа на Оплачен. И вот прикрутить еще какой-нибудь способ оплаты — это всего несколько десятков строк.
Итоги
В итоге, получился на самом деле очень не плохой движок. Сразу скажу, что помимо гибкости, производительность у него тоже весьма не плохая. Как раз недавно наткнулся на топик, в котором народ рассуждал, что даже 40 000 товаров уже напрягает не хило их магазины. Я делал магазины на shopModx с десятками тысяч товаров без всяких особых ухищрений, и все нормально работает. И даже если товаров будут сотни тысяч (я уже делал один на 150 000 товаров), то с небольшими доработками магазин и столько потянет.
И самое главное: эта сборка совершенно бесплатная! Конечно мы всегда открыты для приема донейтов от благодарных разработчиков, но де факто движок полностью бесплатный.
И напоследок видео с кратким обзором движка и двумя способами установки.
Сегодня для нашей команды случилось знаменательное событие — мы объявляем о запуске совершенно нового проекта MODX.RU. Как и раньше, целью сайта является популяризация замечательной системы управления MODX CMS среди русскоязычных веб-разработчиков и конечных пользователей системы. Мы рассчитываем, что новые возможности проекта позволят сделать это намного лучше.
Первым шагом стало создание установщика пакетов. На это ушло пару часов, так как по факту весь код давно присутствует в MODX в папке install, вот тут можно почитать про это.
Ну а дальше уже дело техники. После обсуждения с Bumkaka определили то, что является приоритетным и приступили к работе. Делать решили на базе MODX EVOLUTION.