私たちが取り組んでいる Web サイトでは、サポートするかなり複雑なデザインがありました。そこで、各ページのすべてのコンテンツがコンポーネントで構成される戦略を選択しました。作成者は、見出し、リッチ テキスト ブロック、画像などのさまざまなコンポーネントを挿入できるため、ページを柔軟にレイアウトできます。これは、作成された複雑な設計をサポートできる唯一の方法でした。
この設定は、バージョニングと検索以外はうまく機能しています。ページがバージョン管理されている場合、ページ上のコンポーネントはバージョン管理されていません。項目が検索用に索引付けされている場合、ページ上のコンポーネントはページの一部として索引付けされていません。カスタム検索インデックスを使用して検索の問題を解決できる可能性があると考えていますが、バージョン管理の問題はもっと複雑に思えます。
他の誰かがこれらの問題に直面したか、解決策について考えていますか? Sitecore 7.5 を使用しています。
簡単な答えは、バージョン 8 がレンダリング フィールドにバージョン管理を追加するため、リリースされたらすぐにバージョン 8 にアップグレードすることです。
各項目のレンダリング パラメータでフィールドの内容を設定していると思いますか? その場合は、少し異なるアプローチを取ることをお勧めします。データソースを使用します。データを保持するいくつかのテンプレート (RichTextTemplate、SingleLineTextTemplate、ImageTemplate など) をすべて 1 つのフィールドで作成し、ページに見出しまたはリッチ テキスト ブロックを追加するときに、すべてのエディターにレンダリングをセットアップしてデータを作成することができます。ソース。
このようにして、すべてのコンテンツを適切にバージョン管理することができ、コンテンツとプレゼンテーションを分離しています。
ツリーを整理するために、すべてのコンテンツのアイテムの下に「Assets」フォルダーを使用します。
ツリーの例:
検索の問題は、次の投稿のように聞こえます: How to index sub-content in Sitecore with Lucene?
これは、計算フィールドを示唆しています。計算フィールドで、テンプレートがページであることを確認してから、そのページのすべてのレンダリングを取得します。それらを取得したら、レンダリング データソース アイテムを取得すると、データソース アイテムのフィールドのコンテンツを使用して大きな検索フィールドを作成できます。
これにより、カスタム アクセス レイヤーを使用して余分なインデックスを作成する必要がなくなります。すべて Sitecore API 内にとどまります。