Комментарии 46
широко используемые CMS обычно тщательно тестируются
Когда, казалось бы, ну сколько ещё можно найти дыр в WordPress…
https://wordpress.org/news/2017/09/wordpress-4-8-2-security-and-maintenance-release/
3 дня назад вышел апдейт с фиксом 9-ти критических уязвимостей. Да, открытые CMS тестируются, но это не значит, что в них доселе нет глупейших уязвимостей, и это не значит, что я доверяю опыту тех программистов, которые писали WordPress Core.
Для более-менее серьёзной конторы надо очень подсуетиться, чтобы сделать из open-source CMS безопасную систему. Либо написать своё решение, если позволяет опыт сотрудников (писать безопасный, поддерживаемый, etc., etc. код) и поставленные процессы.
В моей компании пошли по первому пути. Я этому WordPress'у (как InfoSec Engineer) урезал почти всё, что можно, и не жалею.
Переписал проект с Wordpress на Yii2 — как минимум генерация страницы ускорилась в 10 раз.
Конечно, при этом теряется модульность и возможность быстро добавить нужный плагин в систему, но когда уже точно сформирован функционал, и знаешь, чего от него нужно — такой перевод сказывается очень позитивно.
У нас аналогичная ситуация. Только проект переписали с Drupal 6 на Laravel 5.2. Кеширование реализовали на фронтенде (nginx) + SSI для вывода динамических блоков.
Мы очень довольны.
Если у кого-нибудь есть опыт работы с такими штуками, расскажите пожалуйста. А то в гугле по запросу «headless CMS» гораздо больше странных статей вроде этой, а реальных продуктов с нормальной документацией — не густо.
Пользуясь случаем, хотелось бы узнать, кто какие headless-CMS использует на «бэкенде»? Интересуют свободные standalone решения.
Мы же у себя, на данный момент, остановились на Wagtail в качестве «бэкенда». А в качестве «фронтенда» используем обычное Node.js приложение для пред-генерации страниц для React'а (тот самый server side rendering).
Wagtail — это CMS, построенная на базе Django.
По первым впечатлениям: Wagtail больше заточена для использования её как «классической» CMS, однако имеет встроенный REST API (использует Django REST Framework), позволяющий забирать нужные сущности. Хотя, этот API достаточно негибкий: чтобы получить нужный набор полей сущностей, да ещё и с нужной глубиной вложенности связанных объектов, приходится достаточно много писать кода, обильно снабжая его копипастой из ядра Wagtail.
Интерфейс управления контентом и его редактирования в Wagtail достаточно удобный «из коробки», есть интересная система виджетов. Однако, опять же, для сложных кастомных виджетов приходится писать изрядное количество кода, да и UX начинает страдать.
Мы ещё не достаточно глубоко завязались на этом решении, поэтому было бы классно узнать о хороших альтернативах.
Мне кажется, если Wagtail из коробки не подходит, и с ним приходится сражаться, то лучше вообще его не использовать, а работать на голом django/drf.
У нас проект не настолько «контенто-центричен», чтобы писать CMS с нуля на джанге (или чём либо другом).
Фактически, получается так называемое изоморфное приложение. Здесь можно почитать подробнее: Изоморфные приложения. Взгляд в будущее с React.
Такие вещи нужны, в первую очередь, тогда, когда вам нужно дать пользователю какой-то сложный интерфейс на странице, а не просто статичный кусок текста статьи, но, при этом, вы хотите, чтобы и поисковики вас хорошо индексировали, и у обычного пользователя статья загрузилась быстро, как будь то это обычный статичный блог-пост, а не SPA, которое может грузиться по несколько секунд.
Вообще, клон твиттера что на рельсах, шо на джанге пишется за вечер. А вот бложик формата жж с тегами поисками френдами — уже требует интересных развлечений.
А вот с cms — мне интересно как логически решать вложенность страниц, как это делается легким движением руки в вордпрессе, например?
В чём проблема со вложенностью страниц? Дерево построить вообще не проблема (как дерево папок в файловом менеджере, но каждая «папка» при этом может быть и файлом), из этого же дерева автоматически строится главное меню. Именно так и реализовано во многих CMS. Чуть сложнее, если нужно не дерево, а граф.
How I built a CMS, and why you shouldn’t
In the past 15 years, I’ve written five Content Management Systems and built a leading CMS software company. Now let me tell you why you shouldn’t write your own CMS.
Персонаж, разрабатывающий ЦМСки и создавший компанию по разработке ЦМСок сейчас объяснит вам, почему вам не стоит писать свою. Лучше, конечно же, купить (у него).
А именно: Чего вы хотите получить в результате решения. Ну или как ваше решение может повлиять на результат.
Так вот исходя из объекта топика, можно определить задачи (скажем так очевидные, не очевидные каждый пуст ставит для себя сам):
1. Сделать типичный сайт стороннему клиенту
2. Сделать нетипичный сайт стороннему клиенту
3. Сделать один типичный сайт. Например вам в компании поручили сделать сайт компании.
Так что выбрать? Готовое или самописаное? Я просто хочу сказать, что постулат в заголовке ошибочен, т.к. предполагает выбрать одну стратегию и всё. Хотя для каждой стратегии оптимален свой вариант.
P.S. Я как то коллеге сказал — зачем изобретать велосипед. На что он дал мне толстый журнал — новинки велосипедов за такой то год. Коллега увлекался велоспортом.
P.S.S. Когда появился google — уже существовали серьёзные поисковики. Когда появился facebook — уже существовали сайты для общения.
P.S.S.S А теперь всё вышесказанное выкинте из головы (ну или просто положите в архив памяти) как очередной совет типа топика. Есть одно правило прежде чем что то делать подумайте зачем и как. Ну или просто делайте.
Если не ошибаюсь, изначальный автор статьи написал «Kentico CMS». Я с ней сталкивался. Давно. Ничего интересного и революционного в ней на тот момент (2012 г.) не было. Просто платная (очень платная) CMS для внедрения в бизнес-сегменте. Документация была запутанной. Чем-то все это напоминало «Битрикс» — много маркетинга и довольно средний продукт в красивой рекламной коробке. Это мое личное мнение, разумеется. Возможно, я просто не сумел оценить ее или с тех пор что-то стало сильно лучше. Своих денег, на мой взгляд, она не стоила.
Я таким конторам не очень доверяю.
Создав продукт который лучше других решает задачи определённой ЦА — получаешь конкурентное преимущество для работы с этой ЦА. Будешь делать лучше, дешевле, быстрее — при прочих равных, но не вообще, а для данной ЦА.
Универсальных ЦМС как таковых быть не может, поэтому нишевой продукт всегда будет иметь спрос, если ниша конечно выбрана хоть немного с головой.
никогда не понимал зачем использовать готовое решение, при условии сроков не на вчера, если есть наработки (почти у каждого уверен они есть) простой, к примеру, админки, а на выходе: визитка, каталог, или интернет магазин.
Вот ты сделал чтото, например, на вордпрессе, или, прости Господи, на джумле, ну или на магенто… все работает, свежие патчи, десятки сторонних модулей и кучи-кучи-кучи кода под капотом в который вникать и разбираться не то чтобы не хочется, сроки в рамках проекта не позволяют…
… что с этими готовыми решениями будет? Кто будет следить за свежими апдейтами сторонних компонентов системы?
Были случаи, когда давний сайт на одной из известных ЦМС не обновлялся длительное время, в результате, из-за уязвимости в одном из модулей начались бесконечные емейл-рассылки с ВПС и заражение других сайтов… секс был еще тот все это вычистить.
Брать чужую цмс, пусть даже бесплатную, вижу в случаях:
— ограниченные сроки
— ограничен бюджет
— лень возится, проще взять готовое, тик-шмык и работает
— другие причины, типо, рук не хватает, ума не хватает и т.п.
У каждого свои методы работа, но как по мне, легче сделать свое простое с необходимым минимальным набором функций, чем использовать комбайн и следить за апдейтами и его компонентами.
А ещё у неё нет головы.
Я написал свою healess-CMS, и хочу стать вендором))).
А так да, я согласен в классическом виде CMS с ограничениями в разработку, давным-давно никому не нужны. Собственно эти классические CMS меня и подтолкнули написать такую CMS где нет ограничений для построения шаблонов.
Как я написал свою CMS, и почему не рекомендую вам делать то же самое