Каким образом композер определяет установленные версии модулей?

Аватар пользователя marassa marassa 23 мая в 19:11

Верит info.yml или реально сличает все файлы с дистрибутивом модуля?
Я к чему спрашиваю: у меня несколько контрибных модулей существенно доработаны, настолько существенно, что нет смысла генерить патчи. Если я залочу их версии в composer.json, я могу быть спокоен, что композер их не будет трогать, или он, как только я отвернусь, затрёт все мои правки дистрибутивами соответствующих версий?

Лучший ответ

Аватар пользователя ivnish ivnish 23 мая в 21:18
1

В этом случае лучше перемести их в custom и убери из composer.json

Комментарии

Аватар пользователя marassa marassa 24 мая в 20:15

Можно я свои мелкие бессвязные вопросы, так или иначе связанные с composer, буду тут же задавать, чтоб не засорять форум?
Я правильно понимаю, что Друпал априорно не знает, где именно лежит модуль - в /modules, /modules/custom или /modules/contrib и на всякий случай ищет его во всех трех этих местах, и где найдет, там и ладно?

Аватар пользователя gun_dose gun_dose 24 мая в 22:37
1

Да, но после переноса модуля обязательно надо сбросить кэш. А иногда бывает, что надо ещё и php рестартовать.

Аватар пользователя marassa marassa 24 мая в 22:50

Спасибо, так и думал, проведя небольшой эксперимент. Тогда правильно ли я понимаю, что в совете выше "перемести их в custom и убери из composer.json" именно убирание из composer.json является существенным, а перемещение в custom - чистая условность, ни на что ровным счётом не влияющая?
Ну не нравится мне ещё один уровень директорий, один /sites/default/all/styles/public чего сто́ит, так теперь ещё и в модулях такая же фигня Wink Я же могу продолжать складывать все модули в одну кучу (поправив composer.json) и жить счастливо как до композера?

Аватар пользователя gun_dose gun_dose 25 мая в 7:00

Хранить модули в одной куче "очень удобно", особенно, когда у тебя штук 10 кастомных модулей без префиксов.

Аватар пользователя marassa marassa 25 мая в 8:27

У меня нет десяти кастомных модулей без префиксов... Я же забочусь о том, чтобы лично мне было удобно с моей конкретной конфигурацией. Меня почему-то мало греет осознание того, что кому-то удобно то, что мне неудобно Wink

Аватар пользователя ivnish ivnish 25 мая в 7:35

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

Аватар пользователя marassa marassa 25 мая в 8:33

Так я уже использую такой модуль - cloudflare. И сейчас решил наконец сконфигурировать composer окончательно и по уму. Но для меня по уму - это как мне удобно, а не "как все делают"©.
Это не друпал-вэй? Wink

Аватар пользователя marassa marassa 25 мая в 10:36

Мне удобно оставить все модули, и контрибные, и кастомные где они есть - в modules. Если, конечно, это не противоречит каким-то глубинным принципам работы композера. Которых я, увы, не понимаю. Потому что вся имеющая документация не объясняет как и почему так он работает, а даёт тупые инструкции "делай раз, делай два, делай три". Я так не привык. Мне комфортно, когда я, запуская команду, понимаю что, как и почему она сделает. А чего не сделает.

Аватар пользователя ivnish ivnish 25 мая в 10:40
1

Лучше сразу приучать себя к деплою, даже если ты работаешь над личными проектами. Жизнь очень непредсказуема: сегодня ты делаешь личный блог, а завтра уже работаешь в команде разработчиков над сайтом крупной компании)

Разделили папки не зря. modules/contrib в gitignore, а modules/custom нет

Аватар пользователя charOFF charOFF 25 мая в 10:19

marassa wrote: именно убирание из composer.json является существенным, а перемещение в custom - чистая условность

Если не перенести в custom, то при следующем composer update композер удалит папку модуля из modules/contrib
Обычно композер ставит пакеты в vendor, чтобы ставить (и искать) в другие папки используется composer/installers. См. секцию extra:installer-paths в composer.json в корне

  "installer-paths": {
      "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"
      ]
    },
