反対のアイテムリストのEntityreferenceフィールドから参照アイテムを取得する方法は？ （後方参照）
コンテンツタイプAでEntityreferenceフィールドを使用すると、別のコンテンツタイプBから複数のアイテムを参照できます。ノードティーザーページまたはその他のビューリストでは、参照されたアイテムのサブリストとして、コンテンツタイプAのコンテンツアイテムの各行にそれらを追加でリストできます。しかし、コンテンツタイプBで別のEntityreferenceフィールドを使用せずに、逆に自動的に参照ソースを一覧表示するにはどうすればよいですか（不要な二重編集）。
例：車（コンテンツタイプA）が3つの異なる自動車サービスステーション（コンテンツタイプB）で修理されました。したがって、コンテンツタイプ「car」は、それらを追加するためのEntityreferenceフィールドを取得します（Bのアイテム）。サービスステーション（B）のリストを作成するときに、追加の後方参照フィールドやCERのような追加のモジュールなしで、車（A）のリストが自動的に修復され、データベースでの処理が不必要に複雑になるのを確認したいと思います。
注：基本的には、分類用語に期待される動作です。これはDrupal 8のEntityreferencesでもありますが、項目リストの両側から機能する組み込み機能がいくつかあるようです。
現時点では、SQLリクエストの重複を作成せずに、後方参照の問題を解決するためのオプションが2つ（編集：3）しかありません。
- 2番目のビューのコンテキストフィルターを介してノードタイプBを参照するタイプAノードのリストをネストするために ビューフィールドビュー を使用して、各アイテムnid（パフォーマンスの問題の可能性）をフィルターします。
- 両方のコンテンツタイプから2つのEntityreferenceフィールドを同期し、おそらくそれらを Rules で自動化し、ビューの後方参照リストに2番目のEntityreferenceフィールドを使用します。
- [〜＃〜] cer [〜＃〜] モジュールを使用して（私はあなたがノーと言ったのを知っています）、テストした後、あなたが望むことを知っているなら、このモジュールが現時点で最良のオプションだと思いますこの接続は「修正」に同期し、個別に変更されませんでした。
リストとネストされたリストが長い場合、最初にパフォーマンスに大きな影響があります。そして、それを補うために必要なキャッシングモジュールは、まだD8に対応していません。
ルールが常に完全に機能するとは限らないため、2番目に他の問題が発生する可能性があり、ルールがこのアプローチに必要なトリガーをサポートしているかどうかは100％わかりません。
編集：3番目は私の推奨事項です。周りのテストの後、私はそのシンプルさと動作保証についてかなり感銘を受けました。ルールを使用するほど柔軟ではありませんが、悲しいことに、ルールはots自身の物語です。ですから、もう一度試してみてください（CER）。