Який правильний робочий процес оновлення основної композиції?


16

Я хочу використовувати композитор для управління залежностями Drupal 8, але я не впевнений, що є правильним робочим процесом оновлення ядра. На даний момент я використовую drush для оновлення ядра до останньої версії бета-версії, але у мене також є деякі залежності у моєму файлі composer.json, тому після оновлення я використовую програму composer install для встановлення всіх залежностей постачальника contrib. Здається, що запущення composer installзамінює деякі файли в основному каталозі, хоча я якраз оновив ядро ​​до останньої версії.

Я також намагався вручну відредагувати файл composer.json і замінити рядок "drupal / core" конкретним бета-версією, наприклад "drupal/core": "~8.0-beta14",, але він все ще перекриває файли в основному каталозі.

Який правильний робочий процес?

Відповіді:


11

Я припускаю, що ви використовуєте drupal-композитор / drupal-проект як основу для свого проекту. Якщо ні, то подивіться на цей проект і порівняйте його з вашим.

Крім того, ви сказали, що хочете використовувати композитор для управління залежностями Drupal 8, тож я припускаю, що ви вибрали модулі contrib через, composer require drupal/develа не drush dl devel.

Якщо ви робите всі ці речі, то вам слід скористатися composer updateдля оновлення ядра Drupal та всіх модулів contrib. Поки ви зберігаєте свій composer.lockфайл, composer installне слід змінювати версію будь-якої вашої залежності. Використовувати drush pm-updateвзагалі не слід . Для вас не має значення core, оновлені чи ні файли в каталозі, оскільки цим каталогом керує Composer. Вам краще не вводити каталоги, керовані композиторами, у своє сховище, хоча ви можете, якщо хочете.

Звичайно, слід запускати drush updatedbщоразу, коли composer updateзамінюється ядро ​​Drupal або будь-який модуль.

Щоб уникнути отримання версій розробки, встановіть мінімальну стабільність на "бета" у вашому файлі composer.json, використовуючи прапорці стабільності Composer .

Якщо ви використовуєте drupal-composer / drupal-project для управління своїм сайтом, то всі файли кореневого рівня, такі як README.txt, .htaccess та index.html, належать вашому проекту. Це означає, що ви повинні перевірити їх у своєму сховищі git; Композитор не оновлюватиме їх, ви повинні оновити їх самостійно, коли вони зміняться. Ці файли повинні змінюватися рідко, але drupal-composer / drupal-project має сценарій для оновлення цих файлів .


Давайте припустимо, що я використовую оновлення композитора замість ударного оновлення pm, як я оновлюю файли, такі як README.txt, .htaccess тощо.? І як приходить оновлення друку, яке дає інше ядро, ніж оновлення композитора? І чи варто замінювати версію drupal в моєму composer.json на 8.0-betaX перед кожним оновленням? Я не хочу використовувати dev. версія ..
rreiss

Оновлено відповідь.
greg_1_anderson

+1 greg_1_anderson - це виглядає чудово, чи це остаточний спосіб робити оновлення безпеки для Drupal 8? з D7, це: drupal.stackexchange.com/a/71578
therobyouknow

Це виглядає так, як це працює, якщо спочатку встановили Drupal 8.1 з цими кроками: drupal.org/node/2471553 (я виявив, що це працює без помилок)
therobyouknow

"Звичайно, вам слід запускати drush updatedbщоразу, коли оновлення композитора замінить ядро ​​Drupal або будь-який модуль." - дякую, і якщо ви спочатку встановили drupal за допомогою цих кроків, drupal.org/node/2471553, тоді вам потрібен повний шлях до конкретного барабана за допомогою вашої установки Drupal 8 (як вони використовувались для запуску установки як завершального кроку). Спочатку вам потрібно ввімкнути CD в web, а потім в команді / web команда для оновлення db з повним шляхом буде такою: ../vendor/drush/drush/drush updatedb(Я виявив, що це працює).
therobyouknow

2

Нижче КІ для патча - релізів 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, ігноруйте це.


composer update drupal/core symfony/config webflo/drupal-core-strict --with-dependenciesще ніколи мене не підводив. Працює над декількома незначними версіями, наприклад, 8.3 -> 8.6
Clive

1

Використовуючи пакет drupal / core на packgist.org, ми можемо реально керувати ядром, модулями допису (темами та профілями) та іншими постачальниками за допомогою композитора.

Я встановив наступні файли в моєму кореневому каталозі та виконав composer install

composer.json

