Комментарии 13
Чтобы перестать играться с Друпалом, достаточно подписаться на его список рассылки по безопасности.
Я конечно не специалист по безопасности, но думаю что проблемы с безопасностью есть в любом софте. И если Drupal комьюнити предпринимает какие-то меры, например делает рассылки про найденые уязвимости, то это только плюс.
Хотите сказать что если ты никаких ишу по безопасности не было, то это повод не беспокоиться?
Последняя серьёзная уязвимость в друпал 7 вроде была возможно создать много миниатюр одного изображения и переполнить hdd и это очень давно было, даже и не знаю это не самая плохая платформа у альтернативных решений проблем как правило больше и они другого порядка
Чем этот подход принципиально отличается от использования drush? Я так понимаю, что держать весь сайт в гите не получится?
«И я считаю что это недостаток архитектуры, а не обычное состояние web проекта»
Это на самом деле обычное состояние веб проектов к сожалению.
И конечно это не имеет отношения к архитектуре, максимум к реализации. Как эти вещи вобще можно связать пробным образом не понимаю
Там конечно больше проблем безопасности что и одна, но для такого проекта это не очень много и их фиксят, да а тому же это единственная цмс где действительно трудно протолкнуть что то опасное даже в каталог модулей ( кого попало не пропустят ) есть процедура апрува и так тесты для модулей, опять же идея песочницы модулей
Это на самом деле обычное состояние веб проектов к сожалению.
И конечно это не имеет отношения к архитектуре, максимум к реализации. Как эти вещи вобще можно связать пробным образом не понимаю
Там конечно больше проблем безопасности что и одна, но для такого проекта это не очень много и их фиксят, да а тому же это единственная цмс где действительно трудно протолкнуть что то опасное даже в каталог модулей ( кого попало не пропустят ) есть процедура апрува и так тесты для модулей, опять же идея песочницы модулей
Приятно смотреть на то, что Drupal развивается в сторону более удобного использования.
Нет необходимости хранить код контриб модулей (и само ядро!) в вашей системе контроля версий
Преподносится как преимущество №1. Но… в чём проблема держать ядро и контриб модули в своём репозитории?
Места на терабайтном винте мало?
Или может git clone c локального gitlab'a отработает медленнее чем git clone + composer install/update?
Не воспринимайте как критику, это просто вопрос…
Не воспринимайте как критику, это просто вопрос…
Представим, что у вас есть сборка проекта под свои нужды, если она полностью лежит в git, то модули и ядро устаревают. Приходится или при выходе нового модуля сразу заменять его в git'e или оставить неактуальные версии и после git clone запускать drush up.
Оба варианта, по моему опыту, хуже работы через composer.
то модули и ядро устаревают
Ну что значит устаревают? Они остаются стабильными и оттестированными. И это главное. И это задача разработчика — накатить апдейты, просмотреть каждый на предмет адекватности, проверить чтоб работали, отдать в тестирование.
Потому как собирать каждый раз композером — вытягивать свежий код из сторонних репозиториев — слишком высок риск получить неработающий продукт внезапно в пятницу вечером просто потому что у ребят, на код которых я полагался, был плохой день и они вмержили неработающий код(или случайно поломали совместимость, или ещё 100500 причин).
Наверняка после вышесказанного Вы захотите напомнить мне про composer.lock и про то что там зафиксированы версии… но, и в моём гите они тоже зафиксированы. Причём прям сами файлы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Drupal Composer рецепты