Нижче КІ для патча - релізів 8.4.x> 8.4.y , але не нормальні для незначних випусків 8.4.x> 8.5.x . Перейдіть до ОНОВЛЕННЯ 3 нижче, що, на мою думку, є "відповіддю" на незначні оновлення випусків.
1- Зробіть резервну копію будь-яких файлів, які постачаються разом із Drupal, які ви змінили, наприклад .htaccess, robots.txt тощо (ці 2 найбільш часто змінюються).
2- [мені кажуть, що видалити файл блокування неправильно, див. ОНОВЛЕННЯ нижче] Видаліть файл composer.lock (у папці верхнього рівня вашого сайту). Це буде відтворено на кроці 5.
3- Перевірте ваш composer.json (у папці верхнього рівня вашого сайту) і переконайтеся, що "drupal: core" знаходиться в розділі "вимагати", а не в розділі "замінити", наприклад
"require": {
"drupal/core": "^8.4"
},
ні
"replace": {
"drupal/core": "^8.4"
},
Якщо "drupal / core" знаходиться в розділі заміни, перемістіть його до потрібного розділу та видаліть розділ заміни. Якщо в розділі заміни є інші записи, просто видаліть "drupal / core" не весь розділ заміни - але я думаю, що "drupal / core", як правило, є єдиним.
Помістіть, до якої версії ви хочете оновити, в "drupal / core", приклади:
"drupal / core": "^ 8.5" - оновиться до останньої версії 8.5. "drupal / core": "8.4.6" - оновиться до версії 8.4.6.
5- Запустіть це (у папці верхнього рівня вашого сайту):
composer update drupal/core --with-dependencies
6- Якщо помилок немає, виконайте звичайні дії, запустіть оновлення та очистіть кеш:
drush updatedb
drush cr
Або якщо не використовується drush, перейдіть до /update.php, щоб запустити оновлення, а потім до адміністратора / конфігурації / розробки / продуктивності та натисніть кнопку «Очистити всі кеші».
7- Якщо ви створили резервну копію файлів на першому кроці (.htaccess, robots.txt), поставте їх назад. Але перевірте, чи Drupal вносив оновлення до цих файлів і додайте ці зміни до своїх.
Зроблено
Якщо на кроці 5 були помилки з оновленням композитора, це, як правило, пов'язано з проблемами з версіями матеріалів у папці постачальника.
Це чудовий пост у вирішенні таких питань: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update та прочитайте інші 2 публікації Джеффа про Drupal та Composer, щоб отримати більше знань про це.
Мені двоє людей у Twitter сказали, що composer.lock не слід видаляти (крок 2 вище). composer update drupal/core --with-dependencies
Команда відтворює файл блокування в будь-якому випадку.
Під час тестування цього методу я вважаю, що він працює добре для 8.4.3> 8.4.6 (наприклад), але я отримую помилки для 8.4.6> 8.5.x. Повідомлять про те, коли я зрозумію.
Приклад помилок:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
- symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
- symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
- drupal/core 8.5.0 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
- Installation request for drupal/core 8.5.0 -> satisfiable by drupal/core[8.5.0].
- Installation request for symfony/console (locked at v3.2.8, required as ~3.2.8) -> satisfiable by symfony/console[v3.2.8].
Цей пост Джеффа Джерлінга вирішує подібні проблеми, але поки що мені не пощастило: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
Отже ... єдине, що, здається, працює для мене для 8.4.x> 8.5.x - це "ядерний варіант", який, здається, використовує так багато інших, який виконується composer update
.
Я думаю, що це нормально, якщо ви впевнені у версіях модуля в composer.json. Можливо, варто заблокувати їх до поточної версії. Наприклад:
"drupal/address": "1.3"
а не:
"drupal/address": "^1.3"
Але правильна відповідь?
Гаразд, відповідь, яка, здається, є скрізь, - це зробити "ядерний варіант":
A. Видаліть /vendor
папку.
B. Запустіть composer update
і просто оновіть свої модулі разом з core. Або заблокуйте версії модулів, composer.json
якщо ви не хочете їх оновлювати.
Одна людина на Drupal Slack сказала, що «вся філософія композитора полягає в тому, що ви завжди повинні оновлювати пакунки, як можна частіше» . Пакет включає модулі, які я думаю. Отже, я певно має сенс.
Як тільки я отримав від 8.4.6 до 8.5.0, це спрацювало чудово, щоб отримати від 8.5.0 до 8.5.1 так composer update drupal/core --with-dependencies
само, як це було для 8.4.3 до 8.4.6.
Я починаю робити висновок, що "відповідь" полягає в тому, що видалити папку постачальника і файл composer.lock, потім використовувати composer update
це нормально, і потрібно просто переконатися, що номери версій для залежностей у файлі composer.json потрібні вам . Керувати версіями модулів, які ви хочете зберегти, або дозволити їх оновлення не так вже й складно composer.json
.
Наприклад:
"drupal/admin_toolbar": "1.18",
означає палицю з 1.18
"drupal/admin_toolbar": "^1.18",
означає продовжувати та оновлювати, але не більше 1.x (не 2.x)
Це підкріплене коментарем (Загальний Redneck) до цього повідомлення: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update
"Одне з речей, які я як я працюю в підтримку, це те, що блокування версій модулів та ядра є гарною ідеєю, щоб ви МОЖЕТТЕ термонести річ, коли хочете, бо бувають випадки, коли деякі з різних плагінів навіть не хочуть вести себе правильно ".
До речі, файл composer.lock не допоможе, composer update
оскільки він здувається (на відміну від того, composer install
де читається файл блокування):
Біг composer install
буде:
- Перевірте, чи
composer.lock
існує
- Якщо ні, виконайте команду a,
composer update
щоб створити її
- Якщо
composer.lock
існує, встановіть вказані версії з файлу блокування
Біг composer update
буде:
- Перевірити
composer.json
- Визначте найновіші версії для встановлення на основі специфікацій версій
- Встановіть останні версії
- Оновлення,
composer.lock
щоб відображати останні встановлені версії
Посилання: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file
Я бачу, про це згадувалося вище: https://github.com/drupal-composer/drupal-project . Я це використав, і це добре, але це не вимога для використання композитора з Drupal. Це заплутано, оскільки це наче "звучить" так, як це від назви. Коли я вперше розпочав роботу з Drupal 8, я подумав, що це потрібно, тому створив свій перший D8-сайт із цим, вважаючи, що це найкраща практика.
У тій "версії" Drupal він докрокотить у папці / web, а не у верхній папці проекту. Також є маса матеріалів, доданих до .gitignore порівняно із звичайними Drupal:
/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/
Отже, ця версія Drupal справді більше призначена для сайтів, які використовують постійну інтеграцію, щоб робити нову збірку Drupal при кожному розгортанні, використовуючи встановлення композитора. Якщо ви розгортаєтесь за допомогою більш звичайного методу, вам, очевидно, доведеться зафіксувати всі вищезазначені матеріали для свого git repo, інакше він не буде розгорнуто на ваш сервер [1], і цей матеріал необхідний для запуску Drupal.
[1] якщо git пов'язаний з вашим розгортанням - якщо ви розгортаєтесь із SFTP, ігноруйте це.