{
  "require": {
    "composer/installers": "^1.0.20",
    "drupal/core": "8.0.*"
  },
  "extra": {
    "installer-paths": {
      "core": ["type:drupal-core"],
      "modules/contrib": ["type:drupal-module"],
      "profiles/contrib": ["type:drupal-profile"],
      "themes/contrib": ["type:drupal-theme"]
    }
  },
  "scripts": {
    "post-install-cmd": [
      "./post_install.sh"
    ]
  }
}

post_install.sh

#!/usr/bin/env bash
export RAW_DRUPAL="https://raw.githubusercontent.com/drupal/drupal/8.0.x"
curl $RAW_DRUPAL/example.gitignore > example.gitignore
curl $RAW_DRUPAL/.gitattributes > .gitattributes
curl $RAW_DRUPAL/.htaccess > .htaccess
curl $RAW_DRUPAL/.csslintrc > .csslintrc
curl $RAW_DRUPAL/.editorconfig > .editorconfig
curl $RAW_DRUPAL/.eslintrc > .eslintrc
curl $RAW_DRUPAL/.eslintignore > .eslintignore
curl $RAW_DRUPAL/index.php > index.php
curl $RAW_DRUPAL/update.php > update.php
curl $RAW_DRUPAL/web.config > web.config
curl $RAW_DRUPAL/autoload.php > autoload.php
curl $RAW_DRUPAL/robots.txt > robots.txt
mkdir -p sites/default
curl $RAW_DRUPAL/sites/example.sites.php > sites/example.sites.php
curl $RAW_DRUPAL/sites/development.services.yml > sites/development.services.yml
curl $RAW_DRUPAL/sites/example.settings.local.php > sites/example.settings.local.php
curl $RAW_DRUPAL/sites/default/default.services.yml > sites/default/default.services.yml
curl $RAW_DRUPAL/sites/default/default.settings.php > sites/default/default.settings.php

Насолоджуйтесь :)


Я здогадуюсь, мені знадобиться вся ця магія завивки, яку ти зробив. Я очікував, що всі ці потрібні файли буде створений композитором.
dxvargas

@hiphip Файли за межами основного каталогу не змінюються часто, тому вищевикладене може бути сценарієм, який ви виконуєте вручну при оновленнях друпалів від однієї другорядної версії до наступної (тобто 8.1 до 8.2)
Eyal

1

Так, ви можете керувати ядром Drupal разом із композитором. Але варто пам’ятати про кілька речей.

Ви, ймовірно, отримаєте тайм-аути через певну кількість предметів, через які композитор повинен пройти, особливо якщо ви працюєте в локальній віртуальній машині. Якщо ви запустите, composer installви, ймовірно, отримаєте помилку композитора:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Переконайтеся, що ви використовуєте вимагає

{
  "require": {
   "drupal/core": "8.3.*"

Також додайте розширення до тайм-ауту в налаштуваннях

    "installer-paths": {
        "core": ["type:drupal-core"],
        "modules/contrib/{$name}": ["type:drupal-module"],
        "profiles/contrib/{$name}": ["type:drupal-profile"],
        "themes/contrib/{$name}": ["type:drupal-theme"],
        "drush/contrib/{$name}": ["type:drupal-drush"],
        "modules/custom/{$name}": ["type:drupal-custom-module"],
        "themes/custom/{$name}": ["type:drupal-custom-theme"]
    }
},

"config":{
            "process-timeout": 1600
       },

Крім того, якщо це не працює, ви можете запустити встановлення композитора за межами SSH у вашій машині управління .

Це дозволить обійти будь-який час очікування на подію NFS і розпакувати Drupal в потрібному місці.


0

"drupal / core": "~ 8.0-beta14" означає будь-який випуск, більший за 8.0-beta14 і менше 9! Ви хочете видалити тильду, щоб заблокувати її до певного випуску. Потім обов’язково оновіть свій файл блокування, запустивши композитор, а в цільовій системі використовуйте встановлення композитора.

Простий спосіб почати - це створити базу коду за допомогою https://github.com/drupal-composer/drupal-project .

Коли нам потрібно оновити щось на зразок оновлення ядра, ви запускаєте локальний "композитор". Це оновить файл composer.lock.

Коли інші розробники витягують або в сценарії розгортання, ви запускаєте "встановити композитор", який використовує файл блокування.

Рядок у нашому composer.json для Drupal core:

"drupal/core": "~8.0",

Тильда () означає будь-який випуск у межах 8 числа (але не 9) .

Якщо ви хочете заблокувати його до певної версії, не слід використовувати тильду.

"drupal/core": "8.0-beta14",

потім запустіть локально "composer", скопіюйте файл composer.json та composer.lock, а після запуску бази коду запустіть "composer install" на інших установках.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.