web-dev-qa-db-ja.com

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

composerを管理するためにDrupal 8の依存関係を使用したいのですが、適切なコアアップデートワークフローが何であるかわかりません。現在、コアを最新のベータリリースに更新するために急いでくださいが、composer.jsonファイルにもいくつかの依存関係があるため、更新後にcomposer installを使用して、すべてのcontribベンダー依存関係をインストールします。 composer installはコアディレクトリの一部のファイルを上書きしますが、コアを最新バージョンに更新しただけです。

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

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

drush8updatingcomposer
16
rreiss

プロジェクトのベースとして drupal-composer/drupal-project を使用していると思います。そうでない場合は、そのプロジェクトを見て、自分のプロジェクトと比較してください。

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

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

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

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

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

11
greg_1_anderson

以下は、パッチリリース8.4.x> 8.4.yでは問題ありませんが、マイナーリリース8.4では問題です。 x> 8.5.x。以下のUPDATE 3に移動して、マイナーリリース更新の「答え」だと思います。

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

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

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

"require": {
"drupal/core": "^8.4"
},

ない

"replace": {
"drupal/core": "^8.4"
},

「drupal/core」がreplaceセクションにある場合は、requireセクションに移動して、replaceセクションを削除します。 replaceセクションに他のエントリがある場合は、replaceセクション全体ではなく「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のcomposer updateでエラーが発生した場合は、通常、ベンダーフォルダー内のバージョンの問題が原因です。

これはそのような問題に対処するための素晴らしい投稿です： https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update とJeffの他の2を読んでくださいDrupalおよびComposerに関する投稿を参照してください。

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に到達すると、8.4.3から8.4.6の場合と同じように、8.5.0から8.5.1にcomposer update drupal/core --with-dependenciesが正常に機能しました。

「答え」はベンダーフォルダーと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 General）によってバックアップされています： https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update （ "私がサポートで働いているときに私が見つけたものの1つは、モジュールとコアのバージョンをロックダウンすることは良い考えです。さまざまなプラグインのうち、正しく動作したくないものさえあります。」

ちなみに、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をデプロイするたびにcomposer install。より通常の方法でデプロイする場合、上記のものすべてをgitリポジトリにコミットする必要があります。そうしないと、サーバーにデプロイされません[1]で、そのものがすべて必要です。 Drupalを実行します。

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

2
Richard Hood

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

composerは、特にローカルVMで実行する場合、実行する必要があります。composer install composerエラーが発生する可能性があります：

 [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
       },

また、それが機能しない場合は、composer install VMのSSHの外部からを実行できます。

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

1
BigEd

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

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

楽しい ：）

1
Eyal

「drupal/core」：「〜8.0-beta14」は、8.0-beta14より大きく9未満のリリースを意味します。チルダを削除して、特定のリリースにロックする必要があります。次に、composer upを実行してロックファイルを更新し、ターゲットシステムで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」を実行します。

0
oknate