MultiExcerpt Reporting Macro - summary overview of MultiExcerpts, their owner pages and includes


  1. Add a multiexcerpt reporting macro that generates a table that displays the following columns:

    1. The multiexcerpts residing in a space

    2. The pages they are on

    3. The pages that have Multiexcerpt Include macros that reference them

    4. When the page was last updated.

  2. This report macro could look similar to the Page Properties Report macro, with the columns being sortable.

  3. Customer requested options for this macro are:

    1. In Space: Accepts space keys, defaults to current space

    2. Filter by Label: Accepts page labels, defaults to no filter

    3. Columns to show: Drop-down list with choices

      1. Host page

      2. Page(s) with Multiexcerpt Include macro referencing the Multiexcerpt macro

      3. Last updated (preferably when the content within the multiexcerpt was updated, vs. when the page was updated)

  4. References:

The cloud version of this request is at

Freshdesk Tickets

#57059 ( - Question on reporting of where MultiExcerpts are used?

Create a Support Ticket


Andre Pliewischkies
November 21, 2019, 9:58 PM

Great! This description looks much like a housekeeping overview for space admins.

Let me add two things which came to my mind:

  1. The similarity to the page property report initially intended to get a content table: a table of chosen multiexcerpt names displaying the content of these excerpts much like the page property report.

  2. allow to use any cql-statement for filtering as different organisations use different data architectures. But as the page property report requires to use a label it forces me to somehow make sure that e.g. project pages always carry both: label and metadataset which is annoying as any user can remove one of them anytime…
    For example we (DLR) heavily use metadatasets (from the Communardo Plugin) replacing labels which represent the type of content: Metadataset.project instead of labels named project, metadataset.glossary instead label glossary, etc. As metadatasets can hold certain metadatafields, defined attributes for each apge-content-type can be qualified: projects have descriptions, partners, cost units etc. and glossaries have translations, synonyms, abbreveations, target groups etc. The architecture behind is that labels should describe only topics while page-content-types in metadatasets deliver additional metadata structures relevant to the specific content. Target groups for the content and page-content-types should be defined in another way.





Stacy Coakley