Пока народ отдыхает на Рождество, я между делом разбираюсь в новой версии Bolt CMS. Вот некоторые интересные нововведения я хотел бы показать.

SEO и CMS

Меня больше всего бесит в классических CMS забитые поля при создании и редактировании статьи. Хочешь что-то добавить для SEO и упираешь в стенку — НИЗЗЗЗЯ! И ищешь плагины, которые бы подправили бы вывод на страницу всего-то описания страницы и ключевых слов. Да, я знаю, что ключевые слова не принимаются во внимание поисковыми системами, да, я знаю, что они часто генерируются из тизера (короткого описания) страницы. Но я предпочитаю делать все руками и до символа управлять выводом страницы. Да и ключевики умерли в качестве способа повлиять на выдачу в поисковой системе. А вот в качестве дополнительного описания страницы для микроразметки они все ещё в ходу. Так что совсем не лишнее иметь возможность настраивать все по своему вкусу.

Bolt CMS явно относится к конструкторам контента CMF, а не просто к CMS — системамуправления контентом. Вот я и сегодня исследовал именно эту возможность.

Если поглядеть в настройках appconfigcontenttypes.yml, то там явно заложены все поля на все типы контента. Вот только они как средняя температура по больнице и подходят не для всех. В шаблонах, идущих с дистрибутивом Bolt CMS, прописано использование именно этих полей.

А я захотел сделать другую разметку в учебных и практических целях.

Типы контента

Любая страница сайта на Bolt CMS относится к какому-нибудь типу. И типы эти равноправны. Сама идея очень похожа на Drupal.

У такого подхода есть очень много плюсов — страницы отображаются в табличной форме и легко осуществлять навигацию по материалам. И не важно сколько таких страниц/материалов на сайте, поскольку движок выберет и покажет только нужные, в отличие от MODX, где ресурсы хранятся в дереве. И когда ресурсов в дереве много, админка начинает притормаживать.

В такой реализации Bolt CMS есть большой косяк с ЧПУ — при назначении главной странице сайта одной из страниц, произойдет дублирование контента по адресам https://site.ru/ иhttps://site.ru/page/slug-page. Решить эту проблему можно либо закрыть дубль в файле robots.txt, либо настроить редирект 301 в .htaccess, либо в самом движке в роутинге, куда мои шаловливые руки еще не дошли.

Для экспериментов я залез в настройки contenttypes.yml и поправил тип Pages.

Опять же, маленькое уточнение: pages и page используется для генерации URI страницы и если забить русскими буквами (обязательно сохраните файл в UTF-8), то в админке будут отображаться русское название раздела «Контент», но вот при генерации адреса будет что-то типа /stranica/washa-stranica, что на мой эстетический вкус не слишком хорошо смотрится, поэтому я не стал менять эти значения.

Вот получившийся тип страниц

pages:
    name: Pages
    singular_name: page
    groups: ["content", "seo"]
    fields:
        title:
            type: text
            class: large
            group: content
        slug:
            type: slug
            uses: title
        image:
            type: image
        teaser:
            type: html
            height: 150px
        body:
            type: html
            height: 300px
        template:
            type: templateselect
            filter: '*.twig'
        description:
            type: textarea
            postfix: "

Постараться кратко описать страницу не более 180 символов;

;» group: seo keywords: type: text class: large robot: type: checkbox label: «Исключить из индексации?» taxonomy: [ chapters ] recordsperpage: 100

Теперь маленькие пояснения

1. В начале я определяю вкладки, куда я помещу страницы: content и seo. Обратите внимание, что группы заданы только два раза. Движок все следующие поля без указания ставит в вышеуказанную группу.
2. Для SEO параметров страницы я завел 3 новых поля: description, keywords и robots.
3. Robots – это поле типа чекбокс для отключения индексирования страницы путем добавления в раздел head страницы метатегов

   ;

Теперь остается лишь сохранить файл, зайти в админке в Настройки – Проверить базу данных и обновить там базу, которая Bolt CMS автоматом приведет в соответствии с отредактированными настройками. Вам не придется делать миграции, лезть в базу руками и делать тому подобные глупости. Это радует.

Вкладки редактора контента

Заходим теперь в редактирования контента типа Pages и видим, что вкладок стало 4 и поля разнесены по вкладкам. Что я и добивался. Так что теперь не нужно заполнять огромную портянку при редактировании страницы а-ля WordPress.

Это как раз новая фича Bolt CMS.

Добавление новых полей в шаблон Bolt CMS

Теперь было интересно добавить новые поля в шаблон.

Шаблон Bolt CMS состоит из файлов с расширением twig, которые движок уже превращает в страницы. Код php в нем вырезается, так что не надейтесь использовать программирование чего-нибудь на php. Самого шаблонизатора twig хватает для условий, вывода и чуток сверху. Так что наговнокодить в шаблоне у вас не получится J.

Основных шаблонов несколько, они имеют говорящие (на английском назнвания) и они начинаются с буквы. Есть еще вспомогательные шаблоны (в терминологии MODX – чанки), которые имеют начинаются с знака нижнего подчеркивания. Вот как раз над таким шаблоном _header.twig я и буду экспериментировать.

Чтобы много не писать, я выведу файл, доступный для скачивания. А вот некоторые кусочки я прокомментирую.

Увы, я пока не въехал в то, как выводятся данные со страниц, я только «обезьянничаю»  и сдираю готовое, модифицируя под свои нужды.

  {% if record.title is defined %}{{ record.title|striptags }} | {% endif %}{{ app.config.get('general/sitename') }}
  {% if record.title is not defined and app.config.get('general/payoff') %} | {{ app.config.get('general/payoff') }}{% endif %}

