О выборе CMS для сайтовых дел, кратенький обзор Processwire

На днях было появилась нужда — создать сайт, новостного типа, и недолго думая приступил к поиску того самого чудо движка (CMS, пардон — за терминологию из 90х) который бы осилил задачу с относительной лёгкостью, но и — как понимаете — был бы достаточно поддерживаем (важно!), стабилен и гибок для других возможных задач (заказов) из будущего.

К авангардной тройке (WP, Joomla, Drupal) не приглянулся по N-ным причинам, но, щас не об этом.

В общем, перебрал всевозможные критерии (внушительный список хотелок:)) — гугл + ИИ в помощь смекалке и, перематывая к результату — остановился на чудо инструменте Processwire (далее PW).

26962e3d7c77b64594aeefdb18e93faa.jpeg

Признаться, был удивлён возрастом сего инструмента — почти такой же бородач как и пресловутый WP (!), стабилен, имеет нишу, но популярностью вроде как особо не обзавёлся. Хотя, по сегодня поддерживается, обрастает версиями и т.д. Особо порадовало комьюнити — реально отзывчивое и гостеприимное, из личного опыта)).

Сейчас, уже перештудировав многие доки и почти закончив свой намеченный сайт, отрезюмирую по данному CMS/CMF (сайтовый движок):

Что делает его привлекательным средь многих других подобных?

Гибкость — в построении полей и структуры страниц — которая зиждется на мощном & довольно обширном API, и относительная лёгкость в применении встроенных возможностей разработчиком (говорят — не в пример друпал, …откашлялся).

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

5d2431658b2004c5bd4c72db774c018b.jpg

Лично, снимаю шляпу перед разработчиками/мейнтейнерами Processwire инструмента, конкретнее за ту огромную работу по базе API с соответствующей документацией, которая охватывает (наверняка) все возможные операции для вывода и манипуляций информацией в/с бек-энд хранилища, что в купе с темплейтами (файлы шаблонов, для вывода в браузер) и даёт супер-гибкость.

И этот действительно богатый набор встроенного API по сути и выделяет его из массы других движков на сегодня и даёт вход в категорию CMF (content management framework), вроде как среднее звено между традиционным сайтовым движком и полноценным php web-фреймворком.

Таким образом, «сайты любой сложности» — это не преувеличение, при этом разработчик сохраняет полный контроль над процессом + может создавать свои «расширения» (если это действительно разраб, не ноу-кодер из среды современности :)).

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

Касательно уникальности & гибкости дизайна — тут опять свобода (а это часто предполагает ответственность), задействуй css библиотечки на вкус и на тебе авторский сайт (!)

Кстати — «о птичках»

Сам — методом вопросов критериев и перебора — пока остановился на «pure.css», но, для любителей не особо погружаться в css-премудрости, я бы предложил «pico.css» (для чистой html семантики, без «спагетти» тэгов с вереницей классов…) — как хорошую основу для авторского старта.

0cabc58c271ac9d1e44b0123e4f07123.jpg

Возвращаясь к нашему CMS/CMF

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

Три кита архитектуры PW сайта

Поле (field) — богатый набор типов (помимо простых, вроде: text, number, boolean …, есть: image, page-select для связи страниц, включая мульти-выбор с разновидностями вида полей).
Страница (page)- собственно, сама страничка (вроде «О нас», «Контакты» и пр.), сотканная из набора полей выше, в нужной хронологии.
Шаблон (template) — оформленное (структурированниое) представление/отображение конечного набора информации. Можно писать/использовать разные темплейты для разных web-страниц, и — вуаля — на тебе уникальность!

Другой примечательной фишкой платформы, я бы упомянул: Не нужно заморачиваться с низ-лежащей базой данных (СУБД — mariadb): какие поля не создавай в админке, сообразно таблицы и типы формируются в базе, и далее манипулируются через ту же админ-панель.
Processwire — полнофункциональная CMS, то бишь — «content management system» и относится к контенту (упрощ. — информация) как к основополагающему компоненту web-документа. Создаём гибкие контент ячейки/блоки и управляем их выводом в клиентский браузер.

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

Ещё PW плюшки

Возможности настраивать картинки «на лету», обрезать, менять размер, поворачивать, оптимизировать и т.п. — в админ панели.

Безопасность, производительность, кэширование страниц и прочий востребованный функционал — это всё про PW.

Итак! На этом этапе — если таки читатель дошёл до сих, да и не заскучал (!) — было бы хорошо скачать, да и распаковать архив с текущей версией PW для наглядности и экономии воображалки на период прочтения. Едем в сторону конкретики!

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

Нутро

Сайт пользователя находится в директории site (или site-*) в установленном на хосте processwire движком. Далее, в папке templates (что внутри site) — все основные темплейт-файлы для вывода блоков инфы в браузер.

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

За пределами templates (директории) — рядовому сайтоделу — чаще всего, делать нечего, разве что заглядывать в конфигурационный файл (config.php) при надобности.

Последовательность действий в админке (backend):

  1. Создаём поля, настраиваем.

  2. Создаём шаблон/шаблоны (template, хотя тут я бы предпочёл другое название дабы избежать путаницы с *.PHP темплейт файлами, может - blueprint), компонуя в него поля выше, и — напоследок

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

Сей обзор движка не включает создание своих модулей/расширений для более изящной кастомизации инструмента, но — как и требуется — есть документация, она адекватна и с примерами. Интересно, что многие хорошие и актуальные по теме PW сайтоделья туториалы в сети (англ.яз) датируются 2016–2017 гг (!)Насколько могу сказать, в мире nodejs фреймворков всё меняется много динамичнее, и документация соответственно устаревает.

Обобщая

Сам весьма рад знакомству с Processwire и намерен использовать его потенциал для сайтов более серьёзного разлива (скажем, новостные и пр. где всё таки нужна СУБД, как защищённое хранилище возможно большого объёма инфы) и где есть смысл в использовании РСУБД (реляционный тип).

Возвращаясь на миг к наиболее популятным мэтрам и личных доводах «почему НЕ …» — помимо плагиновой системы от третьих лиц, и как это может минусом отразиться в долгосрочной перспективе, наслышан/начитан много о атаках и взломах сайтов на наиболее используемых опенсорс платформах, мозговитыми, но неугомонными недоброжелателями.
По мне, модульная система софта (современный подход) — это хорошо, но все добротные «зап.части» и «примочки» движка пусть будут либо от самого «производителя», либо курироваться им, затем добавляться в реестр одобряемых и рекомендуемых — в случае позитива, дабы не запятнать экосистему.

Прочие упоминания, лирика

В плане лёгких и оптимизированных сайтов — как разраб и для своих нужд — предпочитаю больше из мира SSG (генераторы статики), конкретнее — Astro.

А в случае с не особо крупным сайтом, где таки админ-панель потребна, присмотрелся бы к Grav (ещё не приходилось пользоваться, держу в закладках на будущее). Всё таки — интуитивность в изучении и «порог входа» — вижу одним из важных критериев в выборе из множества.

Буду несправедлив, если не упомяну еще про добротный MODx: Относится к категории CMF, естественно — гибок, имеет много ресурсов, комьюнити, длинный рад плагинов… отдельный русско-язычный сайт, и так понимаю, в целом — будет чуть более популярен в сравнении с обозреваемым PW, но, действительно изучить, да и применить в мало-мальском деле мне ещё не доводилось.

Благодарности, всем добра ! :)

© Habrahabr.ru