Обновление до 8.8 + переход на composer: совет нужен

Аватар пользователя marassa marassa 9 апреля в 10:32

Прошу совета опытных по наилучшему порядку действий.

Вводные:
- Имеется сайт на 8.6.15
- Несколько десятков контрибных модулей + один свой кастомный
- Composer до сих пор не использовался, всё обновлялось ручками
- И dev и prod находятся в двух разных аккаунтах на одном shared-хостинге (ра-дон), локальной инсталляции нет и не хотелось бы без крайней необходимости
- Некоторые контриб-модули существенно доработаны прям в директориях модулей, поэтому их обновлять нельзя
- Есть несколько патчей ядра и контриба, которые надо перенести на новую версию (всегда делал это руками, при необходимости подправлял)

Чего хочется:
- Обновить сайт до текущей версии (8.8.5), ничего не сломав Wink
- В идеале перейти на композер, ничего не сломав Wink

Чего опасаюсь:
- Неоднократно видел сообщения о всевозможных проблемах при переходе на 8.8.
Отсюда вопрос: стоит ли вообще пытаться обновляться прямо с 8.6.15 до 8.8.5, или нужны какие-то промежуточные остановки? Какие? На что обращать внимание?
- Слышал, что composer на dev'е хочет очень много ресурсов, которые shared-хостинг не всегда в состоянии предоставить. Значит ли это, что на самом дешевом тарифе ра-дона, на котором у меня хостится dev, можно даже не пытаться?
- Если всё же стоит попытаться, то в каком именно порядке? Сначала обновиться, потом перевести на композер? Сначала композер, потом обновиться? Как сделать так, чтобы композер даже не пытался обновлять избранные модули без спроса?
- Если нет, то есть ли жизнь на 8.8 (и дальше) без композера? На 8.6 точно знаю что есть, несмотря на многочисленные уверения в обратном Wink

Комментарии

Аватар пользователя ivnish ivnish 9 апреля в 10:42
1

Я бы делал так (впрочем, я так и делал на нескольких проектах)

1) Обновить ядро вручную до 8.7. Убедиться, что всё работает
2) Обновить ядро вручную до 8.8. Убедиться, что всё работает
3) Перевести проект на composer (https://niklan.net/blog/185). Только теперь вместо composer-drupal-project лучше использовать core-recommended
4) Модули, которые патчились вручную, начать патчить с помощью composer.
5) Обновить модули и темы с помощью composer до актуальных версий
6) Продолжать разработку уже с помощью composer

- Слышал, что composer на dev'е хочет очень много ресурсов, которые shared-хостинг не всегда в состоянии предоставить. Значит ли это, что на самом дешевом тарифе ра-дона, на котором у меня хостится dev, можно даже не пытаться?

Разработку всегда лучше вести на локальной машине. Это быстрее и удобнее

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

Залочить текущие версии модулей в composer.json

Если нет, то есть ли жизнь на 8.8 (и дальше) без композера?

Есть, но с постоянным геморроем, особенно, когда нужно патчить ядро и контриб. С composer всё делается автоматически

Аватар пользователя marassa marassa 9 апреля в 10:50

Спасибо!