Тут просто, все готовое. Если у записи есть поле title и оно заполнено, то выводится оно, очищенное от тегов, затем пробел и вертикальная черта и название сайта. Иначе будет выводиться что-то. Но  не заполнить заголовок система не даст, так что тут просто перестраховка.

<meta name="description" content="">

Тут я вывожу в качестве описания из поля тизера, очищенного от тегов. Можно использовать и поле description, его я использую далее.

Вот первая микроразметка:

Как видите, здесь по аналогии я вывожу название сайта, для заголовка карточки название страницы если оно есть, описание страницы, урл страницы и картинку если она есть.
Есть косяк с УРЛ – будет выводиться именно настоящей урл страницы и на главной будет ссылка на именно основной урл, что очень не хорошо. Тут нужно будет еще подумать и включить проверку на главную страницы, как это сделать я пока не разобрался.
Вот вторая микроразметка для twitter:
Здесь все по аналогии и комментировать уже особо нечего.
А вот кусок выключения индексирования:
{% if record.robot == "1" %}{% endif %}

Так что, если поставить галку в админке, выведется конструкция для запрета индексирования. Это наиболее простое и удобно решение, чем выпадающее меню. А отключить некоторые страницы просто необходимо: ну зачем индексировать форму обратной связи или выдачу поиска по сайту, служебные страницы типа 404 и 403.

Все остальное — это моя попытка сходу адаптировать шаблон моего тестового сайта на MODX Revolution  на новую для меня систему Bolt CMS.

Заключение

Сходу мне не слишком много удалось продвинуться без перевода документации. Но мои эксперименты будут полезны тому, кто изучает эту систему и позволит ему сэкономить чуть-чуть времени и что называется «въехать» в новую систему. Так что с такими мыслями я выкладываю эту статью.







2019-03-23T20:22:34
CMS

История знает много психозов, когда люди искали самое-самое в какой-то области. Наиболее известным из них, пожалуй, является философский камень. Искали его как средство создания универсального эликсира от всех болезней, а уж во вторую очередь как способ обратить свинец в золото (это сейчас думают наоборот). Военные всегда мечтали об «вундервафле» (зайдите на Луркоморье и почитаете статью пока можно) как способе победить противника на войне. Поиски идеальной CMS можно отнести к этой же «внудервафле», только в веб-дизайне.

Сколько стоит сайт

Известно уже, пожалуй, всем, что экономист мира рассматривают стоимость любого предмета как совокупность затрат по его приобретению, владению (обслуживанию) и утилизации. Каждый из этих разделов затрат имеет свои статьи и подстатьи в зависимости от предмета. Как раз на этом сыграло правительство России, когда ввело утилизацию автомашин и таким образом повысило конкурентность российского автопрома после вступление в ВТО. Все по закону и скрепи зубами, не скрипи, а плати. Плохо это или хорошо — это другой вопрос за гранью статьи.

«Но ведь сайт — это не предмет!» — скажите вы. И будете абсолютно правы. Но законы экономики работают и здесь. Сайт нужно создать, а это значит заплатить за разработку, купить хостинг и доменное имя и разместить его на сервере хостера. Сайт нужно поддерживать, а значит вовремя платить хостеру, регистратору доменного имени, копирайтерам, фотографам и обслуживающему персоналу. Нужно платить за жесткий диск, где хранятся архивные копии. И только утилизация ничего не стоит – написал письмо хостеру и он все стер.

Поэтому я буду рассматривать сайт именно в этом ключе.

В предыдущей статье я кратко прошелся по движкам для создания сайтов и затронул немного такие понятия как производительность и удобность.

Производительность движков

Вот график распространенности движков по версии сайта itrack.ru:

Если исходить из производительности, то WordPress не имеет шансов на жизнь. Однако, по статистике именно WordPress — самая устанавливая система в мире. В мире!

У Joomla! тоже плохая производительность и люди жалуются, что хостинг плохо тянет систему. Её тоже нужно выкинуть на помойку? А ведь именно Joomla! — это второй номер в списке самых устанавливаемых движков в мире.

Жалобы на плохую производительность во многом происходит как продолжение достоинств этих систем. Из-за легкости входа в мир веб-разработки этих систем именно эти движки используют далекие от мира интернета люди. Не обладая нужными знаниями, они берут хороший, но тяжелый движок, вешают всякую всячину и получают сайт, тормозной донельзя.

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

В этом отношении CMF имеет преимущества в том, что порог вхождения гораздо выше и эти систем идут люди, которые имеют уже представления веб-разработки, как и что делается внутри и могут самостоятельно подправить и оптимизировать систему.

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

Удобность движка

Для разработчика удобны в первую очередь CMF типа MODX и Drupal, поскольку есть документация, наработанные решения и системы получились очень гибкие в работе. То есть вы можете сделать себе блог, портфолио, статейник, продвинутую фотогалерею в одном движке, что сложно сделать в обычной системе типа Joomla или WordPress.

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

Разработка сайта на движке

Самая замечательная в плане удобства использования является WordPress. На этом движке можно развернуть сайт на готовом шаблоне практически за пару часов. И это не преувеличение. Основное время займет заливка и установка движка, скачивание и активация плагинов. Останется только отрегулировать вывод в шаблоне плагинов и сайт готов.

А больший функционал можно получить более глубокой проработкой шаблона и добавлением плагинов. Таким образом даже интернет-магазины запускаются (нет, до ozon.ru им очень далеко, но как витрина на пару десятков/сотен товаром можно сделать легко).

Точно так же можно легко запустить сайт и на Joomla!, когда вы на готовый шаблон легко создаете категории материалов, публикуете начальные материалы и затем настраиваете меню. А уж затем добавляете всякие плишки и виджеты в разные блоки.

