Drupal Composer рецепты

[Pilat]

Чтобы перестать играться с Друпалом, достаточно подписаться на его список рассылки по безопасности.

[Leksat]

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

[FatalStrike]

Хотите сказать что если ты никаких ишу по безопасности не было, то это повод не беспокоиться?

[vovasik]

Последняя серьёзная уязвимость в друпал 7 вроде была возможно создать много миниатюр одного изображения и переполнить hdd и это очень давно было, даже и не знаю это не самая плохая платформа у альтернативных решений проблем как правило больше и они другого порядка

[Pilat]

https://www.drupal.org/security — список проблем. Последняя была ровно месяц назад и раз в несколько месяцев появляются новые, причём только Drupal Core, в сторонних модулях — раз в несколько дней. И я считаю что это недостаток архитектуры, а не обычное состояние web проекта.

[bkotov]

Чем этот подход принципиально отличается от использования drush? Я так понимаю, что держать весь сайт в гите не получится?

[Leksat]

В гите будут только конфиги и кастомный код. В этом вся прелесть.

[vovasik]

«И я считаю что это недостаток архитектуры, а не обычное состояние web проекта»

Это на самом деле обычное состояние веб проектов к сожалению.

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

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

[LeGront]

Приятно смотреть на то, что Drupal развивается в сторону более удобного использования.

[dimkanevidimka]

Нет необходимости хранить код контриб модулей (и само ядро!) в вашей системе контроля версий

Преподносится как преимущество №1. Но… в чём проблема держать ядро и контриб модули в своём репозитории?
Места на терабайтном винте мало?
Или может git clone c локального gitlab'a отработает медленнее чем git clone + composer install/update?

Не воспринимайте как критику, это просто вопрос…

[LeGront]

Не воспринимайте как критику, это просто вопрос…

Представим, что у вас есть сборка проекта под свои нужды, если она полностью лежит в git, то модули и ядро устаревают. Приходится или при выходе нового модуля сразу заменять его в git'e или оставить неактуальные версии и после git clone запускать drush up.

Оба варианта, по моему опыту, хуже работы через composer.

[dimkanevidimka]

то модули и ядро устаревают

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

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

Наверняка после вышесказанного Вы захотите напомнить мне про composer.lock и про то что там зафиксированы версии… но, и в моём гите они тоже зафиксированы. Причём прям сами файлы.