Комментарии 32

Интересно и познавательно, жаль что мало конкретики… Про скорость загрузки сайта хотелось бы знать не только быстро/медленно, а увидеть количественные характеристики (время формирования страницы в секундах, количество запросов к БД для формирования страницы), повторный вызов данной страницы. Не совсем понятен вопрос Кеширования, есть ли он в движке или нужно реализовывать это самому через сторонние модули (Nginx, Apache, PageSpeed etc...). Хотелось бы немного больше про API, не просто наличие, а какие способы аутентификации поддерживает...

Скорость на 101% зависит от настроек и модулей, не получится сказать наперед. Если есть сложная логика и большое число полей в материалах + сложные выводы через views то одно, а лента заголовков и фильтр по тегу — совсем другое.


Кэш из коробки только для анонимов + есть сжатие и агрегирование js и css.

Как-то ч поставил drupal 8.8
Сделал несколько страниц, включил пару стандартных расширений в настройках.
Потом отключил.
Что делать с 500-тыми ошибками, которые начали появлятся в админке с ооочень пространными php бэктрейсами так и не понял.

Что за ошибки и в какой момент появлялись? Может вы делали что то не так? Какие расширения включили? Вопросов больше чем ответов. И еще, в статье я пишу про Drupal 9, а не 8.8.

Я бы добавил про поля (fields) отдельный раздел, т.к. это одна из самых сильных частей друпала. То что в любой тип материала можно добавить почти что угодно, доступны мультизначения (даже мультиюзер значения, если брать модуль flag как поле) и дальше через views можно фильтровать/сортировать по этим fields как угодно. Без этого считаю что не совсем полный обзор.


Ну и справедливости ради:
1) в вордпрессе можно добавлять поля, не на каждой чих нужен модуль)
2) в друпале многие модули тоже пишут не те же люди, что и ядро (и очень часто я попадаю на косяки в плане стабильности и логичности кода)
3) ну а про одностраничники вообще жесть написана — прям вспомнил как на заре писал в notepad++ код всей страницы. Но нет, сам под одностраничниками уже все понимают реактивные (раект/вью/ангуляр) приложения, которое и в шаблоны умеет (и как компоненты, или через nunjuks) и данные из api вытащить может и вообще много всего ещё.


Ну и в свете этого считаю что очень зря ещё не написано что друпал 9 из коробки умеет с такими реактивными приложухами дружить и быть для них сервером данных, а не только как генератор HTML когда выступать. Тут можно гуглить headless Drupal, например.

Fields в Drupal уже даааавно как обыденность.
На мой взгляд, киллер фича Drupal — это деплой с конфигурациями.
Кто с D7 перешёл на D8, по возвращению испытывают колосальную боль без них и ООП )))

Согласен. Но рассказать про типы материалов и вьюз без филдов это было странно же. Не?)

Про поля в контексте этой статьи написано достаточно. Повторюсь — тема уже настолько изъезжена…
Сам движок требует обновления раз в 2-3 недели (ну это в среднем и у других движков так).
Но у Друпала какая-то очень мудрёная процедура обновления, когда нужно скачивать файлы новой версии руками, удалять на хостинге папки со старыми версиями, распаковывать новые версии, предварительно ещё что-то отключать на сайте, потом запускать в админке скрипт апдейта, потом включать то, что отключал перед апдейтом.
Да, это можно делать скриптами (мало кто умеет), но даже с ними, насколько я понимаю, процедура больно сложная, вот инструкция по обновлению из мануала.
В отличие от других движков, где обновление делается нажатием кнопки «обновить» в админке. Т.е. с точки зрения обновлений — движок очень «не для всех».
Я примерно из-за этого с друпала и ушёл. Да, есть Drush (консоль), но это дико неудобно.
Хотя система хорошая, я на ней много чего забавного делал, от СЭД и фотобанка до игры.
Но у Друпала какая-то очень мудрёная процедура обновления, когда нужно скачивать файлы новой версии руками, удалять на хостинге папки со старыми версиями, распаковывать новые версии, предварительно ещё что-то отключать на сайте, потом запускать в админке скрипт апдейта, потом включать то, что отключал перед апдейтом.

Согласен, по сравнению с тем же самым WP процесс обновления ядра сложнее. Хотя если все таки разобраться с Drush, то ситуация с обновлением сразу становиться проще.
Это да, но всё-таки хотелось бы сосредоточиться на разработке, а не освоении достаточно нишевого инструмента.
Так, как здесь уже написали, composer — это стандарт в php разработке. А drush тебе кучу времени сэкономит и в рутинных задачах и в написании нового кода, как поймёшь это — сам выучить захочешь.