Ключевое удобство тут именно в первоначальном быстром развертывании сайта.

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

В MODX идеология совершенно другая и разработка сайта происходит по-другому. Тут создаются шаблоны под виды страниц, по ним создается дерево ресурсов, которые будут отображаться и им назначаются шаблоны. А уж затем происходит наполнение шаблонов, подключаются программы выводов контента, настраивают вывод меню и так далее. То, что занимают несколько кликов в WordPress, тут приходится руками прописывать и настраивать. Зато под разработчиком весь вывод до последнего тега. Разработка сайта получается более долгая, зато сайт делает только то, что требовалось с автоматизацией, которая часто получается больше и лучше, чем в стандартных движках. Хотя некоторая половинчатость и неудобность от некоторых решений присутствует.

А вот стоимость разработки сайта зависит от сложности функционала, количество свободных специалистов на рынке труда. Поэтому обсуждать на каком движке будет дешевле сделать сайт не имеет смысла без техзадания. Одно можно сказать, что разработка сайта на Joomla! и WordPress в базовом функционале примерно одинакова, как и на MODX. На Drupal будет дороже из-за сложности системы.

Поддержание сайта

Когда сайт запущен и работает, приходится за ним присматривать: удалять спам, редактировать статьи, публиковать новые.

И вот тут разница в движках проявляется во всей красе!

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

В качестве такого примера можно привести движки DLE и NG CMS. Оба эти движка имеют одного предка, по идеологии они идут для новостного портала и обои используются для каталогов/варезников/новостных порталов. Вот только в NG CMS с правами очень плохо – разграничений почти нет, плохо проработано удобство. И несмотря на то, что NG CMS бесплатная, а DLE платный движок, на первой сайтов очень мало, а на DLE их огромное количество.

Drupal — это другой пример важности прав. Сам по себе Drupal очень тяжелый движок, разработка на нем сложна, а удобство довольно посредственное. Но разграничение прав просто замечательное! Поэтому на нем очень любят разрабатывать крупные сайты-порталы, где контент генерируется не только разработчиком/заказчиком, а самими посетителями.

Второе, что бросается в глаза — это удобство редактирования и добавления контента. Визуальные редакторы, написанные на javascript есть практически у всех систем. Но вот обрамление к ним, продуманности интерфейса и удобство всего этого часто продумано плохо. Я называю это проблемой open source – прекрасная идея лежит в основе, но интерфейс «писал программист для программиста».

Интерфейс WordPress, опять же, даже при некоторой странности редактора, просто отлично проработан, есть куча мелочей, которые просто не замечаешь, но которых очень не хватает в других движках. Аналог WordPress на php framework CodeIgniter MaxSite CMS при большей производительности сильно проигрывает именно по редактору и вообще общему удобству пользования. И именно из-за этого не сможет составить конкуренцию WordPress в обозримом будущем.

Но и редактором не заканчивается важность интерфейса движка. В WordPress прекрасна поставлена работа с комментариями – очень легко подключить плагин антиспама, легко просматривать, одобрять или удалять комментарии, легко отвечать на комментарии. Кроме того, легко можно настраивать боковые панели сайта и таким образов менять сайт.

В Drupal с редактором все грустнее, но хорошо поставлена работа с боковыми панелями. Но самое замечательное именно в этом движке поставлена работа с каталогизацией – разбиения материалов по некоторым признакам: категориям, тегам и по другом признакам.

В движке MODX  есть редактор, есть гибкие шаблоны и настраиваемая форма редактирования материала. Интерфейс вылизанный и очень неплох. Кроме того, в нем есть дерево ресурсов, где очень легко ориентировать в структуре сайта. Но для того, чтобы разбираться с принципами админки требуется некоторое время. А вот с блоками в панелях работать конечному редактору не удобно – они забиты в шаблон и так просто как в WordPress или Drupal их не поправишь.

Bolt CMS имеет простую админку, редактор, разделение материалов по признакам и многое другое. С одной стороны, есть все, что нужно как в Drupal или MODX, а с другой стороны немного не привычная идеология разработки. К сожалению, документация вся на английском и её явно не хватает. И очень большая проблема с готовыми решениями. Я пытался разобраться с несколькими плагинами, но мне так и не удалось заставить их заработать сходу, а документации по ним явно недостаточно. Хотя у системы есть отличный потенциал, с ней нужно разбираться очень серьезно.

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

Какую же выбрать CMS/CMF?

Как видите, любая система имеет свои плюсы и минусы, ведь живем мы не в идеальном мире. Так что нет CMS, которая была бы самая-самая для всех видов сайтов.

Прежде чем выбирать систему под проект, я бы посоветовал сделать следующее:

1. Составить самому себе техническое задание на создание сайта: что за сайт, цель его создания, каким вы его хотите видеть, что он должен отображать, разделы и так далее. Таким образом вы поймете тип сайта.
2. Как вы планируете его расширять и обслуживать. Если вы сейчас хотите сделать визитку, а затем добавить блок новостей, то пойдет почти любой движок. А если вы планируете добавить каталог, интернет-магазин, портал и так далее, то тут уже нужен профессионал и он уже подскажет как реализовать это, но и стоить это будет денюжку. Учтите, что все навороты, которые у вас голове вертятся в 99% просто не нужны и просто вредны.
3. По техзаданию и планам по расширениям задайте вопросы на профильных форумах и проанализируйте ответы. Обратите внимания на цены решний, плюсы и минусы.
4. После отбора движков на форумах, посмотрите как с ними работать на ютубе, вимео, скачайте видео уроки. Достаточно получить общее впечатление как ставить и как настраивать.
5. Скачайте каждый движок и попробуйте сайт-пример, который идет практически к каждому движку в деле. То есть попробуйте подстроить под себя. И вы поймете, что вам нравится или не нравится, что вам понятно, что не понятно. У вас появится свое предпочтение движка. Например, я не делаю сайты на Joomla! – ну не нравится мне этот движок, хоть убейте.

