You can now reuse field IDs in Picturepark which previously was not possible on the same schema or on child schemas after the field had been deleted. In order to do so, you see a badge on Settings in the Main Menu which leads to the Status Page where you find the new index for Content and List Items. There you can trigger the update of Content and List Items.

Picturepark now cleans up the data preventing the re-use of a field, but independent from the update of the schema. Therefore indexes are asynchronously updated once the editor deletes a Field that references other schemas or fields. The update on request might prevent deleting a ListItem because of a stale reference, but it makes the schema update a lot faster. The trigger point for this update is a manual start by the user after changing the schema configuration, indicated with a badge next to the settings menu.

This way, the admin controls when Content and List Items shall be updated, instead of updating all items after every change. The significant advantage is to be able to perform multiple changes to multiple schemas without waiting for an update of all items after each change. However, the drawback is that some Items may contain obsolete information until the update is triggered:

• The calculated value for a calculated string field that is not up to date (if its template changed in the schema).
• A reference to a Tagbox or a Relation to a Content Item that is no more in place, e.g., if the editor removed the Tagbox from the Layer and Content Items had this Layer, and multiple tags added.
• After the update by the admin, outdated items are up-to-date again, and the system cleans the ids of the removed fields so that it is possible to add again fields with previously taken ids.

The Status Page in the Settings in the Main Menu shows the state of Content and List Items: up-to-date, in progress, and outdated. For the outdated state, a button at the bottom "update" triggers the update. 

It is not required to do the update immediately after every edit to a schema, but the content authority should trigger an update after finishing the schema edits. Otherwise, the search may find Content Items by tags that are no longer available in their metadata profile.

The display pattern configuration on all types of schemas will result in an update to this status. An admin can start reindexing affected items after changing existing display patterns, which is also indicated via a badge in the main menu. The reindexing of all items in the platform is not automatically triggered after updating display patterns, to prevent waiting times for admins who are updating several display patterns at once. The admin can proactively start re-rendering after all changes are done.

This re-rendering is now handled via a dedicated service provider that can be deployed on a dedicated instance, to significantly improve performance on high-volume instances.

Bear in mind that the removal of a field does not affect the Display Pattern status, so a broken Display Pattern due to missing field values can not be detected at this point.

The Search Indices referring to the index in Elastic Search where all data is saved to. There are two indices:

1. RootListItemSearchIndex - this index holds all list items.
2. RootContentSearchIndex - this index holds all content items.

When you double-click to open you see the lists or virtual / file types contained. The index is always updated when field values change.