-
Notifications
You must be signed in to change notification settings - Fork 13
Dynamic Component Presentations
The use of Dynamic Component Presentations (DCPs) can complicate the approach to search indexing. The fundamental reason for this is that when you have DCPs which are added to the page as embedded component presentations, you can alter the contents of the page without republishing the page, just by republishing a DCP. This can quickly lead to the index data for a page being out of date or stale.
The easiest way to find an approach that works for a given implementation is to start with cases that are either not problematic, or have a reasonable workaround. If this covers a large percentage of the requirements for indexing, then we should be OK. There are lots of intricate and complex cases, however focusing on these makes no sense if they cover 1% of the pages requiring indexing.
In some cases, a DCP is not allowed to be added to a page and can only be published separately. Think of promotions which are shown on pages based on targeting logic, or events which are shown in a Calendar GUI. In this case, either the DCP should not be searchable (promotions), or should be searchable with specific functionality (for example calendar search) where the URL to link to and/or the content shown in the search results is determined by some application logic based on the type of content (for example /events/calendar?event=xyz). Either way it is not an issue. We ensure appropriate indexing TBBs are added to the Component Template if and only if it should be indexed, and everything will just work OK so long as our web application is aware of when the queries/search results might contain DCP type results, which should either be excluded, or have their URLs generated from the content type and DCP ID.
SDL Tridion provides the opportunity to reuse content across different pages by using different templates for the same component It is quite common to have the same component on landing/index and detail pages using different (and sometimes dynamic) Component Templates. However, if a user’s search results in a hit on that component content, we probably want to direct them directly to the detail page and not a landing/index page. So in this case, it seems logical to exclude all CTs other than the main details CT(s).
With the above case, it may be that the main details CT(s) are also dynamic. If there is a compelling reason for this, then we need to take care that when a component is published that this triggers an update of the index data for the page. This can either be done in one of two ways:
- Using some custom resolving – triggering a publish of the page when the DCP is published.
- Have some logic in the indexing TBBs for the details CTs, which instead of generating DCP index data, actually get a reference to the corresponding details page, and outputs index data for the page, thus overwriting the page entry in the index when published. The first approach is the most correct, but a little heavyweight on publishing (the whole idea of having such a DCP is to avoid publishing the page). The second approach could lead to problems if there were other components on the page which had been added/updated but not yet (re)published. This should be looked at on a case-by-case basis.
This leaves us with DCPs whose content should be indexed, and be searchable on multiple pages. If you have this scenario, these need to be looked at on a case-by-case basis to evaluate the best approach.