А вот когда вы руками пощупали движки, отобрали 1-2 претендента, идите уже на профильные форумы и сообщества и задавайте вопросы как реализовать нужный вам функционал, спрашивать сколько это будет стоить, кто бы мог помочь и кого бы вы посоветовали. Таким образом вы быстро войдете в курс дела и поймете что сколько стоит. И тут уже будет планировать и делать.

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

Зачем нужна CMS

Одна из больших статей затрат при создании сайта — это программирование. Статические сайт, которые не могут взаимодействовать с пользователями безвозвратно уходят: нужны комментарии, формы заказов, подписки и обратной связи, фильтры товаров и многое другое. Часть такого функционал можно реализовать за счет подключения сторонних сервисов типа внешних комментариев Disqus или формы обратной связи Reformal. Но у такого решения есть и минусы (кто бы сомневался!), да и изменять сайт лучше самому и в понятной административной панели, нежели руками править файлы html.

Вот для облегчения именно этой задачи – поддержания сайта – и были разработаны всякие-разные CMS. Писали и пишут их как энтузиасты «just for fan», так и серьезные дяденьки на заказ за деньги (например, Bitrix).

CMS и CMF

Причем, если разобраться, все такие системы управления сайтами делятся на две большие группы:

• CMF (content management framework) — среда (каркас)  проектирования и разработки систем управления контентом;
• CMS (content management system) – система управления содержимым сайта.

Кроме разницы в последней буковки, разница не в возможностях, а в идеологии разработки. Если CMS — это законченная система под конкретную задачу, где функционал развивается подключением модулей, написанными сторонними программистами, в готовую систему, то в CMF готовых решений нет и их обязательно нужно подгонять под нужды конкретного заказчика, что дает возможности строить гибридные сайты с одной админкой.

Можно много спорить, какая система к чему относится, какие формальные признаки одного и другого. Но все это не нужно! Разница, повторюсь, в идеологии. Задуманный сайт можно собрать на любой системе, вопрос только в том, сколько нужно сил на это и сколько это будет стоить.

Другая сторона CMS и CMF в том, что интерфейс первой заточен больше под пользователя и более удобен для поддержания сайта, а второй более удобен для разработчика, но не слишком удобна для пользователя. Но и в первом случае, и во втором, нужно учиться пользоваться админкой для поддержания сайта.

Он-лайновые конструкторы сайта

Пожалуй, самым известным таким конструктором является ukoz. На это платформе очень много сайтов было сделано и до сих пор висит в рунете, созданные руками тех, кто не хотел и не хочет платить за хостинг, доменное имя. Это и энтузиасты чего-нибудь, кланы он-лайновых игр и многое другое. Сейчас ukoz негласно считается среди разработчиков этакой помойкой, где не стоит размещать свой сайт. Тем более, что такой сайт не добавишь в серьезные каталоги, там нельзя размещать рекламу и есть еще куча ограничений.

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

Для интернет-магазинов есть свои такие он-лайн конструкторы, сходу вспомнить название не получилось, но если захотите, то гугл вам поможет найти.

Так что этот сегмент существует и имеет право на существование, поскольку люди пользуются и платят за это деньги.

Если глянуть в глубину, то такие сервисы подходят для именно визиток, которые делаются быстро без изысков под маленького предпринимателя, захотевшего выйти в интернет и вести в нем бизнес.

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

С другой стороны, в такой сайт боязно вкладывать деньги на раскрутку в поисковых сетях, на продвижение в социальных сетях, ведь вы не владеете даже доменным именем.

Так что подумайте хорошенько, стоит ли связываться с такими конструкторами.

Блоговый платформы онлайн

Если вы хотите вести личный дневник или блог, то есть пару бесплатных сервисов: LiveJournal и Blogpost, где можно бесплатно вести свой блог. Возможностей там оформления маловаты, как и превратить страничку в разукрашенную ёлку, но для контента вполне достаточно.

LiveJournal или ЖЖ (перевод «живой журнал) очень популярен среди людей, которые просто ведут свой блог. Есть очень раскрученные блоги, особенно по политике. Народ даже научился делать там деньги, хотя это как бы запрещено (или просто не поощряется руководством ЖЖ).

Blogpost – это сервис от «корпорации добра», где еще меньше возможностей, чем ЖЖ. Но и там тоже народ ведет свои дневники.

Для заработка в сети такие платформы подходят очень плохо и если ваша цель зарабатывания денег, то не стоит сюда вкладывать время и деньги. А вот если для себя и бесплатно, то это хорошая альтернатива своему сайту.

Итак, с онлайн сервисами разобрались, вернемся к CMS/CMF системам.

Типы CMS/CMF

Все системы для создания сайтов пишутся под задачи: визитки, блоги, порталы, фотогалереи, форумы, интернет-магазины и так далее. Это не означает, что на форуме не может быть блогов или нельзя прикрепить фотогалерею. Это сделать можно, как и просто поставить несколько движков, которые объединить программно.

Можно еще разделить системы по способам хранения данных: в базах типа MySQL (PostreSQL), в файле базы SQLite и в обычных файлах. Каждое решение имеет как свои плюсы, так и минусы.

СMS на файлах

CMS на хранении данных в файлах имеют огромное количество плюсов для пользователя, поскольку нужно просто сжать на хостинге в архив и скопировать себе на компьютер — вот и весь бэкап. Точно так же легко развернуть сайт – закачал архив, развернул в нужную папку, настроил права на файлы и папки и все готово. Разработчику легко использовать системы контроля версий типа git, удобно работать в любимой IDE.

