正しい作曲家ベースのコア更新ワークフローとは何ですか？

composerを使用してDrupal 8の依存関係を管理したいのですが、正しいコアアップデートワークフローが何であるかはわかりません。現時点では、drushを使用してコアを最新のベータリリースに更新していますが、composer.jsonファイルにも依存関係があるため、更新後にcomposer installを使用してcontribベンダーの依存関係をすべてインストールしています。composer installコアを最新バージョンに更新したばかりですが、実行するとコアディレクトリの一部のファイルが上書きされるようです。

また、composer.jsonファイルを手動で編集し、「drupal / core」行を特定のベータリリース（例：）に置き換えようとしました"drupal/core": "~8.0-beta14",が、それでもコアディレクトリ内のファイルは上書きされます。

適切なワークフローとは何ですか？

私はあなたがあなたのプロジェクトの基礎としてdrupal-composer / drupal-projectを使用していると思います。そうでない場合は、そのプロジェクトを見て、あなたのプロジェクトと比較してください。

また、Drupal 8の依存関係を管理するためにcomposerを使用したいとおっしゃっていましたので、contribモジュールを経由composer require drupal/develではなく経由して選択したと思いますdrush dl devel。

これらすべてを実行している場合は、composer updateDrupalコアとすべてのcontribモジュールの更新に使用する必要があります。composer.lockファイルを保持している限りcomposer install、依存関係のバージョンを変更しないでください。まったく使用drush pm-updateしないでください。coreこのディレクトリはComposerによって管理されているため、ディレクトリ内のファイルが更新されているかどうかは関係ありません。希望する場合はできますが、コンポーザーが管理するディレクトリをリポジトリにコミットしない方が良いでしょう。

もちろん、Drupalコアまたはモジュールを置き換えるdrush updatedbたびに実行する必要がありcomposer updateます。

開発バージョンの取得を回避するには、Composer安定性フラグを使用してcomposer.jsonファイルで最小安定性を「ベータ」に設定します。

drupal-composer / drupal-projectを使用してサイトを管理している場合、README.txt、.htaccess、index.htmlなどのルートレベルのファイルはすべてプロジェクトに所有されます。つまり、gitリポジトリにチェックインする必要があります。Composerはそれらを更新しません。変更された場合は、自分で更新する必要があります。これらのファイルはめったに変更されませんが、drupal-composer / drupal-projectにはこれらのファイルを更新するスクリプトがあります。

パッチリリース8.4.x> 8.4.yでは問題ありませんが、マイナーリリース8.4.x> 8.5.xでは問題ありません。マイナーリリースアップデートの「答え」と思われるものについては、以下のUPDATE 3にジャンプしてください。

1- .htaccess、robots.txtなど、変更したDrupalに付属するファイルをバックアップします（最も一般的に変更されるのは2つです）。

2- [ロックファイルの削除が間違っていると言われました。以下の更新を参照してください] composer.lockファイルを削除します（サイトの最上位フォルダーにあります）。これは手順5で再作成されます。

3- composer.json （サイトの最上位フォルダーにあります）を確認し、「drupal：core」がreplaceセクションではなくrequireセクションにあることを確認します。

"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にアクセスして更新を実行し、次にadmin / config / development / performanceに移動して[すべてのキャッシュをクリア]ボタンをクリックします。

7-最初のステップでファイルをバックアップした場合（.htaccess、robots.txt）、それらを元に戻します。ただし、Drupalがそれらのファイルを更新したかどうかを確認し、それらの変更を自分のファイルに追加してください。

完了

手順5の作曲家の更新でエラーが発生した場合は、通常、ベンダーフォルダー内のバージョンの問題が原因です。

これは、このような問題に対処するのに最適な投稿です。https： //www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-updateにアクセスし、DrupalおよびComposerに関する他の2つの投稿を読んで入手してください。それに関するより多くの知識。

Twitterの2人から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].

Jeff Geerlingによるこの投稿は、同様の問題に対処していますが、これまでのところ私には運がありません：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モジュールを実行し、コアとともにモジュールを更新します。または、モジュールのバージョンcomposer.jsonを更新したくない場合はロックダウンします。

Drupal Slackのある人は、「Composerの全体的な哲学は、できるだけ頻繁にパッケージを更新する必要があるということです」と述べています。パッケージには、私が思うモジュールが含まれています。だから私は推測するに理にかなっています。

