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

Структура папок Bolt CMS

Для начала рассмотрим распакованный дистрибутив последней версии Bolt CMS. В корне проект находится следующие папка:

1. App – именно здесь находится ядро Bolt CMS и все настройки, кеш, логи и так далее;
2. Files – здесь будут лежат файлы, которые вы загрузите для страниц вашего сайта;
3. Theme – здесь находятся темы оформления сайта, которые можно поменять;
4. Vendor – системные библиотеки, которые при помощи composer загружаются, конфигурируются и необходимы для работы ядра

Если в папку vendor руками лезть не стоит, то в других папках стоит посмотреть все файлы стоит очень внимательно.

Темы я затрону в одной из будущих статей, там много интересного. Но сегодня я пропущу этот каталог. Каталог files я тоже пропущу, я подробно описал как загружать и использовать файлы в статьях в руководстве пользователя.

А вот к папке app покопаемся вдоволь.

• cache – здесь хранится кеш сайта, руками там ничего править не стоит;
• classes – вспомогательные классы Bolt CMS, стоит «поглядеть», но трогать явно не стоит без знаний;
• config  — а вот тут лежат все конфгурационные файлы ;
• database – папка с базой на sqlite3, тут нечего смотреть;
• extensions – папка с расширениями;
• resources – тут ресурся для движка, языковые файлы
• src – само ядро движка
• theme_defaults – шаблоны по умолчанию, админка
• view – вьюшки движка

Как легко догадаться, сегодня я буду ковырять настройки в папку config.

Как настраивается Bolt CMS

По умолчанию в папке app/config лежат файлы с расширением *.dist. Эти файлы с настройками по умолчанию всех аспектов работы движка. Их 6 штук. Когда при первом запуске инсталятора скрипт доходит до настроек, то все файлы копируются с теми же названиями и им присваивается расширение yml – именно отсюда и берутся настройки.

Когда первый раз запускается инсталлятор, в файле database.dist по умолчанию прописывается работа с базой SQLite3, а сама база находится в папку app/database. Очень удобно для хостинга без поддержки MySQL и резервное копирование заключается в простой архивации сайта и скачивание себе на локальную машину. Учитывая, что Bolt CMS не предназначен для сайтов с высокой посещаемости и в нем нет плагинов комментариев, то это будет хорошим решением. Но если вам нужно чуть больше производительности, то лучше настроить систему на работу с базами MySQL или даже PostgreSQL.

Файлы с расширением yml – это обычные текстовые файлы, в которых легко разберется любой человек. В них приведены комментарии (правда, на английском языке), есть примеры и по аналогии можно добиться многого от движка.

Config.yml – это основной файл конфигурации именно движка: подключение к базе, название сайта, его адрес, локализация, вывод ошибок и так далее.

Contenttypes.yml – это файл, который конфигурирует типы страниц и их поля в административной панели. Это второй по важности конфигурационный файл и именно его вы будете править чаще всего.

Menu.yml – это файл меню, с помощью которого можно определять разные меню, вложенность элементов, адрес ссылок и название пунктов. Есть и плагин, который помогает визуально редактировать этот файл, но на мой вкус легче руками самостоятельно отредактировать его в редакторе.

Permission.yml – это файл с настройками прав пользователей. Его редактирование нужно будет на последнем этапе разработки сайта.

Routing.yml – это файл с уникальными настроками роутинга. Роутинг – это связывание адреса страницы с конкртеным действием движка. То есть можно делать какие-то тонкие настройки для плагинов и модулей.

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

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

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

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

После версии Bolt CMS 1.6.12 вышла версия 2.0. И это не просто сменилась цифирка, а реально были сделаны большие изменения в системе.

Административный интерфейс

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

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

Вкладки групп полей

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

В файле настроек групп контента contenttypes.yml вы можете задать группу для каждого поля. Вот пример такого файла:

pages: 
groups: ["content", "media"]
    fields:
        title:
            type: text
            group: content
        slug:
            type: slug
            uses: title
            group: content        
        body:
            type: html
            group: content
        feature:
            type: image
            group: media
        gallery:
            type: imagelist
            group: media

А вот что вы получите на странице редактирования

Улучшенный модульный JavaScript

Разработчики системы использовали для сборки Grunt, так что теперь вместо большого и монструозного bolt.js вся функциональность разбита по маленьким модулям.

Мультизагрузка изображений

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

Новые языки

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

Юзабилити

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

Расширения Bolt CMS