А вот дальше начинаются минусы, которых не меньше.

Прежде всего, доступ в базу и выборку значений происходит быстрее, чем работа с файлами, требуют меньше памяти. Да и работа с MySQL проще и понятнее для выборки данных для отображения. А значит разработка стоит меньше, плагины становятся проще и их удобнее писать/редактировать. Тут всего это преимущества нет и в помине! Попытки прикрепить выборку через  xml в GetSimple дали положительный эффект, но при большом количестве материалов время генерации увеличивается очень существенно.

Так же трудно сделать уже выборки по условиям (фильтры товаров для примера), комментарии.

Кеширования страниц обычно тоже не реализовано, либо реализовано плохо.

Так что область применения таких CMS довольно ограничено: визитки и простые витрины, если добавить скрипты на javascript, то и простенькую корзину заказов, а значит можно реализовать и интернет-магазин. В принципе, разработчики таких CMS именно так и позиционируют свои системы.

CMS/CMF на базах данных

SQLite — это подмножество баз данных, которые имеют свои недостатки. Но буду рассматривать именно в этом разделе, поскольку обычно sqlite — это опция выбора между MySQL или SQLite.

Поскольку база sqlite хранится в одном файле в папке с сайтом, то часть проблем работы с файлом присутствует и здесь: нужно загружать весь файл с память, пока происходит доступ к файлу, блокируются другие запросы к файлу, доступ к данным дольше, чем у MySQL. Но с другой стороны уже гораздо легче делать выборку данных. SQLite поддерживается средствами PDO и написав выборку для PDO, она подойдет и для sqlite и для MySQL.

С другой стороны, переносить такой сайт так же легко, как и CMS на плоских файлах.

MySQL сейчас установлен даже на бесплатных хостингах, так что с этой точки зрения файлы давно потеряли преимущество перед базами. А архивировать сайт можно легко в админке хостера или в веб-интерфейсе доступа к базе phpMyAdmin.

На MySQL создаются более универсальные системы и более производительные.

Производительность движков сайтов

Когда начинается выбор из однотипных движков под одну задачу, веб-разработчики начинаются мерятся главным мужским половым признаком производительностью.

Критериями производительности и нагрузки на сервер хостера являются потребление памяти и время генерации страницы. Именно по этим критериям идут жестокие баталии на форумах!

Данные по производительности систем

Я приведу свои данные, которые я лично проверил как на локалке, так и на тестовом  shared хостинге в одинаковых условиях:

Сайты были небольшие и не сильно сложные.  Так что данные не совсем корректные, поскольку известно, что MODX Evolution при большом количестве страниц начинает резко увеличивать потребление памяти и при определенных условиях прекращает работать (виновата система кеширования).

Это то, что выдают сами системы при генерации страницы.

Тестирование в браузере

Все эти данные будут корректны только для потребления памяти. А если глянуть в браузере сколько качается и как отображается страница?

Тут ждет очень неприятный сюрприз!

Google Chrome и расширение PageSpeed дает интересные данные, что средняя страницы в пределах 15-50 кб. Всего лишь. Именно её и генерит  движок сайта, причем можно глянуть время от запроса на сервер и на отдачу страницы. Так вот, он примерно одинаков – около 400 миллисекунд. В это время входит и время получения сервером запроса, запуск движка и генерации страницы и отдача заголовка. И получается, что особой разницы нет. Хороший сервер с широким каналом и тормозным движком легко обойдет плохой сервер с легким движком.

Другая часть проблемы состоит в том, что средняя страница полностью весить около 4 Мб. То есть в 100 раз больше! И это графика, скрипты и стили. Получается, что в среднем страница на нормальном канале в 5 Мбит/с грузится около 3-5 секунд.

Получается, что время генерации пользователю не важны!

Нагрузка на сервер

Но не ужели не важна производительность движка? Очень важна, но для облачных хостеров. Ведь вы платите за потребленные ресурсы и чем больше вы будете потреблять время процессора, тем больше вы заплатите. И миллисекунды складываются во вполне ощутимые рубли.

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

И тут есть один тонкий момент: а когда происходит отключение? При посещении 10 человек, 100 человек или 1000?

Самый тяжелый движок WordPress на хостинге Sprinthost.ru на начальном тарифе без кеширования выдерживал 2-3 тысячи посетителей в сутки. Такой наплыв нужно еще обеспечить! Тогда решили просто переходом на более высокий тариф, а впоследствии подключили кеширующие плагины и все решилось в лучшем виде. Сейчас хостер поставил диски SSD и скорость сайтов возросла в несколько раз.

Можно было еще сжать стили, почистив от не нужных правил, объединить картинки оформления в спрайты, разнести по CDN часть файлов типа jquery, убрать часть плагинов, комментарии подключить на Disqus. В общем, вариантов оптимизации много.

А при такой посещалки достаточно поставить простейшую рекламу от Google AdSence и легко можно поднимать 100-200$ в месяц почти на любой тематике. И уж этой суммы вам будет хватать на любой хостинг, даже на выделенный сервер.

Какой же следует вывод – производительность важна характеристика, но сейчас она отходит на второй план перед удобством использования движка.

Удобство разработки и использования движка сайта

На мой взгляд, сейчас на первый план приходит удобство разработки и использования движка. Если нужно учиться использовать систему целую неделю, мучиться при добавлении или исправлении материала, то какой бы производительной она не была, я не буду её использовать. И никто не будет.

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

Любимое занятие техно снобов — это сравнивание жидкого и мягкого а-ля «что кручи кит или слон».  У веб-дизайнеров сравнение идет по скорости генерации картинки или потребляемой памяти движков сайта. И куча всяких тестов по фреймворков, версий php, ruby vs python и так далее.