Аватар пользователя ivnish ivnish 25 мая в 10:32
2

marassa wrote: а перемещение в custom - чистая условность

Нет, потому что папка modules/contrib по умолчанию в gitignore. То есть все твои изменения в каком-то модуле не попадут на прод при деплое (если не используется composer и патчи через него). Тут дело именно в деплое

Да и нет ничего постыдного обозвать контрибный модуль кастомным, если ты внес в него много своих изменений Wink

Аватар пользователя marassa marassa 25 мая в 10:37

ivnish wrote: папка modules/contrib по умолчанию в gitignore

Вот! Вот так, по крупицам и приходит понимание почему так сделано Wink

Аватар пользователя marassa marassa 25 мая в 16:58

Чую, что до полного просветления осталась буквально пара шагов Wink
При использовании друпала с композером рекомендуется вынести папку vendor из веб рута на уровень выше. Я даже уже не буду спрашивать зачем - ну рекомендуется и рекомендуется. Я спрошу а откуда друпал узнает, что все библиотеки теперь там, а не где были только что? В отличие от переноса модулей между modules, custom и contrib, который никак не влияет на работу сайта (после очистки кэша), перенос папки vendor на уровень выше приводит к немедленной кончине сайта Wink

Аватар пользователя ivnish ivnish 25 мая в 18:00

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

Чтобы сайт не падал, нужно несколько раз сбросить кэш и перезапустить php, чтобы сбросить кэш apcu

Аватар пользователя marassa marassa 25 мая в 18:34

Каким образом и в какой степени вынос крохотной (и наиболее "вылизанной") части кода проекта за пределы веб-рута (при том, что львиная доля кода остается внутри веб-рута) повышает безопасность?
Но об этом я как раз не спрашивал Wink Спрашивал я о другом: откуда друпал знает, что директория vendor там, а не тут?
Я прочёл инструкцию на drupal.org Add Composer to an existing site, она, кстати, довольно толковая, но в качестве единственного варианта указывается создание нового пустого сайта с помощью composer create-project и последующего копирования туда всех файлов существующего сайта. А я не могу понять, почему нельзя просто поправить нужные конфигурационные файлы существующего сайта. Но ни одна зараза нигде не пишет какие именно Wink

Аватар пользователя bsyomov bsyomov 25 мая в 21:11

Ой-ой. Не надо думать, что вот эти все тонны зависимостей, похожи на "крохотную (и наиболее "вылизанную") часть кода". Пора снять розовые очки. Это код практически не контролируемый вами. Очень разумно всё это держать подальше от webroot.
Сколько сайтов было сломано через разные кривые примеры к библиотекам, это прям даже Wordpress не снилось. Smile

Аватар пользователя marassa marassa 25 мая в 21:28

Можно спорить о том, насколько крохотная и насколько вылизанная это часть кода, но сути-то это не меняет - это всего лишь часть. А если учесть, что прямой доступ к этому коду через веб-запрос возможен только при грубой мисконфигурации веб-сервера, то оправданность этого шага выглядит ещё бледнее на мой дилетантский взгляд.

Аватар пользователя bsyomov bsyomov 25 мая в 22:13

Намного лучше спроектировать систему так, чтобы проблема была исключена, чем надеяться на то, что все правильно всё сконфигурируют...
Ну и конфиг по умолчанию drupal сейчас хоть и вайтлистит только несколько точек входа, так было не всегда, кстати.

Аватар пользователя bsyomov bsyomov 25 мая в 21:26

Потерял вторую часть ответа:

marassa wrote: А я не могу понять, почему нельзя просто поправить нужные конфигурационные файлы существующего сайта. Но ни одна зараза нигде не пишет какие именно

Да просто потому, что это просто самый простой путь.
А конфиги, это не совсем конфиги в данном случае, а целый автолоадер, который автогенерирует composer, и никто не предполагает, что туда надо лазить вообще руками. Smile

