23 мая 2021 в 19:11
Верит info.yml или реально сличает все файлы с дистрибутивом модуля?
Я к чему спрашиваю: у меня несколько контрибных модулей существенно доработаны, настолько существенно, что нет смысла генерить патчи. Если я залочу их версии в composer.json, я могу быть спокоен, что композер их не будет трогать, или он, как только я отвернусь, затрёт все мои правки дистрибутивами соответствующих версий?
23 мая 2021 в 21:18
В этом случае лучше перемести их в custom и убери из composer.json
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
В этом случае лучше перемести их в custom и убери из composer.json
Спасиб, не подумал об этом.
Можно я свои мелкие бессвязные вопросы, так или иначе связанные с composer, буду тут же задавать, чтоб не засорять форум?
Я правильно понимаю, что Друпал априорно не знает, где именно лежит модуль - в /modules, /modules/custom или /modules/contrib и на всякий случай ищет его во всех трех этих местах, и где найдет, там и ладно?
Да, но после переноса модуля обязательно надо сбросить кэш. А иногда бывает, что надо ещё и php рестартовать.
Спасибо, так и думал, проведя небольшой эксперимент. Тогда правильно ли я понимаю, что в совете выше "перемести их в custom и убери из composer.json" именно убирание из composer.json является существенным, а перемещение в custom - чистая условность, ни на что ровным счётом не влияющая?
Я же могу продолжать складывать все модули в одну кучу (поправив composer.json) и жить счастливо как до композера?
Ну не нравится мне ещё один уровень директорий, один /sites/default/all/styles/public чего сто́ит, так теперь ещё и в модулях такая же фигня
Хранить модули в одной куче "очень удобно", особенно, когда у тебя штук 10 кастомных модулей без префиксов.
У меня нет десяти кастомных модулей без префиксов... Я же забочусь о том, чтобы лично мне было удобно с моей конкретной конфигурацией. Меня почему-то мало греет осознание того, что кому-то удобно то, что мне неудобно
Ты будешь не использовать composer ровно до того момента, когда тебе нужно будет установить модуль, который ставится только через composer. Тот же commerce, например
Так я уже использую такой модуль - cloudflare. И сейчас решил наконец сконфигурировать composer окончательно и по уму. Но для меня по уму - это как мне удобно, а не "как все делают"©.
Это не друпал-вэй?
А как "тебе удобно"? Поясни подробнее)
Мне удобно оставить все модули, и контрибные, и кастомные где они есть - в modules. Если, конечно, это не противоречит каким-то глубинным принципам работы композера. Которых я, увы, не понимаю. Потому что вся имеющая документация не объясняет как и почему так он работает, а даёт тупые инструкции "делай раз, делай два, делай три". Я так не привык. Мне комфортно, когда я, запуская команду, понимаю что, как и почему она сделает. А чего не сделает.
Лучше сразу приучать себя к деплою, даже если ты работаешь над личными проектами. Жизнь очень непредсказуема: сегодня ты делаешь личный блог, а завтра уже работаешь в команде разработчиков над сайтом крупной компании)
Разделили папки не зря. modules/contrib в gitignore, а modules/custom нет
Если не перенести в custom, то при следующем composer update композер удалит папку модуля из modules/contrib
Обычно композер ставит пакеты в vendor, чтобы ставить (и искать) в другие папки используется composer/installers. См. секцию extra:installer-paths в composer.json в корне
"docroot/core": [
"type:drupal-core"
],
"docroot/modules/contrib/{$name}": [
"type:drupal-module"
],
"docroot/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"docroot/themes/contrib/{$name}": [
"type:drupal-theme"
],
"docroot/drush/contrib/{$name}": [
"type:drupal-drush"
],
"docroot/libraries/{$name}": [
"type:drupal-library"
]
},
Нет, потому что папка modules/contrib по умолчанию в gitignore. То есть все твои изменения в каком-то модуле не попадут на прод при деплое (если не используется composer и патчи через него). Тут дело именно в деплое
Да и нет ничего постыдного обозвать контрибный модуль кастомным, если ты внес в него много своих изменений
Вот! Вот так, по крупицам и приходит понимание почему так сделано
Чую, что до полного просветления осталась буквально пара шагов
При использовании друпала с композером рекомендуется вынести папку vendor из веб рута на уровень выше. Я даже уже не буду спрашивать зачем - ну рекомендуется и рекомендуется. Я спрошу а откуда друпал узнает, что все библиотеки теперь там, а не где были только что? В отличие от переноса модулей между modules, custom и contrib, который никак не влияет на работу сайта (после очистки кэша), перенос папки vendor на уровень выше приводит к немедленной кончине сайта
Выносят для того, чтобы не было возможности обратиться к этим файлам и библиотекам через вебсервер. В целях безопасности, кароч
Чтобы сайт не падал, нужно несколько раз сбросить кэш и перезапустить php, чтобы сбросить кэш apcu
Каким образом и в какой степени вынос крохотной (и наиболее "вылизанной") части кода проекта за пределы веб-рута (при том, что львиная доля кода остается внутри веб-рута) повышает безопасность?
Спрашивал я о другом: откуда друпал знает, что директория vendor там, а не тут?
Но об этом я как раз не спрашивал
Я прочёл инструкцию на drupal.org Add Composer to an existing site, она, кстати, довольно толковая, но в качестве единственного варианта указывается создание нового пустого сайта с помощью composer create-project и последующего копирования туда всех файлов существующего сайта. А я не могу понять, почему нельзя просто поправить нужные конфигурационные файлы существующего сайта. Но ни одна зараза нигде не пишет какие именно
Ой-ой. Не надо думать, что вот эти все тонны зависимостей, похожи на "крохотную (и наиболее "вылизанную") часть кода". Пора снять розовые очки. Это код практически не контролируемый вами. Очень разумно всё это держать подальше от webroot.
Сколько сайтов было сломано через разные кривые примеры к библиотекам, это прям даже Wordpress не снилось.
Можно спорить о том, насколько крохотная и насколько вылизанная это часть кода, но сути-то это не меняет - это всего лишь часть. А если учесть, что прямой доступ к этому коду через веб-запрос возможен только при грубой мисконфигурации веб-сервера, то оправданность этого шага выглядит ещё бледнее на мой дилетантский взгляд.
Намного лучше спроектировать систему так, чтобы проблема была исключена, чем надеяться на то, что все правильно всё сконфигурируют...
Ну и конфиг по умолчанию drupal сейчас хоть и вайтлистит только несколько точек входа, так было не всегда, кстати.
Потерял вторую часть ответа:
Да просто потому, что это просто самый простой путь.
А конфиги, это не совсем конфиги в данном случае, а целый автолоадер, который автогенерирует composer, и никто не предполагает, что туда надо лазить вообще руками.
Тут не что-то надо потихоньку менять, а весь подход к развёртыванию.
Где что лежит, прописано в composer.json. Исходя из этих путей, композер генерирует автолоадер. Если после генерации автолоадера перетащить вендоров, то всё сломается
Про vendor там как раз ни слова нет.
Я поправил путь в autoload.php, ему еще какого-то рожна не хватает
Это потому, что папка vendor в корне проекта является значением "по умолчанию".
В
vendor/composer/autoload_classmap.phpПуть до ядра такой:
'Drupal' => $baseDir . '/web/core/lib/Drupal.php'? (ну или соответствующий проекту).Но вообще правильнее что-то типа
composer dump-autoload, а не руками туда лезть.Спасибо, гляну.
Всецело и полностью согласен! В какой версии Друпал планируется убрать ВЕСЬ php-код (кроме index.php) из веб-рута?
Напомнить, что у нас больше одной точки входа, и так радикально не выйдет?
Это где-то несмываемым маркером записано?
Можно оставить три trusted файла в веб-руте, можно сделать так, чтобы точка входа была одна. Всё возможно, если есть реальное желание решить проблему, а не создать видимость решения.
Да можно. И дать возможность создавать пользователю ещё по необходимости, если нужны другие уровни бутстрапа, например.
Так сделано по умолчанию в некоторых фреймворках, кстати. Только точки входа и статика в webroot.
Нынешняя структура, в первую очередь, результат некого постепенного развития. Изменить всё и сразу не так просто. А вынести библиотеки в отдельную папку, да ещё как это делается композером по умолчанию довольно просто.
Возможно в какой-нибудь условной 11 версии будет и так, как выше описано. Но пока у нас в модулях могут быть стили, скрипты, картинки и.т.п. И разбивать модуль на код и статику, не так уж удобно. Так что может и не будет.
Любой шаред-хостинг по умолчанию позволяет выполнять любой php-файл по прямому запросу. И дефолтный друпаловский .htaccess эту проблему не решает. Поэтому изначально при настройке какой-либо безопасности нужно исходить из того, что любой php-файл доступен для прямого вызова через веб. А вот если это вынести на уровень выше веб-директории, то утверждение про "мисконфигурацию сервера" становится абсолютно справедливым.
Не понял, поясни пожалуйста.
Создай файл под названием hello.php, напиши туда:
<?phpecho 'Hello!';
?>
Положи файл в папку core/modules, а затем набери в браузере "твой-сайт/core/modules/hello.php"
404, как и ожидалось. С дефолтным .htaccess.
А вот в папке core запускается. Что, собственно, только подтверждает мою мысль об изначально дырявой безопасности друпала. И вынос отдельной произвольно взятой папки vendor за пределы веб-рута эту проблему не решает никак.
Просто папка vendor в теории наиболее опасная. Равно, как node_modules в javascript.