И так же «известно всем» (кстати, это логическая ошибка — апеллирование к толпе), что WordPress медленный, а вот CMF/CMS MODX быстрый. Вот по этому я и хочу чуток пройтись.

PageSpeed

У Google есть сервис сравнения скорости сайтов — PageSpeed. Слышали многие, а вот не все пользуются (либо пользуются от случая к случаю). Там можно проверить не только скорость загрузки сайта, но и получить ценные подсказки. Кто не знает, скорость меряется комплексной оценкой от 0 до 100. И чем больше баллов, тем быстрее работает сайт.

Основные критерии:

1. скорость отдачи сервера (косвенно — и насколько быстро отдает CMS)
2. оптимизация кода страницы
3. оптимизация css стилей
4. оптимизация js скриптов
5. оптимизация картинок
6. кеширование в браузере

Если у этого сервиса аналоги? Конечно есть! Но они константируют факты, но не делают выводы и не дают советы. Кроме того, в зависимости откуда вы меряете и что, результаты разнятся.

А тут как бы легко можно проверить, получить советы. И расположение сайта не зависит.

Что мерить будем

Лично я этим сервисом не пользовался, но вот просматривая на ютубе канал финты WordPress, я наткнулся на серию видео уроков по ускорению сайта на WordPress и решил проверить свои проекты на этом сервисе до и после оптимизации.

Подопытные кролики: сайт «Отдых в Анапе» на MODX Evolution (по всем отзывам — очень быстрый движок), сайт «Гараж строим сами» на WordPress со сложной темой, сайт друзей «Геленджик» с простой неадаптивной темой и этот блог, который я перевел на простую бесплатную тему Basic. Ну и до кучи сайт на MODX Revolution как тестовый сайт (ссылка уже не работает, я ее удалил) . Как видите, ссылки не скрываю, сами можете меня проверить.

Чтоб было сделано для ускорения

Сайты на WordPress были немного оптимизированы сайты Гараж и этот блог:

1. Переведены на PHP 7.0 серверы, ошибки пофиксены;
2. Плагином Query Monitor просмотрены все запросы и удалены плагины с ошибками ( был плагин DB optimize, который вешал систему на 7 версии и WP No External Links — обращался к несуществующей таблице);
3. Поставлены плагин перегенерации картинок  Regenerate Thumbnails;
4. Поставлены и настроены плагины оптимизации картинок: EWWW Image Optimizer, Imsanity;
5. Плагин борьбы со спамом Akismet заменен на Kama SpamBlock;
6. Плагином Autuptimize пожаты скрипты, стили и html;
7. В файле .htaccess добавлены инструкции для настройки кеширования.

Как видите, ничего сверх естественного не было сделано. Плагин WP SuperCache был раньше установлен.

Сайт Анапа по минификации стилей и скриптов был доработан руками раньше, как и ответы кеширования сервера.

Результаты замеров скорости

А вот результаты оказались интересными. Все сайты находятся на разных аккаунтах, но у одного хостера — Sprinthost.ru. И он одинаково плохо отдает страницы, о чем постоянно ругается PageSpeed.

Какие выводы из этого можно сделать:

1. Низкие результаты для мобильных устройство зависят еще и от темы, так что Геленджик со старой темой и Отдых в Анапе набрали так мало баллов именно по этому.
2. Гараж проиграл по наворотам, которые съедают время — слайдер, сложная разметка с кучей логики (тема очень навороченная), просмотры, виджеты.
3. Очень сильно зависит от оптимизации темы WordPress что и как будет отдаваться контент.
4. Особой разницы между MODX и WordPress нет совершенно.
5. Вполне реально сделать быстрый сайт и на WordPress, главное не увлекаться виджетами, плагинами и сложностями.

Так что чисто для себя я закрыл вопрос в «медленности движка WordPress».

Кроме того, прекрасно видно, что и споры MODX Evo vs Revo тоже глупы — они абсолютно одинаково отдают контент. И без реальной оптимизации руками такие сайты будут проигрывать WordPress, где оптимизацию можно отдать на откуп готовым плагинам.

Не секрет, что официальное сообщество MODX практически полностью отказалась от старой ветки MODX Evolution (1.0). Некоторые энтузиасты продолжают развивать и решили взять новое имя: Evolution CMS.

Логично, произошел ребрендинг, сообщество решило отказаться от старого наследия, переработать админку и еще куча всего.

Evolution CMS

Под «капотом» движка все та же старый добрый MODX Evolution. Но некоторые расширения были признаны устаревшими. Так списали со счетов модуль EvoGallery как написанную с ошибками и дырами в безопасности, убрали плагины MultiPhotos и другие.

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

И из всех сайтов, которые у меня есть, остался только один сайт, который работал на MODX Evolution.

Я довольно редко обновлял его, с 2014 года статей почти не публиковал. Сайт сезонный (под летние отпуска), так что внимание в году он требовал не много.

Но этим летом опять взломали и нужно было что-то делать. Про борьбу с вирусами я писал здесь.

Попытка обновиться

В общем, после лечения заразы, я обновился на новую тогда версию 1.3.0. И у меня все отвалилось!

Перестали выводиться новости, а что выводились, то выводились по странным датам. Картинки часть пропали. Но самое страшное — в админке стало очень сложно работать.

Нет, к дизайн новой админки я приноровился быстро, хотя она стала теперь странной — ожидаешь одно, а получаешь другое. Попытки скопировать фишки из MODX Revolution выглядят именно неуклюже. Думаю, что если движок дальше будет развиваться, то эти детские болезни быстро исправят.

Я же говорю о схлопывании и пропаже визуального редактора в первую очередь.