8.4.6から8.5.0に移行すると、composer update drupal/core --with-dependencies8.4.3から8.4.6の場合と同様に、8.5.0から8.5.1に移行するのに問題なく機能しました。

私は「答え」はベンダーフォルダとcomposer.lockファイルを削除してから使用composer updateすることであり、composer.jsonファイルの依存関係のバージョン番号があなたが望むものであることを単に確認すべきだと結論付け始めています。保持したいモジュールのバージョンを管理したり、更新を許可したりすることはそれほど大したことではありませんcomposer.json。

例えば：

"drupal/admin_toolbar": "1.18", 1.18に固執することを意味します

"drupal/admin_toolbar": "^1.18", は先に進んでアップデートすることを意味しますが、1.x（2.xではありません）

：これは、この記事にコメント（一般的な田舎者）によってバックアップされhttps://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update 「私がきたことの一つ私がサポートしているのは、モジュールとコアのバージョンをロックダウンすることをお勧めします。そのため、さまざまなプラグインの一部が正しく動作したくない場合もあるため、必要なときにそれをサーモヌークできます。」

ちなみに、composer.lockファイルはcomposer update（composer installファイルをロックする場所とは対照的に）吹き飛ばされるため、役に立ちません。

実行composer install予定：

• composer.lockが存在するかどうかを確認します
• そうでない場合は、を実行し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。私はそれを使用しましたが、問題ありませんが、ComposerをDrupalで使用するための要件ではありません。名前に由来するような「音」の一種であるため、混乱を招きます。Drupal 8を初めて使用したとき、それが必要だと思ったので、それを使って最初のD8サイトを構築しました。

Drupalの「バージョン」には、プロジェクトの最上位フォルダーではなく、/ webフォルダーにdocrootがあります。また、通常のDrupalと比較して、.gitignoreに追加されたものがあります：

/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/

したがって、このバージョンのDrupalは、コンポーザーインストールを使用して、デプロイごとにDrupalの新しいビルドを実行するために継続的な統合を使用しているサイト向けです。より通常の方法でデプロイする場合、明らかに上記のすべてをgitリポジトリにコミットする必要があります。コミットしないと、サーバーにデプロイされません[1]。

[1] gitがデプロイに関係している場合-SFTPでデプロイする場合、これを無視します。

packagist.orgのdrupal / coreパッケージを使用すると、composerを介してコア、contribモジュール（、テーマ、プロファイル）およびその他のベンダーを実際に管理できます。

ルートディレクトリに次のファイルをセットアップして実行しました 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

楽しい ：）

はい、Drupalコアを作曲家で管理できます。ただし、注意すべき点がいくつかあります。

特にローカルVMで実行している場合は、コンポーザーが実行する必要があるアイテムの数が多いため、おそらくタイムアウトが発生します。実行composer installすると、おそらくcomposerエラーが発生します：

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

必ずrequireを使用してください

{
  "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
       },

それがうまくいかない場合は、composer installを実行することもできます は、VMの外部SSHからをます。

これにより、NFS共有のタイムアウトがバイパスされ、Drupalが適切な場所に展開されます。

「drupal / core」：「〜8.0-beta14」は、8.0-beta14より大きく9未満のリリースを意味します！チルダを削除して、特定のリリースにロックすることができます。次に、composerを実行してロックファイルを更新し、ターゲットシステムでcomposer installを使用します。

開始する簡単な方法は、https：//github.com/drupal-composer/drupal-projectを使用してコードベースを構築することですです。

コアのアップグレードなどを更新する必要がある場合は、ローカルで「composer up」を実行します。これによりcomposer.lockファイルが更新されます。

他の開発者がプルダウンするとき、またはデプロイメントスクリプトで、ロックファイルを使用する「composer install」を実行します。

Drupalコア用のcomposer.jsonの行は次のとおりです。

"drupal/core": "~8.0",

チルダ（）は、8の数字（ただし9ではない）内のリリースを意味します。

特定のバージョンにロックする場合は、チルダを使用しないでください。

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

次に、「composer up」をローカルで実行し、composer.jsonおよびcomposer.lockファイルをコミットし、コードベースをプルダウンした後、他のインストールで「composer install」を実行します。