Кхм. Вот прям ща накатываю апдейт:
cp -R /folder/from /folder/gde/tam/vash/www


Команда копирования сама обновляет только те файлы, которые надо обновить (upd: точнее не надо ничего перед этим удалять, так будет вернее)


Драш удобней, но, конечно, на проде мне его никто не даст поставить, да и уж тем более проду доступ в сеть не видать как своих ушей)


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


В общем не повод уходить с друпала, вот честно. Есть ещё тысяча причин почему он местами кривой, но апдейт в последних рядах среди прочих )))

Я ж и говорю, что решение сильно не для всех. Например какой-нибудь простой интернет-магазин можно сделать на WP и потом любая девочка сможет из админки нажать кнопочки бэкапа и обновления.
А вот с Друпалом эта девочка будет вынуждена постоянно обращаться к знающему мальчику. А мальчику это надоело, а значит скорей всего он поставит девочке WP, чтобы его реже беспокоили. Хотя мальчик прекрасно понимает, что на Друпале можно поднять гораздо более крутой магазин, хоть и придется самому разрабатывать плагины для СДЭКа, приема платежей и т.д. А под WP оно уже есть, пусть и платное, но всяко дешевле стоимости работы этого мальчика.
Так что Друпал больше всё-таки для серьезных проектов, где нет сложностей запилить свой плагин, обновлять движок через консоль и всё такое.

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


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


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

Если это магазин, где есть только девочка и она торгует только своими цветочками, то, возможно, и то не факт вы правы. Ежели нет — то это чепуха
обновляться надо только c composer. Выучите наконец-таки пару команд.

А чего мудрёного? Composer давно стандарт в php мире.


Drush использовался для скачивания во времена Drupal7 (примерно 9 лет назад)

Ничего мудрёного, просто это нужно уметь и разбираться, иметь нужные доступы и не бояться. Т.е. нужно иметь доступы к хостингу, знать и уметь Drush и/или прочий Composer.
А значит, например, например фрилансер, который сайты делает, кучу раз подумает стоит ли на этом всём делать сайт для заказчика, ведь потом ещё заказчику нужно будет всю эту кухню объяснять. Ну разве что фрилансер продолжит тянуть с заказчика ежемесячно денежку за обслуживание всего этого хозяйства.

В статье автор считает эту CMS одной из лучших и рекомендует её своим клиентам.
Но эти клиенты потом не смогут самостоятельно обновить движок.
Клиент, как правило, если у него нет собственного программиста и не должен обновлять Drupal, т.к. сайт этого клиента — это не какой-нибудь микробложик на WP.
Drupal для относительно больших проектов, где нужна высокая степень технологичности и предсказуемости.
Друпал 8 и 9 настолько хороши, что сообщество решило продлить поддержку Друпал 7, т.к. ещё очень большое кол-во сайтов не хотят переходить с Друпал 7(т.к. очень дорого).
Они не не хотят.
Те кто не переходит с D7 значит D8 им для их проекта не нужен.
Ещё раз: Drupal 8/9 это система для более сложных проектов. Делать на ней мелкие бложики как раньше на D7 — это тоже самое, что пушкой по воробьям. А вот относительно крупные проекты, например СМИ, ЛК, Коммерция — где нужна предсказуемость и расширяемость — самое оно.
почему нельзя бложики на 8/9? Конечно под каждую задачу — свой инструмент, но друпал для блогов вполне подходит.
Не согласен с тем, что Друпал относят к классу CMS. Это CMF. Отсюда некорректно сравнивать Другал с Вордпрессом или Джумла, которые являются CMS с расширенными возможностями.
А вас не смущает тот факт, что разработчики свой продукт называют именно CMS?
image
Я думаю, что это вопрос формулировки, но с точки зрения разработки (более или менее зрелой, а не просто поставить тему оформления), нужно уметь много всего, о чём не задумываются «вебмастера» на WP, joomla или, прости господи, на битриксе.
А Symfony под капотом позволяет сделать всё, что должен уметь фреймворк. Я встречал проекты, которые сделаны на друпал, но люди не знали инструментарий друпала, но в, видимо, совершенстве владели Simfony. Результат был достигнут, но немного не тем путём ))

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