ivnish wrote: Перевести проект на composer (https://niklan.net/blog/185). Только теперь вместо composer-drupal-project лучше использовать core-recommended

Это единственное изменение? В остальном пост Никлана еще актуален?

ivnish wrote: Разработку всегда лучше вести на локальной машине. Это быстрее и удобнее

Я это слышал неоднократно, но лично мне на протяжении последних трех с лишним лет было быстрее и удобнее на удаленной Wink

ivnish wrote: Залочить текущие версии модулей в composer.json

То есть композер содержимое директорий не проверяет и поверит на слово, что если в geolocation.info.yml написано version: '8.x-1.10', то так оно и есть, хотя на самом деле это не совсем так? Wink

ivnish wrote: Есть

Уф, отлегло Wink
Значит буду сначала обновляться как привык, а потом факультативно займусь композером.
Еще раз спасибо!

Аватар пользователя sas@drupal.org sas@drupal.org 9 апреля в 10:55

Это добавление компосера Add Composer to an existing site
https://www.drupal.org/docs/8/install/add-composer-to-an-existing-site
Обновление до 8.8 по этой инструкции
Special considerations for upgrading to Drupal 8.8.0 and later
https://www.drupal.org/docs/8/update/update-core-via-composer#s-special-...

Аватар пользователя ivnish ivnish 9 апреля в 10:58

Это единственное изменение? В остальном пост Никлана еще актуален?

Да. Там как раз есть раздел как перевести сайт на composer

Я это слышал неоднократно, но лично мне на протяжении последних трех с лишним лет было быстрее и удобнее на удаленной

Не каждый хостинг справится с командой composer update . Радоновский должен, хотя я не пробовал. А вот PHPStorm довольно сильно тормозит при работе с сайтом, который подключен по sftp или по ftp. Особенно индексация. Но хозяин - барин, как говорится Smile

То есть композер содержимое директорий не проверяет и поверит на слово, что если в geolocation.info.yml написано version: '8.x-1.10', то так оно и есть, хотя на самом деле это не совсем так?

В geolocation.info.yml ничего менять не нужно. Если версия модуля 8.x-1.10, значит нужно такую же указать в composer.json без использования ^ и ~ В этом случае composer не будет трогать этот модуль

Значит буду сначала обновляться как привык, а потом факультативно займусь композером.

Удачи Smile Но имей в виду, что некоторые старые модули могут перестать работать на 8.7 и 8.8, их придется обновить принудительно после обновления ядра. Что и когда обновлять поможет чтение changelog'ов модулей на орге

Аватар пользователя marassa marassa 9 апреля в 11:18

ivnish wrote: PHPStorm довольно сильно тормозит при работе с сайтом, который подключен по sftp или по ftp

PHPStorm и системное использование Git - это следующий этап. Пока по старинке редактирую всё в FARе как пещерный человек Wink А Git запускаю только когда нужно патч сформировать для .org...

ivnish wrote: В geolocation.info.yml ничего менять не нужно

Это понятно, просто версия, прописанная в info.yml при первоначальной скачке модуля не соответствует реальной кодовой базе с многочисленными моими правками. Мне важно было понять, что композер поверит цифре в info.yml и оставит директорию модуля в покое, а не станет сличать файлы в директориях модуля с дистрибутивом заявленной версии.

ivnish wrote: некоторые старые модули могут перестать работать на 8.7 и 8.8

Это тоже понятно уже.

Аватар пользователя jura12 jura12 9 апреля в 14:17

Работай с друпалом правильно!

после 8.8 я обновляюсь в следующем порядке:
1.делаем бэкап сайта
2.запускаем скрипт обновления в каталоге /var/www/drupal8 скрипт

vendor/bin/drush sset system.maintenance_mode 1
vendor/bin/drush cache:rebuild
chmod 755  /var/www/drupal8/web/sites/default
composer update drupal/core-recommended --with-dependencies
chmod 555  /var/www/drupal8/web/sites/default
vendor/bin/drush updatedb
vendor/bin/drush cache:rebuild
vendor/bin/drush cron
vendor/bin/drush sset system.maintenance_mode 0
vendor/bin/drush cache:rebuild

источник информации

Аватар пользователя marassa marassa 11 апреля в 14:10

Промежуточный отчёт: поддавшись лени, решил рискнуть обновить dev с 8.6.15 прям до 8.8.5 и, как ни странно, получилось вообще без ошибок. Потом повторил то же на проде. Видимо, у меня просто не используются "проблемные" модули, только Pathauto пришлось обновить до 1.6. Потом еще и PHP обновил до 7.2. По результатам поверхностного тестирования всё вроде бы работает.
Разбираюсь с композером, возникают еще вопросы:
1. Есть ли смысл использовать автоматизированные "композеризаторы" легаси-проектов типа Composerize Drupal?
2. Понимаю, что для работы с composer нужно будет каким-то образом перенаправить веб-сервер на вновь создаваемую папку web. А как это вообще делается на shared-хостинге? Ра-дон, если это важно.
3. Вижу, что контрибные модули в композер-проектах теперь зачем-то полагается складывать в modules/contrib, а не просто в modules - это нужно/обязательно?

Аватар пользователя ivnish ivnish 11 апреля в 14:16
1

1. Наверное нет смысла, учитывая как просто это делается вручную
2. Я на радоне делаю так:
* кладу корень проекта в каталог site
* удаляю каталог public_html
* делаю символическую ссылку site/web -> public_html
Вообще, я писал об этом документацию
3. Да, контрибные в contrib, кастомные в custom. Это общепринятая практика

Аватар пользователя marassa marassa 11 апреля в 15:11

Спасибо, твою документацию видел ведь, но забыл. Вообще одной из главных проблем композера в друпале вижу обилие устаревшей/туманной/противоречащей друг другу и самой себе документации...

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

Задам еще один вопрос про композер, чтоб два раза не вставать: ну вот допустим перевёл я сайт полностью на композер, включая контрибные модули. Насколько я понимаю, тогда обновлять модули можно будет ТОЛЬКО через композер, т.е. в command line. А через удобную и наглядную страницу /admin/modules/update, которую никто пока никуда из ядра не убрал и вроде не собирается, теперь нельзя, так? Какой-то когнитивный диссонанс получается...

Аватар пользователя ivnish ivnish 12 апреля в 9:23

Почему диссонанс? Посмотрел на странице какие модули нуждаются в обновлении, обновил через командную строку. Через веб тоже можно обновить, но информация об обновлении не попадет в composer.lock. А это важно, если работу ведешь на локалке, а потом деплоишь на прод

Аватар пользователя marassa marassa 12 апреля в 9:31

ivnish wrote: Почему диссонанс?

Ну как почему? В Drupal помимо command line тулзов [пока еще] имеется административный веб-интерфейс. В этом интерфейсе имеется страница, позволяющая посмотреть какие модули имеют обновления, тут же посмотреть release notes и тут же одним кликом выбрать и обновить нужные модули. Но только делать этого нельзя, потому что

ivnish wrote: информация об обновлении не попадет в composer.lock. А это важно

А composer является настоятельно рекомендованным инструментом ведения зависимостей Drupal. А на ядерной странице, приглашающей [неопытного] админа обновить модули в обход настоятельно рекомендованного инструмента, ни слова про это не сказано. Как же не диссонанс? Wink

Аватар пользователя ivnish ivnish 12 апреля в 9:32

Понимаю) Я сам на этой странице смотрю обновления читаю release notes. К этому просто надо привыкнуть. Не исключено, что в каком-нибудь Drupal 9 или Drupal 10 вообще уберут возможность обновляться через админку

Аватар пользователя marassa marassa 12 апреля в 9:46

ivnish wrote: Не исключено, что в каком-нибудь Drupal 9 или Drupal 10 вообще уберут возможность обновляться через админку

Тем самым завершив превращение Drupal в заградительно сложный в освоении инструмент, предназначенный исключительно для матёрых программирующих профессионалов, чувствующих себя в CLI как рыба в воде, и окончательно потеряв немалую долю "мышекликеров", которые до сих пор могли строить (и продавать, и сопровождать) вполне функциональные сайты на Друпал.
На мой взгляд правильнее было бы включить в админку некую веб-обёртку композера, которая позволяла бы выполнять бóльшую часть типовых команд композера, не вылезая в CLI.

Аватар пользователя VasyOK VasyOK 12 апреля в 21:44
1

"исключительно для матёрых программирующих профессионалов"
Если ваш патч, положили в новую версию модуля, значит это вы и есть.

Мышекликеры они на 7 ке остались и боятся признавать, что 8-ка для них сложна. Это я эксгибиционист и не стесняюсь если что-то не выходит.

Про обновление. После того, как наложишь 10 патчей в composer.json и сделаешь
composer install
composer update
оно как-то полегче становится.