Sorry, we don't support your browser. Install a modern browser

Built-in "editorial attention" dashboard sections (to-do stats + recently edited)

On every content site I build, editors need the same two things on their Panel
dashboard, and I end up rebuilding them by hand each time:

A “to do” overview: content that still needs attention, images without
alt text, items without a cover image, items missing a required relation,
stale drafts. Ideally as stats tiles that turn green when there is nothing
left to do, with a linked list of the pages where the open work lives.
A “last edited” list: the five most recently modified pages across the
whole site, as a “where was I?” re-entry point.

The second one is already possible with a pages section and
query: site.index.sortBy("modified", "desc").limit(5), but you have to know
the query API to discover it. A ready-made section type (or a documented
recipe in the starter blueprints) would make it accessible to everyone.

The first one is where blueprint YAML genuinely runs out today:

The query language has no conditionals, so you cannot render “3” in a
warning color but “None – nothing to do” in a positive color. This needs a
custom site method plus a blueprint callback in a plugin.
A site-wide list of files missing alt text is not expressible at all,
because files sections are always scoped to a single parent.
Making the (potentially long) findings list collapsible requires raw HTML
through an info field.

Proposal: an optional, built-in section type (e.g. type: attention or
type: tasks) where you configure checks declaratively:

attention:
  type: attention
  checks:
    missing_alt:
      label: Images without alt text
      query: site.index(true).files.filterBy("type", "image").filterBy("alt", "")
    missing_cover:
      label: Articles without cover image
      query: page("blog").childrenAndDrafts.filterBy("cover", "")

Each check renders as a stat tile (count + theme based on count) plus an
expandable list of the affected pages, linked to their Panel views. Entirely
opt-in, so it stays out of the way of minimal setups.

Attached: a mockup of what this looks like on a real editorial dashboard
(currently built with a custom plugin + panel CSS).

4 days ago

To be honest, this sounds quite opinionated and specific for the core as section type. I could totally see this as plugin or even great cookbook recipe, as you also mentioned.

I have to correct one statement: “The query language has no conditional” - it actually has in v5. Switch over the more modern query runner (https://getkirby.com/docs/reference/system/options/query#runner - will become the default in Kirby 6) and then this works:

todo:
  type: stats
  reports:
    - label: Unpublished
      value: "{{ site.index.filterBy('status', 'unlisted').count }}"
      icon: page
      info: "{{site.index.filterBy('status', 'unlisted').count > 0 ? 'review & publish' : 'nothing to do'}}"
      theme: "{{site.index.filterBy('status', 'unlisted').count > 0 ? 'negative' : 'positive'}}"

(depending on your page count you might not want to run .index here three times, e.g. add a custom page method to add some caching, but to illustrate the conditional features of Kirby query language)

4 days ago

Thanks,

that’s a really useful correction. I didn’t realise the AST runner already handles conditionals in v5. I tested it against 5.5.0 and you’re right of course: with query.runner => DefaultRunner::class, a ternary in the theme and info fields resolves exactly as in your example, so the coloured stats tiles need no PHP at all. Good to know it becomes the default in v6.

And fair enough on it being too opinionated for a core section type. A plugin or a cookbook recipe makes maybe more sense, agreed.

One part the runner doesn’t cover as far as I know, though: the list every page or file that still needs attention side. So a site-wide list of images missing alt text isn’t expressible in a blueprint, because files sections are scoped to a single parent, so that still needs a custom section or method. But the conditional tiles plus a documented DefaultRunner recipe would already get most sites a long way, which might be the sweet spot rather than a dedicated core type.

Thanks again for the pointer.

3 days ago

Make a suggestion