Тому, щоб радити, треба бути готовим поручитися на 100%. І ми можемо з упевненістю рекомендувати UMI як систему управління сайтами і навіть, почасти, як фреймворк. Рекомендувати без винятків і застережень, як для крихітних сайтів-візиток, так і для мегапорталів і інтернет-магазинів.
Добре знаючи величезна кількість інших CMS, ми можемо пояснити, на чому грунтується наша думка.
Яку ліцензію вибрати?
Універсальність структури даних
Зазвичай розробники звикли бачити статті сайту в базі даних в табличці, лінійно: id конкретної статті - заголовок - анонс - текст.
У базі даних UMI.CMS дані зберігаються в іншій структурі: id абстрактного елемента - текстове поле - числове поле. Тут трохи складніше знайти заголовок і текст, але за допомогою API - кілька рядків коду - і ви отримаєте що завгодно. Ну, а якщо це «незручно» - на жаль, програмування це така область, де кращий приз дістається якраз за додаткове розумове навантаження. Якщо все ж є бажання піднятися на більш високий рівень структури даних, то з'являються нові цікаві можливості.
Наприклад, є інтернет-магазин керамограніта, де типовим товаром є «Плитка для підлоги срібляста, 1 кв. метр ». Все б добре, але ця плитка буває п'яти різних розмірів. І кожен розмір буває глянсовий, а буває матовий, і ще буває противоскользящий (для вулиці), і до кожної можуть додаватися ті чи інші декори (кромки та ін.). Декори стоять додаткових грошей, але вони не продаються окремо, а йдуть на додачу до одного метру відповідної їм плитки, і тільки до неї.
Приклад може здатися рідкісним, але в дійсності таких товарів багато: автомобілі (ціна залежить від комплектації), що збираються з комплектуючих комп'ютери, форми заяв на візу (та, з програмної точки зору це теж товар), кондиціонери (спліт-системи), і т . д.
У модулі «Шаблони даних» доповнюємо тип «Товар» додатковими полями:
Типорозмір 1, tip1, рядок, видиме;
Типорозмір 2, tip2, рядок, видиме;
і так далі до 15 (п'ять можливих розмірів плитки, помножені на три типи поверхні, дають 15 можливих варіантів типорозміру).
Аналогічно створюємо числові поля для цін:
Ціна за кв. метр 1 типорозміру, pr1, число, видиме;
Ціна за кв. метр 2 типорозміру, pr2, число, видиме;
і т. д. до 15.
Залишається модифікувати кошик, щоб вона приймала ще один параметр - типорозмір. Розписувати це немає сенсу, тому що в сучасній версії ЮМІ опціонні товари є і так. Ми зараз просто проілюструємо сам принцип.
Отже, якби ми робили це на движку з лінійним принципом зберігання даних, як Joomla, Netcat, Bitrix і ін. Нам би треба було додавати колонки в таблиці БД. А якщо у нас не один такий складний тип об'єктів, то довелося б взагалі створювати окрему іншу таблицю під ці додаткові властивості, і надбудовувати щось глобальне над усім движком.
Тут же у нас просто з'являються нові рядки в існуючій таблиці. Сама структура таблиці зберігається. Тобто якщо раніше запит по id елемента товару повернув би нам назву, ціну і картинку, то тепер він нам повертає ще і типорозміри цього товару і ціни на них. При цьому в інших елементах, таких, як статті, як і раніше залишилися назву і контент - нові властивості повертаються тільки для того елемента, у якого вони є.
Очевидно що на простому сайті, де є тільки один тип даних - статті - таблиця з лінійним зберіганням даних видаватиме контент швидше. У той же час, якщо у нас є багато хитромудрих об'єктів з різними властивостями - реалізований в ЮМІ метод зберігання даних є оптимальним, якщо не сказати геніальним рішенням. Платою за універсальність в деяких випадках може виявитися швидкість, але цю проблему творці UMI вирішили ідеально. Але про це пізніше, а зараз головне питання: і як дістати ці дані, щоб вивести на сторінці сайту?
Прямі запити до бази не потрібні, тому що цю роботу за нас зроблять API і шаблонизатор.
Життя - вона мінлива і непередбачувана. І жоден збірник готових рецептів не дасть відповідей на всі ситуації. API не повинен претендувати на управління Всесвіту, він повинен спрощувати типові рутинні речі. І тільки ті з них, які дійсно треба спрощувати. Тільки дійсно складні речі, а не все підряд.
Шаблонізатора два, xslt і старий, tpl. Краще, звичайно, починати з xslt, щоб перестрибнути відразу через сходинку, але зараз для наочності візьмемо приклад з tpl-шаблонізатором.
Досить зробити так:
Аналогічно можна вивести будь-яке поле даних будь-якого об'єкта одним макросом, взагалі не знаючи php. І це дійсно серйозний крок вперед, до того світлого майбутнього, коли будь-який нормальний чоловік без навичок програмування зможе займатися серйозним корпоративним сайтом.
Макроси універсальні, і їх небагато. Їх можна вставляти як в шаблони, так і в текст статті. Так що з UMI контент-менеджер може керувати сайтом повністю самостійно, в той час як в інших CMS для виконання такого завдання треба було б участь програміста.
На простому редагуванні шаблонів і вставці макросів вже можна побудувати дуже багато. Якщо у Вас старша редакція з великою кількістю встановлених модулів, то навіть просунутий інтернет-магазин може зробити вебмастер не повідомляючи php.
Коли функціоналу макросів недостатньо, на допомогу приходить API. Для тих, хто прийшов з інших движків іноді буває неочевидним спосіб його використання в ЮМІ. Наприклад, вони чудово розуміють суть виклику API для отримання вмісту поля "telefon" зі статті з id рівним 5:
Але те, що починається далі, перетворює їх життя в кошмар, і вони шлють ЮМІ прокляття. Тому що вони лізуть в код движка, шукають там функцію, що виводить на сторінку контент, і за допомогою різних хаков намагаються вкрутити в цей, сильно абстраговані і об'єктно орієнтований, код свою вставку у вигляді наведеного вище коду. Вони міркують: це правильно, адже я використовую API. Але немає. Лізти в сам движок має сенс тільки, якщо це епохальна модифікація, якщо потрібно щось основоположне змінити. У розробці на ЮМІ втручання в код самого движка дійсно вкрай рідко буває.
Досить просто додати в /classes/modules/custom.php нову функцію:
Розробники, які звикли до потужних фреймворками зразок CodeIgniter, намагаються знайти в API функцію, яка б видала дані у вигляді красивої таблички. Наприклад, товари в інтернет-магазині. Такого немає, API в UMI - це міст між даними і шаблонізатором. Тобто таблицю повинен буде малювати шаблонизатор за тією схемою, яка йому дана tpl (папка / tpls /) або xslt шаблоні (/ xsltTpls /). Іноді йому можна допомогти. Припустимо, нам треба вивести товари таблицею в три колонки. Блокова верстка - це відмінна річ, але коли справа стосується колонок, то часто оптимальним варіантом є таблиця. І не тільки xslt, але і tpl шаблонизатор теж може її побудувати:
- Виведемо товари макросом # 037; catalog getObjectsList ( '3_col_template') # 037; - Скопіюємо шаблон / tpls / catalog / default в / tpls / catalog / 3_col_template і відредагуємо наш новий шаблон, вставивши туди теги таблиці. - Додамо в новий шаблон, в кінець фрагмента objects_block_line макрос # 037; custom splitter (207 # 037 ;. Передача параметра id потрібна, щоб обійти кешування макросу. - Додамо в /modules/classes/custom.php функцію:
Ця функція видає роздільник рядів таблиці на кожен третій (або інший заданий змінної $ cols) виклик, і товари виводяться в три колонки.
Коли дійсно є сенс модифікувати сам движок
Це не те кешування засобами nginx, яке є в WordPress і деяких інших двигунах - коли гарячі сторінки поміщаються в невеликий кеш в пам'яті і видаються звідти. Набагато краще. Не тільки гарячі, але взагалі всі сторінки сайту перетворюються в статику і видаються nginx. Без запуску php, без mysql. Абсолютна прискорення. Не дарма переклад сайту в статику під nginx є найкращим засобом від DDOS.
В інструкції не сказано, як зробити виняток з кешування для деяких сторінок, але це просто.
Також UMI CMS може бити всі рекорди і без кешування, на динамічних даних, в разі якщо число сторінок на сайті невелике. Включаємо memcached, при необхідності збільшуємо буфер на сервері, і нам доступні мільйони відвідувачів на добу навіть на слабкому залозі.
Безпека
У antivirus-alarm.ru (антивірусний проект Kraftwork) постійно звертаються за очищенням сайтів. І за кілька років існування проекту зібралася статистика. Так ось, сайтів на ЮМІ там немає. Перше місце у Юкоз - воно й зрозуміло, там школярі самі ставлять собі на сайт «чудо-яваскрипт». Друге - у DLE. А UMI CMS взагалі в цьому дірявому списку немає. Ні однин власник сайту на UMI за очищенням не звертався.
UMI дозволяє зробити навіть автоматичну перелинковку сторінок сайту по призначеним цих сторінок тегами. У той час як адепти інших движків розводять руками і відмовляються робити подібне, на UMI розробники просто додають в custom.php функцію, яка фільтрує виведений на сторінку контент, додаючи при цьому перелинковку.
недоліки
Можна дуже довго розписувати гідність UMI CMS, тому що Юмісофт довго над нею працювали і встигли за цей час величезна кількість всього хорошого зробити. Але справедливості заради треба знайти і бяку.
Непросте питання, тому що виявити дійсно серйозні системні недоліки UMI CMS не представляється можливим. Деякі розробники скаржаться, що UMI не повідомляє їм про допущені ними синтаксичних помилках, а просто вивішує білий екран в разі поставленої не там коми (для безпеки це добре, що не показує помилки, а потрібен дебаг - зробіть error_reporting (55)). Або скаржаться на недостатність API. Це несерйозно: CMS не є пультом управління Всесвіту, у неї інші функції.
Інший вельми рідкісний, але все ж реальний випадок, - коли замовник сайту звик отримувати потрібні йому дані безпосередньо з mysql, експортувати в Ексель і назад за допомогою phpMyAdmin. Тут використовується в ЮМІ схема зберігання інформації з високим ступенем абстрагування є перешкодою. Якщо при цьому сайт малобюджетний - тут UMI явно не оптимальний варіант. Але якщо проект серйозний - немає різниці, як зберігаються дані. Робимо для замовника таблицю в зручному йому форматі і періодично експортуємо дані з ЮМІ в цю «піддослідну» таблицю. Заодно позбавляємося від проблеми «важких» запитів, які неминучі при завантаженнях-вивантаженнях в Ексель величезних баз даних - тому що тепер замовник мучить НЕ mysql таблиці живого високонавантаженого сайту, а їх «дублерів». Рятівний рецепт, якщо замовник любить запити з like, а таблиці по кілька гігабайт.