Другое главная особенность Bolt CMS 2.0 — это репозитарий расширений.  Разработчики используют систему пакетов Composer для более гибкой разработки на Bolt CMS. Теперь можно легко создать и распространять пакеты. На сайте https://extensions.bolt.cm находится уже более 50 пакетов, которые могут быть применены при разработке сайта. И количество пакетов будет только увеличиваться.

Старые расширения  ветки 1.6

Если вы использовали в релизе 1.x включенные с дистрибутив расширения, то все 28 расширения были портированы на новую ветку 2.0  и доступны для установки.

Гибкая установка

Раньше было возможно только простая установка через обычное скачивание архива системы и далее через FTP заливка и настройка сайта. Пользователи хотят устанавливать Bolt CMS и через другие возможности. Поэтому система развертывания претерпела изменения

Установите болт в качестве пакета Composer

Теперь есть возможно в существующий проект включить через Composer пакет bolt/bolt2.0.

Если вы хотите, то можете воспользоваться некоторыми дополнительными скриптами, которые помогут установить в нужное место. Более подробные инструкции здесь: https://github.com/bolt/bolt-docs/blob/master/source/installation-advanced.md#installing-bolt-as-a-composer-package

Начиная новый проект с помощью Composer

Теперь можно установить Bolt CMS 2.0 при помощи командной строки и Compser. Для этого просто в командной строке наберите (поправив имя проекта):

composer create-project bolt/composer-install <MYPROJECT> —prefer-dist

и composer  сам скачает и установит последний дистрибутив Bolt CMS

Присоединение Bolt CMS к существующему проекту

Много работы было сделано, чтобы BoltCMS мог работать в качестве автономного HTTPKernelInterface, не вмешиваясь в любой глобального пространства имен или констант. Так что, если вы используете StackPHP (или аналогичный) вы можете установить болт на URL префикс так просто, как это:

$map = [
		"/another" => new AnotherApplication(),
		"/blog" => new BoltApplication(['resources'=>new BoltConfigurationComposer(__DIR__)])
	];
$app = (new StackBuilder())
    ->push('StackUrlMap', $map)
    ->resolve($app);
Stackrun($app);

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

Настройка каталогов

Для улучшения защиты сайта — это убрать из каталогов обще пользования файлы движка. Это наиболее частый запрос пользователей. Но разработчики хотят сделать Bolt CMS простым для пользователей разной квалификации, размещающих свой сайта на shared-хостингах.

Bolt CMS 2.0 поставляется с новым модулем конфигурации, что позволяет больший контроль над размещением проекта. Например, вот как вы загружаете Bolt CMS 2 на сервер, где есть только доступ в web-интерфейс в папку public, а весь код находится в папках выше:

<?php
// public/index.php
require_once "../vendor/autoload.php";
$configuration = new BoltConfigurationStandard(dirname(__DIR__));
$configuration->setPath("web", "public");
$configuration->setPath("files", "public/files");
$configuration->setPath("themebase", "public/theme");
$configuration->verify();
$app = new BoltApplication(array('resources'=>$configuration));
$app->initialize();
$app->run();

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

Качество код

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

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

Шаблон административной панели

Целью переработки шаблона панели управления было в разделении большого шаблона на маленькие блоки и воспользоваться механизмом наследования шаблонизатора Twig. Это привело к разделению 41 шаблона на 110 более мелких блоков, которые упростились и позволяют переопределить более мелкие детали системы

PSR-4 стандарт кода

Мы также воспользовались возможностью, чтобы обновить код Bolt CMS, чтобы перейти от стандарта кодирования php PSR-0 до PSR-4, которая упростила и организовала код лучше.

Переводы: капитальный ремонт

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

panel:
latest-activity:
    button:
        more: "mehr Aktivit?ten"
    by: "von"
    headline: "Letzte Aktivit?ten"
    logged-in: "angemeldet"
    logged-out: "abgemeldet"
    saved: "Gespeichert"
    unknown: "unbekannt"
user-actions:
    button:

Скоро переключения языков на каждого пользователя

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

Гибкость файловой системы

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

1. FTP
2. Sftp
3. Dropbox
4. Amazon S3
5. WebDAV

Это означает, с небольшими изменениями конфигурации вы можете выбрать, где хранить все ваши файлы на Dropbox, или в облаке Amazon S3 вместо этого.

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

Настройка загрузки для разных типов страниц

Еще одна полезная новая функция: вы можете задать различные каталоги загрузки на каждого типа страницы с помощью простой конфигурации. Например:

feature:
    type: image
    upload: uploads/features
gallery:
    type: imagelist
    upload: uploads/gallery

Другие изменения

Новая библиотека с миниатюрами

Мы решили по разным причинам, что предыдущая библиотека Timthumb не очень хорошо подходит для Bolt CMS, нам нужно что-то, что может монтировать на существующий Silex App, а также быть гораздо более гибкой для разработчиков. Так Bolt CMS 2.0 поставляется с новым пакетом bolt/thumbs, которая функционально совместима со старой системы, но предлагает следующие усовершенствования.

Пути могут быть настроены путем расширения или перезаписи $app[‘thumbnails.paths’].

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

Улучшенная гибкость типов полей

Это одно улучшение, которое предназначено, чтобы сделать жизнь проще для разработчиков расширений. Доступные типы полей (например, HTML, текст, число) теперь можно управлять с помощью класса FieldManager и все соответствуют новой FieldInterface. Это означает, что добавление нового поля доступных опций так же просто, как создание класса, который соответствует интерфейсу и добавление его менеджеру. В качестве примера, насколько просто это сейчас, смотрите в документации по адресу: https://docs.bolt.cm/v20/extensions-customfields

Совместимость с Windows

Из-за файловой системы Windows могли вызываться ошибки. Сейчас используется библиотека Pathogen для генерации пути. Это позволяет в ядре и расширениях писать более простой код.

PostgreSQL Совместимость

Были несколько серьезных ошибок, которые помешали 1.x версии Bolt CMS работает плавно на системах PostgreSQL, Bolt CMS 2.0 включает в себя исправления ошибок для этих случаев и полностью протестирован на PostgreSQL.

Новая версия Bolt CMS 2.0 вышла вместе с обновлением официального сайта.

Вот перевод новости с официального сайта.

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

Почти каждая библиотека в Bolt CMS 2 была переработана, чтобы код был чище, читабельнее. А для разработки использовался принцип «стоять на плечах гигантов». Поэтому вместо изобретения своих велосипедов были использованы и протестированы пакеты из Symfony, Silex, Swiftmailer, Doctrine и кучи других. Таким образом, проект более управляем, а разработка новых функций BoltCMS получается гораздо быстрое. Например, сама Болт имеет только 10% кода. Сравните: Bolt CMS содержит  15000 строк, и 141000 строк в WordPress. Это дает нам держать код в хорошем состоянии.

Прежде чем мы перейдем описании этой версии, есть еще одна вещь, которую я хотел бы упомянуть: Bolt CMS — это работа команды. Все больше и больше кода, и функций, и исправлений были сделаны участниками нашей команды. Этот релиз не было бы возможным без его неустанные коммитов таких людей как Gawain, Ross, Reinier, Rix, Gerhard, Peter, Tobias, Xiao, Lodewijk, Anke, Andrew, Evert, Steven, Stefan, Thaís, Corentin, Marc, Melinda, Derk, Sebastiaan и и многих других, которые делали расширения, тестировали и предлагали свои улучшения.

Если вам интересно, об особенностях в Bolt CMS 2,0, взгляните на нашу страницу особенности. Если вы работаете  с Bolt CMS 1.Х, то на этой странице подробно описаны наиболее важные изменения (на английском) по сравнению с предыдущей версией.

К Bolt CMS 2.0 была проделана дополнительно много второстепенных вещей:

• Разработан новый сайт
• Документация постоянно обновляется. Все описание расширено, в том числе новых функций, таких как написание расширений.
• Мы сделали умную шпаргалку, которая будет бесценным инструментом
• Был запущен сайт с расширениями для Bolt CMS. Есть более 60 расширений и тем на данный момент, и это число быстро растет.
• Не хватает терпения, чтобы установить Bolt CMS себе? Попробуйте его в Интернете быстро на нашем демо-сайт: Try.bolt.cm. (примечание: пока не работает)
• Наша IRC канал становится все более и более насыщенным. В течение дня (по Гринвичу) всегда есть люди, активные в канале.
• Чтобы начать работу с болтом 2.0 сам, увидеть установку страница болт в документации, в котором подробно различные способы установки болт.

Мы уверены, что вам понравится!

Пока народ отдыхает на Рождество, я между делом разбираюсь в новой версии 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$ в месяц почти на любой тематике. И уж этой суммы вам будет хватать на любой хостинг, даже на выделенный сервер.

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

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

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

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