The basic idea behind completeness checks of CMS objects is to deliver a control tool to measure possible pain points. By doing so, it brings problems to light that otherwise would have been undetected. Two things will be described in this text:
The object validation framework provides the foundation necessary to perform completeness checks for all CMS objects (i.e. Pages, Page Variants, Components, Page/Component Templates and Includes).
Possible problems collected per CMS object do not yet have any influence on the CMS object in terms of its operational state or function. For instance, a page containing no visible page variant at a certain time can still be staged, published or exported. Problems are merely collected as is and do not have any consequences.
In principle, the creation of a new CMS object can leave mandatory configuration parameters without any value. Some customers may not want to let CMS instances with missing parameter values be part of further processing (i.e. rendering, publishing etc.). The decision concerning which configuration parameter is mandatory and which is optional must be made based on the model artifact (=development time) that defines the parameter instance.
The following kinds of CMS instances must be part of the input set processed by this rule:
Page or component templates are not part of the input set because their configuration parameter values are only applied (during rendering) when there is no child-component or child-page variant specific value. The problem of a missing value of a mandatory configuration parameter is therefore virtually inherited to the leaf node of a pagelet inheritance tree (also known as: component or page variant).
The definition of a missing configuration parameter value is that the invocation of
ParameterContainerOverloadingInfo.resolveConfigurationParameterValue(String,LocaleInformation) will return a null reference. A check like this must be done for every mandatory configuration parameter that exists in a repository domain.
The basic problem is that, for a given time frame, Pages/Includes/Slots might have time periods where they either hold no or only unpublished / hidden components/page variants assigned to them. This defines them as empty during those time periods. This rule is to identify all time periods for all pages/includes/slots within a given validation context where they are either filled or empty.
An example of an empty slot can be seen in the figure below. The error marks represent those time periods where the slot is empty.
The slots / placeholders of the following content elements (pagelets) will be inspected:
The following types of pagelet entry points will be inspected for emptiness:
Gaps found in slots / placeholders are only reported locally for the directly affected Page Variant / Component / Page Template / Component Template. These problems are not propagated to any other indirectly affected items where this item is part of a composition path or content template inheritance chain.
The UI consists of three different views showing statistical information about reported problems of the above rules.
This overview just contains the numbers of how many CMS objects are available in the selected channel or organization master. Depending on the type of staging environment in which the application server is running, users can update that information with a click on the 'Update' button. For application servers that are part of a live system the update action may have a bad impact on the system's average response time or throughput. Therefore object statistic recalculation in the content area along with other areas only shows the 'Update' button if the server is part of the editing system (
If this does not suit your needs, there is always the possibility to schedule the job 'Update Shop Statistics' in the SMC.
The problems reported by the two rules can be exclusively switched on and off by the filtered search. Along with other data a filter can be configured to reduce the number of objects for which problems have been reported. As slots and placeholders do not have any visual representation in this overview, the produced validation results are shown in the context of the Component / Page Variant / Component Template / Page Template they belong to. The same applies to View Contexts which contain other Pages or Includes. Any problem reported for them will be visible in the context of the View Context they belong to.
Following a link in the above problem statistic will take you to the details of the selected CMS object type (Page, Include, Component etc.).
The number of CMS objects displayed in this detail view must be equal to the number shown in the previous problem statistic view. In the last column all problems reported for the CMS object will be mentioned. You can search CMS objects by ID or Name. Or you can search by problem type and language. Clicking on the mentioned problem will take you to the CMS object editing area where the problem is located. Leaving you with the possibility to fix the problem and safe your changes. After that the reported problem will disappear from the overview or details listing.