私はようやくDrupal 8を真剣に検討し始め、特に構成管理に興味があります。少し問題があるかもしれない何かに遭遇しました。それはカスタムブロックコンテンツに関するものです。
構成管理システムがブロック構成(地域、テーマ、重み、可視性など)をエクスポートできることがわかりますが、実際のブロックの内容は構成エクスポートで取得されないため、これは合理的で理解できます。
そのブロック構成を本番サイトにインポートすると、ブロック構成が作成され、保留メッセージが配置され、ブロックが壊れているか欠落していることが報告されます。明らかに、ブロックコンテンツは運用サーバーに存在しません。
カスタムブロックを開発/ステージングサーバーから本番サーバーに移行するにはどうすればよいですか? Drupal 8のブロックはノードのようなフィールド化可能なエンティティであるため、同じ方法で移行する必要があることを理解しています。Drupal = 8しかし、これはDrupal 6および7サイトからDrupal 8ではなくDrupal = 8からDrupal 8サイト。
この問題は特に、ビューなどの他のモジュールによって生成されたブロックが構成として明らかに移行するため、カスタムブロックに関するものです。
ここで言及していない別の答えは、コアの「カスタムブロック」設定とほぼ同じである Simple Block モジュールを使用することですが、コンテンツ+構成の奇妙なハイブリッドではなく、すべてのブロック設定とコンテンツが構成に保存され、クリーンにエクスポートおよびインポートできます。
Drupal 8コア: カスタムブロックを適切にエクスポートおよびインポートできない の詳細については、参照してください。
これを解決する寄付モジュールを公開したところです。基本的に、モジュールは、カスタムブロック(コンテンツブロック)をラップする構成(固定ブロック)に基づいたタイプのブロックを提供します。コンテンツブロックが存在しない場合は、デフォルトのコンテンツで作成されるか、デフォルトのコンテンツが設定されていない場合は空になります。すべてがUIを介して行われ、特別なファイルやカスタムモジュールは必要ありません。
私はそれをFixed block contentと名付け、以下で公開されています:
開発の一部として追加されたコンテンツをプッシュしてライブに維持するためのもう1つのアプローチは、コンテンツをエクスポートするために Default Content モジュールを使用することです。これは、コンテンツがインストールプロファイルの「コンテンツ」フォルダーにエクスポートされるように構築されており、モジュールが有効になっている場合は、サイトのインストール時にコンテンツを自動的に取り込みますが、一度に1つのアイテムをインポートすることもできます。更新フックなど、example.installまたはexample.profileに以下のコードを含めます。
<?php
/**
* Import a piece of content exported by default content module.
*/
function example_import_default_content($path_to_content_json) {
list($entity_type_id, $filename) = explode('/', $path_to_content_json);
$p = drupal_get_path('profile', 'guts');
$encoded_content = file_get_contents($p . '/content/' . $path_to_content_json);
$serializer = \Drupal::service('serializer');
$content = $serializer->decode($encoded_content, 'hal_json');
global $base_url;
$url = $base_url . base_path();
$content['_links']['type']['href'] = str_replace('http://drupal.org/', $url, $content['_links']['type']['href']);
$contents = $serializer->encode($content, 'hal_json');
$class = 'Drupal\\' . $entity_type_id . '\Entity\\' . str_replace(' ', '', ucwords(str_replace('_', ' ', $entity_type_id)));
$entity = $serializer->deserialize($contents, $class, 'hal_json', array('request_method' => 'POST'));
$entity->enforceIsNew(TRUE);
$entity->save();
}
IDが8のカスタムブロックをエクスポートします。
drush dcer block_content 8
(設定しない場合 Drush設定でプロファイルパスを設定します 上で指定する必要があります。)
そして、結果のエクスポートをexample.installファイルで次のように使用します。
<?php
/**
* Add the footer block content.
*
* Implements hook_update_N().
*/
function example_update_8001() {
example_import_default_content('block_content/136efd63-021e-42ea-8202-8b97305cc07f.json');
}
同じ問題があり、実際にはソリューションではなく、追加のみです。共同開発では、リポジトリからプルしてすべての構成をリセットするステージングサーバーを使用しています。これは、ブロック構成が自動的にリセットされていることを意味し、そのサーバーに直接「コンテンツ」と見なすブロックを配置することはできません。
Drush config-export syncを使用するのは簡単ですが、実行した内容を正確に把握し、構成の変更がデプロイ用であることを確認できます。しかし、Drupalは、ブロックが構成であることを決定します(ブロックのコンテンツはコンテンツとして扱われることは明らかですが)。したがって、これは設計上、壊れているようです。
時間を考えると、最も実用的な解決策はブロック関連のymlファイルを.gitignoreに追加することです。
ブロックはコンテンツと非常に絡み合っているため、複数の環境間でブロック構成を同期することの強力な利点があるかどうかはわかりません。
これは、タイトル/ボディ(コンテンツ)を持たないymlファイルから新しいブロックが作成されているため、「壊れている/見つからない」というメッセージが表示されるためです。
開発のblock_contentテーブルのUUID(両方の場所でブロックを作成したい場合は、マシン名が一致することを確認してください...)を作成しようとすることができます(他の関係ではエンティティを使用しているようです) id)。次に、構成の同期を実行すると、ymlファイルの「ビューの違い」を確認できます。本番のUUIDなどに一致させるには、devで他に何を変更する必要があるかを確認できます。これは機能しましたが、このプロセスを実行するか、block_content、block_content__body、block_content_field_dataを使用して何らかのデータベースブロック同期を自分で作成しない限り、コード内のすべてのブロック構成を無視するのが最も簡単です。
あまりエレガントではありませんが、ブロック構成をコード内に保持できる可能性があります。それ以外の場合、configを使用してブロックを展開し続けると、それらは常に「壊れているか欠落しています」。
別の ブログ投稿 は、ライブ環境でカスタムブロックを作成するが、配置しないことを提案しています。データベースをdevに同期した後、カスタムブロックを構成し、構成をエクスポートできます。これは、プレースメントのライブインポートにすでに存在するため、可能です。
これを処理する最良の方法は次のようになると思います:
これは私が普段使用しているもので、個人的に使用しています。ただし、ブロックのコンテンツのみと比較して、データベース全体が同期されます。
Structure Sync モジュールをお試しください。
Structure syncは、構成と見なすこともできるコンテンツを同期するためのDrushコマンドと管理インターフェイス画面を提供します。メニュー項目、カスタムブロック、分類用語を含みます。
手順:
私もわかりませんが、解決策が見つからなかった場合は、このモジュール https://www.drupal.org/project/deploy を参照してください。率直に言って、PushブロックをDEVからPRODにデプロイできるかどうか覚えていません。