— Читайте также: Секреты успеха и особенности переноса сайта на Umi.CMS
Рекомендовать что-то — дело очень неблагодарное. Потому что рекомендующий отвечает за рекомендуемого, и, если последний разочарует, то по неписанному правилу виноват тот, кто посоветовал.
Поэтому, чтобы советовать, надо быть готовым поручиться на 100%. И мы можем с уверенностью рекомендовать UMI как систему управления сайтами и даже, отчасти, как фреймворк. Рекомендовать без исключений и оговорок, как для крошечных сайтов-визиток, так и для мегапорталов и интернет-магазинов.
Хорошо зная огромное количество других CMS, мы можем пояснить, на чем основано наше мнение.
Какую лицензию выбрать?
Открыв магазин лицензий Юмисофт в первый раз, разработчик сразу видит цену 29900 рублей, и это некоторых шокирует.
В действительности старшую редакцию Commerce есть смысл покупать для серьезного проекта, которому это — не деньги, а возможности старшей редакции того стоят. В то же время малобюджетный проект можно сделать на UMI Start, эта лицензия бесплатна (внимание: с 2013 года версия Start аннулирована). Отличие только в наборе модулей. Внутри админка такая же, функционирует движок точно так же, последующий переезд с одного на другое возможен. Код бесплатной UMI обфусцирован, то есть запутан, но не закодирован наглухо. То есть при необходимости вставить в index.php хитрый SEO-редирект или глобальный фильтр с ob_start() — это всегда возможно. Ну а если проект дорастет до необходимости серьезных капитальных разработок, всегда можно перейти на коммерческую лицензию. Правда, это порой стоит усилий, так что если предвидится развитие — лучше сразу купить хотя бы редакцию Lite.
Одна из главных фишек UMI CMS — возможность вести разработку кастомного функционала отдельно от ядра и модулей системы в файлах вида /modules/classes/custom.php. Туда можно добавить функции, заинклудить классы, в том числе взятые из любых фреймворков, и отобразить весь этот дополнительный функционал на сайте макросом типа %custom myfunction()% (Пример для tpl шаблонизатора. Далее все примеры так же для tpl,потому что с него все обычно начинают, а кто дорос до xslt — тому эта статья уже не нужна). Таким образом можно сделать на UMI все, что угодно, не касаясь кода самой CMS. Да, это доступно и в бесплатной версии, так что и на ней можно построить все, что хочется, даже не касаясь обфусцированного кода. Вот, почему нет абсолютно никакого смысла в нуленых сборках UMI — там полно бэкдоров, да и это все равно, что воровать бесплатное.
Ещё шикарные подарки от UMI: многосайтовость (управляем несколькими сайтами в одной админке), резервное копирование («машина времени» для статей) и Великий Могучий модуль «шаблоны данных» (добавляем любые дополнительные поля данных любым объектам средствами админки) доступны даже в бесплатной версии. Если после этого кто-то говорит, что ЮМИ дерет бабло за лицензии, то стыдно, товарищи.
Получается, вопрос — какую выбрать лицензию? — это только вопрос серьезности клиента. Даже самый навороченный функционал технически осуществим на любой, в том числе бесплатной, версии. Но клиент посерьезнее на следующий день захочет онлайн-биллинги, опросы и интеграцию с социальными сетями, так что проще (и выгоднее) сразу купить лицензию побольше.
Универсальность структуры данных
Обычно разработчики привыкли видеть статьи сайта в базе данных в табличке, линейно: id конкретной статьи — заголовок — анонс — текст.
В базе данных UMI.CMS данные хранятся в иной структуре: id абстрактного элемента — текстовое поле — числовое поле. Тут немного сложнее найти заголовок и текст, но с помощью API — несколько строк кода — и вы получите что угодно. Ну, а если это «неудобно» — увы, программирование это такая область, где лучший приз достается как раз за дополнительное умственное напряжение. Если все же есть желание подняться на более высокий уровень структуры данных, то появляются новые интересные возможности.
Например, имеется интернет-магазин керамогранита, где типичным товаром является «Плитка напольная серебристая, 1 кв. метр». Все бы хорошо, но эта плитка бывает пяти разных размеров. И каждый размер бывает глянцевый, а бывает матовый, и ещё бывает противоскользящий (для улицы), и к каждой могут прилагаться те или иные декоры (кромки и пр.). Декоры стоят дополнительных денег, но они не продаются отдельно, а идут в придачу к одному метру соответствующей им плитки, и только к ней.
Пример может показаться редкостным, но в действительности таких товаров много: автомобили (цена зависит от комплектации), собираемые из комплектующих компьютеры, формы заявлений на визу (да, с программной точки зрения это тоже товар), кондиционеры (сплит-системы), и т. д.
В новой версии UMI (сентябрь 2011) опциональные (сборные) товары уже входят в готовом виде в модуль «интернет-магазин». Поэтому приведенный ниже пример — не руководство к действию, а просто конкретика чтобы понять принцип.
В модуле «Шаблоны данных» дополняем тип «Товар» дополнительными полями:
Типоразмер 1, tip1, строка, видимое;
Типоразмер 2, tip2, строка, видимое;
и так далее до 15 (пять возможных размеров плитки, умноженные на три типа поверхности, дают 15 возможных вариантов типоразмера).
Аналогично создаем числовые поля для цен:
Цена за кв. метр 1 типоразмера, pr1, число, видимое;
Цена за кв. метр 2 типоразмера, pr2, число, видимое;
и т. д. до 15.
Остается модифицировать корзину, чтобы она принимала ещё один параметр — типоразмер. Расписывать это нет смысла, потому что в современной версии ЮМИ опционные товары есть и так. Мы сейчас просто проиллюстрируем сам принцип.
Итак, если бы мы делали это на движке с линейным принципом хранения данных, как Joomla, Netcat, Bitrix и др., нам бы потребовалось добавлять колонки в таблицы БД. А если у нас не один такой сложный тип объектов, то пришлось бы вообще создавать отдельную другую таблицу под эти дополнительные свойства, и надстраивать что-то глобальное над всем движком.
Здесь же у нас просто появляются новые строки в существующей таблице. Сама структура таблицы сохраняется. То есть если раньше запрос по id элемента товара вернул бы нам название, цену и картинку, то теперь он нам возвращает ещё и типоразмеры этого товара и цены на них. При этом в других элементах, таких, как статьи, по прежнему остались название и контент — новые свойства возвращаются только для того элемента, у которого они есть.
Очевидно что на простом сайте, где есть только один тип данных — статьи — таблица с линейным хранением данных будет выдавать контент быстрее. В то же время, если у нас есть много заковыристых объектов с разными свойствами — реализованный в ЮМИ метод хранения данных является оптимальным, если не сказать гениальным решением. Платой за универсальность в некоторых случаях может оказаться скорость, но эту проблему создатели UMI решили идеально. Но об этом позже, а сейчас главный вопрос: и как достать эти данные, чтобы вывести на странице сайта?
Прямые запросы к базе не нужны, потому что эту работу за нас сделают API и шаблонизаторы.
API
Жизнь — она изменчива и непредсказуема. И ни один сборник готовых рецептов не даст ответов на все ситуации.
API не должен претендовать на управление Вселенной, он должен упрощать типичные рутинные вещи. И только те из них, которые действительно надо упрощать. Только действительно сложные вещи, а не все подряд.
В отличие от других движков, в UMI можно сделать большинство стандартных вебмастерских вещей, вообще не зная ни api, ни даже php, а используя только набор макросов с http://help-dev.umi-cms.ru/.
Шаблонизатора два, xslt и старый, tpl. Лучше, конечно, начинать с xslt, чтобы перепрыгнуть сразу через ступеньку, но сейчас для наглядности возьмем пример с tpl-шаблонизатором.
Допустим, надо, чтобы клиент мог менять слоган под логотипом, телефон в шапке и копирайт в футере средствами админки. Сразу забудем о том, чтобы курочить сам движок ради такой мелкой тривиальной задачи.
Достаточно сделать так:
— в модуле «Шаблоны данных» создаем новый тип данных «Настройки» и добавляем в него три поля: slogan, telefon, copyright.
— создаем статью типа «Настройки» и вносим нужные данные в эти поля. Допустим, id этой статьи (число в конце адресной строки при редактировании статьи) у нас равен 5.
— в нужных местах шаблона вставляем макросы:
%data getProperty(5,'slogan')%
%data getProperty(5,'telefon')%
%data getProperty(5,'copyright')%
(здесь везде число 5 — это id элемента, то есть нашей новой статьи «Настройки»).
Вместе со слоганом и телефоном выведется служебная информация. Это можно изменить, отредактировав шаблон /tpls/data/default.tpl
Аналогично можно вывести любое поле данных любого объекта одним макросом, вообще не зная php. И это действительно серьезный шаг вперед, к тому светлому будущему, когда любой вменяемый человек без навыков программирования сможет заниматься серьезным корпоративным сайтом.
Действительно очень частая ситуация: контентщик выкладывает на сайт тексты, и появляется необходимость разместить объявление о скидках на десятке страниц сразу. И чтобы можно было периодически менять процент скидки, в один клик, а не путем редактирования всех десяти статей. С UMI это очень просто: вставляем в текст всех этих статей макрос наподобие описанного выше, чтобы он выводил контент скидочной статьи (если надо вывести поле контент статьи с id=5, можно вставить макрос %content insert(5)%). Теперь при редактировании статьи, содержащей текст объявления о скидке, изменения появляются на всех страницах автоматически.
Макросы универсальны, и их немного. Их можно вставлять как в шаблоны, так и в текст статьи. Так что с UMI контент-менеджер может управлять сайтом полностью самостоятельно, в то время как в других CMS для выполнения подобной задачи потребовалось бы участие программиста.
На простом редактировании шаблонов и вставке макросов уже можно построить очень многое. Если у Вас старшая редакция с большим количеством установленных модулей, то даже продвинутый интернет-магазин может сделать вебмастер без знания php.
Когда функционала макросов недостаточно, на помощь приходит API. Для пришедших с других движков иногда бывает неочевидным способ его использования в ЮМИ. Например, они отлично понимают суть вызова API для получения содержимого поля "telefon" из статьи с id равным 5:
$hierarchy = umiHierarchy::getInstance();
$element = $hierarchy -> getElement(5);
$telefon = $element -> getValue('telefon');
if ($element instanceof umiHierarchyElement) {
}
Но то, что начинается дальше, превращает их жизнь в кошмар, и они шлют ЮМИ проклятья. Потому что они лезут в код движка, ищут там функцию, выводящую на страницу контент, и с помощью разных хаков пытаются вкрутить в этот, сильно абстрагированный и объектно ориентированный, код свою вставку в виде приведенного выше кода. Они рассуждают: это правильно, ведь я использую API. Но нет. Лезть в сам движок имеет смысл только, если это эпохальная модификация, если нужно что-то основополагающее изменить. В разработке на ЮМИ вмешательство в код самого движка действительно крайне редко бывает.
Достаточно просто добавить в /classes/modules/custom.php новую функцию:
function get_field($id,$field) {
$out = "";
$hierarchy = umiHierarchy::getInstance();
$element = $hierarchy -> getElement($id);
if ($element instanceof umiHierarchyElement) {
$fv = $element -> getValue($field);
if ($fv) $out = $fv;
}
return $out;
}
И теперь можно вставить в то место шаблона, где должен выводиться телефон, макрос %custom get_field(5%
По сути, это то же самое, что упоминавшийся выше макрос %data getProperty(5%, но есть маленькое преимущество: при пустом поле telefon наш макрос выводит пустоту, а не остается висеть на странице.
Эту же обертку можно использовать, если надо вставить яваскрипт, опубликовать что-то, содержащее спецсимволы, примеры кода или такие теги, которые никак не проходят через визуальный редактор ЮМИ. Загоняем эти данные в специально созданное нами в модуле «Шаблоны данных» поле типа «Простой текст». И выводим макросом %custom get_field( id_статьи_куда_загнаны_данные%. Это подходит, если Вам надо вывести код контакта, фейсбука или гисметео, и только на одной странице. Не создавать же для такого случая отдельный шаблон.
Разработчики, привыкшие к мощным фреймворкам наподобие CodeIgniter, пытаются найти в API функцию, которая бы выдала данные в виде красивой таблички. Например, товары в интернет-магазине. Такого нет, API в UMI — это мост между данными и шаблонизатором. То есть таблицу должен будет рисовать шаблонизатор по той схеме, которая ему дана tpl (папка /tpls/) или xslt шаблоне (/xsltTpls/). Иногда ему можно помочь. Допустим, нам надо вывести товары таблицей в три колонки. Блочная верстка — это отличная вещь, но когда дело касается колонок, то часто оптимальным вариантом является таблица. И не только xslt, но и tpl шаблонизатор тоже может её построить:
— Выведем товары макросом %catalog getObjectsList('3_col_template')%
— Скопируем шаблон /tpls/catalog/default в /tpls/catalog/3_col_template и отредактируем наш новый шаблон, вставив туда теги таблицы.
— Добавим в новый шаблон, в конец фрагмента objects_block_line макрос %custom splitter(207%. Передача параметра id нужна, чтобы обойти кэширование макроса.
— Добавим в /modules/classes/custom.php функцию:
function splitter($id, $cols) {
$out = '';
if (!$cols||$cols==''||$cols==0) $cols=3;
$_REQUEST['uniquestring']++;
if ( (intval($_REQUEST['uniquestring'])/$cols) ==
round(intval($_REQUEST['uniquestring'])/$cols)
$out .= "</tr><tr>";
return $out;
}
Эта функция выдает разделитель рядов таблицы на каждый третий (или иной заданный переменной $cols) вызов, и товары выводятся в три колонки.
Когда действительно есть смысл модифицировать сам движок
Очень редкие случаи. Например, для SEO оказалось необходимо сократить адреса вида /catalog_tovarov/novie_tovary/samiy_noviy_tovar/ до /samiy_noviy_tovar/. Причем не для какого-то отдельного раздела или типа адресов, а по всему сайту в целом. То есть созданием виртуальных копий в корне сайта и модификацией шаблонов меню тут уже не обойтись — будут тысячи объектов в корне. Вот только в таких случаях действительно есть смысл препарировать UMI. Потому что система ЧПУ тут не внешняя-дополнительная, а является, можно сказать, частью ядра.
Скорость
С февраля 2011, начиная с версии 2.8.3, UMI позволяет готовыми средствами включить кэширование через nginx. И это все меняет. Существенно меняет.
Это не то кэширование средствами nginx, которое доступно в WordPress и некоторых других движках — когда горячие страницы помещаются в небольшой кэш в памяти и выдаются оттуда. Гораздо лучше. Не только горячие, но вообще все страницы сайта преобразуются в статику и выдаются nginx. Без запуска php, без mysql. Абсолютное ускорение. Не даром перевод сайта в статику под nginx является лучшим средством от DDOS.
Подробности о том как это настроить: http://wiki.umisoft.ru/Кэширование_через_nginx
В инструкции не сказано, как сделать исключение из кэширования для некоторых страниц, но это просто.
Также UMI CMS может бить все рекорды и без кэширования, на динамических данных, в случае если число страниц на сайте небольшое. Включаем memcached, при необходимости увеличиваем буфер на сервере, и нам доступны миллионы посетителей в сутки даже на слабом железе.
Безопасность
В antivirus-alarm.ru (антивирусный проект Kraftwork) постоянно обращаются за очисткой сайтов. И за несколько лет существования проекта собралась статистика. Так вот, сайтов на ЮМИ там нет. Первое место у Юкоза — оно и понятно, там школьники сами ставят себе на сайт «чудо-яваскрипты». Второе — у DLE. А UMI CMS вообще в этом дырявом списке нет. Ни однин владелец сайта на UMI за очисткой не обращался.
SEO
Просто перечень, комментировать тут нечего — кому надо, тот и так знает, что за некоторые из этих пунктов сеошник готов жизнь отдать:
— Встроенное, родное безотказное ЧПУ c автоматическим редиректом перемещенных страниц с 301-ым ответом сервера.
— Встроенная выдача 404-го ответа сервера на страницы ошибки Not Found (кажется, что это везде должно быть, но увы, во многих движках до сих пор страницы Not Found выдаются с кодом 200).
— Динамический тайтл, равный h1, и возможность задать префикс тайтла. Увы, нельзя задать суффикс и нет возможности задать префикс и суффикс тайтлам дочерних страниц, но это легко добавляется парой кастомных скриптов.
— Автоматическая карта сайта (начиная с февраля 2011, с версии 2.8) — всегда актуальный sitemap.xml
— Автоматическая генерация robots.txt (в версиях >2.8 учитывает многосайтовость в директиве host).
— SEO-модуль с обширной статистикой (правда, SEO-специалисты часто предпочитают универсальные инструменты статистики, такие как Google Analytics или Liveinternet).
UMI позволяет сделать даже автоматическую перелинковку страниц сайта по назначенным этим страницам тегам. В то время как адепты других движков разводят руками и отказываются делать подобное, на UMI разработчики просто добавляют в custom.php функцию, которая фильтрует выводимый на страницу контент, добавляя при этом перелинковку.
Недостатки
Можно очень долго расписывать достоинство UMI CMS, потому что Юмисофт долго над ней работали и успели за это время огромное количество всего хорошего сделать. Но справедливости ради надо найти и бяку.
Непростой вопрос, потому что выявить действительно серьезные системные недостатки UMI CMS не представляется возможным. Некоторые разработчики жалуются, что UMI не сообщает им о допущенных ими синтаксических ошибках, а просто вывешивает белый экран в случае поставленной не там запятой (для безопасности это хорошо, что не показывает ошибки, а нужен дебаг — сделайте error_reporting(55) ). Или жалуются на недостаточность API. Это несерьезно: CMS не является пультом управления Вселенной, у неё другие функции.
Скорее можно назвать ниши, где UMI CMS является не самым оптимальным вариантом. Это индивидуальный блог, где лучше использовать Wordpress. И отдельно стоящий форум (без общей авторизации с сайтом), где есть смысл выбрать между Vbulletin и Ipb. Последний имеет также редакцию, позволяющую построить сайт с форумом, объединенные единой авторизацией. Правда, CMS от Ipb мало знакома контентщикам, и это удорожает обслуживание такого сайта.
Причина неоптимальности UMI CMS для блогов и форумов в том, что специализированные «социальные» движки много лет развивались именно в этом направлении. Энтузиасту-блоггеру проще воспользоваться советами по настройке Вордпресса от других, таких же энтузиастов, знающих Wordpress, — это мир любительского сайтостроения.
Другой весьма редкий, но все же реальный случай, — когда заказчик сайта привык получать интересующие его данные напрямую из mysql, экспортировать в Эксель и обратно с помощью phpMyAdmin. Тут используемая в ЮМИ схема хранения информации с высокой степенью абстрагированности является препятствием. Если при этом сайт малобюджетный — тут UMI явно не оптимальный вариант. Но если проект серьезный — нет разницы, как хранятся данные. Делаем для заказчика таблицу в удобном ему формате и периодически экспортируем данные из ЮМИ в эту «подопытную» таблицу. Заодно избавляемся от проблемы «тяжелых» запросов, которые неизбежны при загрузках-выгрузках в Эксель огромных баз данных — потому что теперь заказчик мучает не mysql таблицы живого высоконагруженного сайта, а их «дублеров». Спасительный рецепт, если заказчик любит запросы с like, а таблицы по несколько гигабайт.
Старые версии UMI CMS
Тоже классные. В первый год жизни сайт на ЮМИ можно проапгрейдить бесплатно, и с современными (>2.8) версиями движка все пройдет на ура, если все дополнения делались в custom.php и/или в инклудах к нему. Если же вносились изменения в сам код модулей, то они могут потеряться при обновлении. При автоматическом апгрейде сильно старой версии UMI в некоторых случаях возможны серьезные проблемы — прекращение работы системы авторизации, в том числе авторизации в админцентр. База данных в старых версиях тоже имеет другой формат, и «подложить» её в свежеустановленную новую UMI CMS не получится. В такой ситуации остается либо перенести статьи руками, если их немного, либо сделать скрипт импорта на основе API.
Бесплатные редакции UMI Free старых версий были зашифрованы zend, и при апгрейде сервера до php 5.3 они перестают работать, так как zend для 5.3 отсутствует. Есть много хитрых путей все-таки пристроить туда zend, но проще скопировать незазендованные файлы из редакции UMI Corporate той же версии, что и ваша Free, — работает.