Тут не что-то надо потихоньку менять, а весь подход к развёртыванию. Smile

Аватар пользователя gun_dose gun_dose 25 мая в 18:21

Где что лежит, прописано в composer.json. Исходя из этих путей, композер генерирует автолоадер. Если после генерации автолоадера перетащить вендоров, то всё сломается

Аватар пользователя marassa marassa 26 мая в 7:42

gun_dose wrote: Где что лежит, прописано в composer.json

Про vendor там как раз ни слова нет.

gun_dose wrote: Если после генерации автолоадера перетащить вендоров, то всё сломается

Я поправил путь в autoload.php, ему еще какого-то рожна не хватает

Аватар пользователя bsyomov bsyomov 25 мая в 21:52
1

marassa wrote: Про vendor там как раз ни слова нет.

Это потому, что папка vendor в корне проекта является значением "по умолчанию".

marassa wrote: Я поправил путь в autoload.php, ему еще какого-то рожна не хватает:

В vendor/composer/autoload_classmap.php
Путь до ядра такой: 'Drupal' => $baseDir . '/web/core/lib/Drupal.php' ? (ну или соответствующий проекту).
Но вообще правильнее что-то типа composer dump-autoload, а не руками туда лезть.

Аватар пользователя marassa marassa 25 мая в 22:18

bsyomov wrote: Намного лучше спроектировать систему так, чтобы проблема была исключена

Всецело и полностью согласен! В какой версии Друпал планируется убрать ВЕСЬ php-код (кроме index.php) из веб-рута?

Аватар пользователя marassa marassa 25 мая в 22:36

bsyomov wrote:у нас больше одной точки входа

Это где-то несмываемым маркером записано? Wink Можно оставить три trusted файла в веб-руте, можно сделать так, чтобы точка входа была одна. Всё возможно, если есть реальное желание решить проблему, а не создать видимость решения.

Аватар пользователя bsyomov bsyomov 25 мая в 22:50

Да можно. И дать возможность создавать пользователю ещё по необходимости, если нужны другие уровни бутстрапа, например.
Так сделано по умолчанию в некоторых фреймворках, кстати. Только точки входа и статика в webroot.

Нынешняя структура, в первую очередь, результат некого постепенного развития. Изменить всё и сразу не так просто. А вынести библиотеки в отдельную папку, да ещё как это делается композером по умолчанию довольно просто.

Возможно в какой-нибудь условной 11 версии будет и так, как выше описано. Но пока у нас в модулях могут быть стили, скрипты, картинки и.т.п. И разбивать модуль на код и статику, не так уж удобно. Так что может и не будет.

Аватар пользователя gun_dose gun_dose 25 мая в 23:39

marassa wrote: возможен только при грубой мисконфигурации веб-сервера

Любой шаред-хостинг по умолчанию позволяет выполнять любой php-файл по прямому запросу. И дефолтный друпаловский .htaccess эту проблему не решает. Поэтому изначально при настройке какой-либо безопасности нужно исходить из того, что любой php-файл доступен для прямого вызова через веб. А вот если это вынести на уровень выше веб-директории, то утверждение про "мисконфигурацию сервера" становится абсолютно справедливым.

Аватар пользователя marassa marassa 26 мая в 7:44

gun_dose wrote: Любой шаред-хостинг по умолчанию позволяет выполнять любой php-файл по прямому запросу. И дефолтный друпаловский .htaccess эту проблему не решает.

Не понял, поясни пожалуйста.

Аватар пользователя gun_dose gun_dose 26 мая в 8:55

Создай файл под названием hello.php, напиши туда:

<?php
echo 'Hello!';
?>

Положи файл в папку core/modules, а затем набери в браузере "твой-сайт/core/modules/hello.php"

Аватар пользователя marassa marassa 26 мая в 9:20

404, как и ожидалось. С дефолтным .htaccess.
А вот в папке core запускается. Что, собственно, только подтверждает мою мысль об изначально дырявой безопасности друпала. И вынос отдельной произвольно взятой папки vendor за пределы веб-рута эту проблему не решает никак.