В общем, повозившись пару часов, я плюнул и вернул из бекапа хостера старую добрую версию 1.2.9. И все заработало.

Попытка номер два

Все равно оставалась неудовлетворенность. Выходят новые версии, а проблемы не решаются. Буквально в пятницу неделю назад, под выход новой версии 1.4RC я снова решил обновится.

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

Ditto в топку!

В ходе дискуссии выяснилось, что некоторые разработчики несколько раз релизили код, который не совместим со старыми наработками. И поломали сортировку по датам публикации.

Теперь нужно делать сортировку по датам создания. Поскольку по датам публикации в любой момент может опять сломаться.

Вместо Ditto нужно использовать сниппеты DocLister.

Документация по DocLister

1. Документация на официальном сайте
2. Документация на сайте https://modx-gu.ru/

Увы, документация очень фрагментарная, очень многие моменты описаны плохо. Вот для уточнения некоторых тонких моментов я опишу подробнее подводные камни.

Практическая работа

Я строил сайт на примерно таких вызовах

[[Ditto? 
    &tpl=`@FILE:assets/templates/rest/chanks/ditto-card.chank.tpl.html` 
    &summarize=`7` 
    &depth=`3` 
    &hideFolders=`1` 
    &paginate=`1`  
    &dateSource = `pub_date` 
    &sortBy=`pub_date` 
    &sortDir=`ASC`
    &dateFormat=`%d.%m.%y в %H:%M` 
]]
    <div class="pagination">[+previous+] [+pages+] [+next+]</div>

А для вывода использовался чанк что-то наподобие того



<div style="border-bottom: 1px dotted #CCC;">
<p class="title"><a href="[+url+]" title="[+longtitle+]">[+longtitle+]</a></p>
<a href="[+url+]" title="[+longtitle+]">
	<img src="[[phpthumb? &input=`[+image-post+]` &options=`w_120,h=90,zc=1`]]" class="imgl" alt="[[+pagetitle]]" />
	</a>
<div>
<p style="text-indent: 0;">
  <strong>Адрес:</strong> [+tv-adres+]</br>
  <strong>Телефон:</strong> [+tv-tel+]</br>
  <strong>Сайт:</strong> <a href="[+tv-site+]" rel="nonidex,nofollow" title="Сайт [+longtitle+]">[+tv-site+]</a>
</p>
 
<p class="readmore-list">
    <a href="[+url+]" title="[+longtitle+]">Подробнее...</a></p></div>
<br class="clear" />
</div>

То есть я прошу сделать вывод ленты новостей по 7 блоков по шаблону и отсортировать их по убыванию по дате публикации. Заодно дату формирую по заданному шаблону.

Сайт рушился из-за вызовы форматирования даты aDate, который наглухо вешал все.

Как видите, ничего сложного нет.

Однако, переписать просто вызов сниппета на DocLister невозможно. И другие параметры, и другая идеология.

Дополнительные

В вызове сниппета нужно обязательно указывать дополнительные поля, которые используются при выводе. Иначе их сниппет не подтягивает и не выводит.

Чтобы не мучиться с префиксами полей, нужно сделать убрать его. Примерно так



&tvPrefix=``

&tvList=`image-post`

image-post — это имя моего дополнительного поля, правьте под себя и записывайте все через запятую.

Разница между шаблоном в чанке и во встроенном в вызов

Так же есть разница как вызвать шаблон: через чанк или встроить через @CODE:

В первом случае отработают вызовы сниппетов в чанке, а потом его использует DocLister как шаблон. Во втором случае сразу используется как шаблон, а вызов сниппета не происходит.

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

Пагинация в DocLister

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

Мои вызовы DocLister

[[DocLister?
	&id=`list`
	&display=`7`
	&depth=`2` 
	&hideFolders=`1` 
	&tvPrefix=``
	&tvList=`image-post`
	&orderBy=`createdon DESC`
	&dateFormat=`%d.%m.%Y`
	&tpl=`ditto-news.chank.tpl`
	&paginate=`pages`
	&pageAdjacents=`2`
	&TplNextP=`@CODE:<a href="[+link+]">></a>` 
	&TplPrevP=`@CODE:<a href="[+link+]"><</a>` 
	&TplPage=`@CODE: <a href="[+link+]">[+num+]</a>` 
	&TplCurrentPage=`@CODE: <span class="ditto_currentpage" style="background: #FFDF80;">[+num+]</span>` 
	&TplWrapPaginate=`@CODE: <div class="pagination">[+wrap+]</div>`
]]
 
[+list.pages+]

Пример рабочий, так что можно его брать и изучать. Выводится 7 блоков, глубина до 2 уровней от текущей страницы, используется tv-поле image-post, папки скрываются, сортируются по дате создания по уменьшению, используется чанк, пагинация вперед-назад и

цифры.



<div class="articlePost">
    <p class="title"><a href="[+url+]" title="[+pagetitle+]">[+pagetitle+]</a></p>
    <a href="[+url+]" title="[+pagetitle+]">
      <img class="imgl" src="[[phpthumb? &input=`[+image-post+]` &options=`w=100,h=75,zc=1`]]" width="100"  height="75" alt="[+pagetitle+]"  title="[+pagetitle+]"/>
    </a>
    <p style="text-indent:0;">Дата: <strong>[[MyDate? &date=`[+date+]`]]</strong></p>
    <p>[+introtext+]</p>
    <div class="clear"></div>
</div><br />

Тут тоже все похоже. Только теперь пути формируются в плейсхолдере [+url+].

aDate

Камень преткновения был в этом сниппете. Отключал — работало. Включал — ошибка.

В конце концов мне это надоело и я переписал сниппет почти слово-в-слово. Но удалил лишнее и с 10-ой попытки заработало.

Но мне стало интересно и я отрыл сниппет aDate на github у другого человека, который взял идею Дмитрия, доделал её и создал целый комбайн! Вот здесь можно скачать этот полезный сниппет.

Опции:

&date — обязательный параметр, дата — любой плейсхолдер: [+createdon+], [+pub_date+] и так далее

&alterDate — дата как и date, только будет использоваться если &date содержит пустое значение.

&tpl — чанк или @CODE; По умолчанию — '@CODE:[+day+].[+month+].[+year+] [+hour+].[+minute+].[+second+]'

Доступны плейсхолдеры: [+day+] [+month+] [+year+] [+hour+] [+minute+] [+second+]

&lang — язык, для форматирования названий месяцев года. Доступно: ru, en, ua. По умолчанию: ru.

&Uppercase — формат вывода месяцев года:

1. 0 — по умолчанию, выводит все в нижнем регистре
2. 1 — выводит с первой буквой в верхнем регистре
3. 2 — все буквы в верхнем регистре

&monthFormat — формат месяца:

• 1 — числовое значение месяца (01 — 12)
• 2 — название месяца (январь)
• 3 — короткое название месяца (янв)

Заключение

В Evolution CMS произошло очень много изменений. Пляски с бубном над моим сайтом не прошли даром — я обновился, кое-что узнал нового.

С другой стороны, мне грустно видеть, что система ушла в пике и непонятно, сможет ли из него выйти. Точно такие же признаки были у SantaFox CMS, с которой я пришел в мир MODX.

Так что я думаю и прикидываю что мне делать с сайтом:

1. доделать его и ждать когда со следующим обновлением опять что-то отвалится
2. перенести его на MODX Revolution
3. вообще перенести его на движок WordPress

Каждое решение имеет свои плюсы и минусы. Если у кого есть интересные мысли — милости прошу в комментарии, обязательно обсудим.

В конце года WordPress вышел новый релиз 5.0 с новым редактором Gutenberg. И сообщество во всем мире разделилось на два лагеря: кто принял этот редактор и тех, кому этот редактор не зашел. Я тоже обновился и хочу поделиться своими ощущениями.

Идея редактора в том, что вы должны думать не портянкой текста, а блоками. То есть статья делится на блоки: блок заголовок, блок текста с абзацами, блок картинка и так далее.

Изначально в редакторе не так уж много блоков, но уже появились плагины, цель которых добавить новые блоки. И по идеи этот редактор сможет заменить кучу плагинов, которые помогают оформлению теста поста или страницы. Заодно будет очень хороший штатный  конкурент конструкторам страниц типа Elementor. И станет гораздо легче делать сложное оформление постов со слайдерами или сложными галереями, колонки и так далее. А учитывая, что в WordPress есть произвольные поля, которые все больше используются в темах как больших конструкторах контента в таких СMS как Drupal, Joomla! и MODX, то в скором будущем возможно очень не хилое развитие шаблонов и сайтов.

Но все это в теории. А как все это на практике обстоит здесь и сейчас?

Gutenberg в WordPress 5.02

У меня несколько сайтов на wordpress и я их уже обновил сначала до версии 5.0.

На одном из своих сайтов, когда я попробовал отредактировать последнюю статью чисто посмотреть на новый редактор, начались глюки с библиотекой медиафалов — тупо не возможно вставить или отредактировать фотографию в статье. Ну не контачит новый редактор и библиотека: не видит медиафайлы и все!

На том сайте я просто поставил плагин с классическим редактором и успокоился.

А вот на этом сайте я последовательно обновил сайт сначала на 5.0, потом 5.01 и затем до последней версии 5.02.

Наученный горьким опытом, я решил не править старые, а создать новую статью. Как раз предыдущая статья о итогах 2018 года была именно как проба пера именно редактора Gutenberg в боевых условиях.

По сравнению с первым опытом, редактор стал более адекватным и я сразу накропал статью с оформлением. Вот только мой любимый плагин Art Decoration в нем не завелся и врезки сделать не получалось. Но фотографии вставлялись и их можно было заменить/отредактировать. В общем статья получилась.

Плагин Yoast SEO так же нормально отрабатывал в конце статьи. Его как раз обновили перед концом года, адаптировав под новый редактор.

А вот боковая панель, где я задаю фотографию статьи, метки, категории и так далее существенно изменили свой дизайн. Он стал непривычным, но понятным.

Но! Что-то пошло не так и стала постоянно выскакивать надпись «Не удалось сохранить черновик». Это слегка меня напрягло (и не напрасно, как оказалось!).

Статья вроде сохранялась, но опубликовать её я так и не смог. Походу это вылезла еще одна из ошибок системы. А возможно и простое наложение плагинов оптимизации wordpress, которые вмешались в системные настройки и что-то поломали.

В результате текст статьи я потерял и пришлось скомкано писать её заново в классическом редакторе.

Проблемы с Gutenberg

Так что получается, что пока редактор очень сырой и такие глюки будут вылазить еще не раз и не два.

С другой стороны стало понятно и возмущение другой части пользователей этой CMS: под этот редактор за 2 года начали вычищать всю эко-систему из тем и плагинов. И все равно ломается обратная совместимость. Даже популярный плагин YARPPудалили из официального репозитария потому что его не тестировали с новым редактором и автор плагина не ответил на письма разработчиков. Под нож так же попали и другие плагины.

Именно такие действия и вызвали гнев большой части общества.

Сейчас на новом сайте (на самом деле старом — пришлось заново ставить все с нуля из-за вирусов) пришлось использовать аналог Related Posts для замены YARPP. И редактор поставил классический, хорошо хоть разработчики оставили путь отступления для старых сайтов.

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

Как говорится «будем посмотреть» (с) Гоблин — Пучков.