Support filters for template strings

[hanneskuettner]

Is your feature request related to a problem? Please describe.

I am looking for a way to apply custom transformations on fields in template string {{ someField | filter }} in various location in the CMS.

This would allow many cool things for usability and customizability.

Right now it is impossible to format a custom date field in for example the summary field. Or transform text to uppercase.

Describe the solution you'd like

I am proposing a filter mechanic similar to many other templating systems that would allow users (and the core CMS itself) to register filters that are applied on string templates similar to this:

// register filters
CMS.registerStringTemplateFilter('myFilter', whateverFunction);
CMS.registerStringTemplateFilter('date', (d, format) => moment(d).format(format));

{{ someField | myFilter }} will be transformed internally to myFilter(someField) and the output of that function used instead of the some_field value.

{{ publishDate | date('YYYY-MM-DD') }} will be transformed to date(publishDate, 'YYYY-MM-DD') and its output used.

The convention would be to provide the field value as first parameter and all other parameters given in the filter itself as the next parameters.

The CMS core could provide filters like date, upper, lower.

Describe alternatives you've considered

Additional context

I don't know and can't really justify any good argument about the performance implications of this if it's for example used in the summary field of a large collection ¯\_(ツ)_/¯.

[erezrokah]

Keeping this open until we implement dynamic filters

[robsonsobral]

Hi, pals!

May I ask for one more filter?

| default could be useful. {{linkTitle | default title}}

Thank you!

[erezrokah]

@robsonsobral, this would make a good first contribution

[robsonsobral]

Really, @erezrokah? Cool!

I gonna take a look. Unfortunately, I know nothing about React. It's easier to make a disaster than a feature.

[erezrokah]

Unfortunately, I know nothing about React. It's easier to make a disaster than a feature.

The relevant code is here, I don't think you'd need a lot of React experience for it: https://github.com/netlify/netlify-cms/blob/f528186594fdb1947f21faee7461d08a4f7b13d3/packages/netlify-cms-lib-widgets/src/stringTemplate.ts#L126

Let me know if there is anything else I can do to support.

[pmpinto]

Pasting a previous issue comment here as requested in the original issue.

---

Is your feature request related to a problem? Please describe. I have a boolean field that I want to be able to glance at on a list. So I do:

summary: '{{title}} {{is_featured}}'

And I get a list like this:

Item 1 true
Item 2 true
Item 3
Item 4 true
Item 5

Describe the solution you'd like I would like to be able to control the text that gets outputted when the value of a boolean is true. For instance:

summary: '{{title}} {{is_featured | true: "🌟"}}'

Describe alternatives you've considered The usual ternary operator would be fine too:

summary: '{{title}} {{is_featured ? "🌟" : ""}}'

So the list would end up like:

Item 1 🌟
Item 2 🌟
Item 3
Item 4 🌟
Item 5

[LorenzBischof]

Maybe also something like: is_featured | "🌟" if true, which would allow state | "🌟" if "featured" It would also be cool if the filters could be chained (not sure if this is already possible): is_featured | "★" if true | "☆" if false

[KoljaTM]

Added the suggested filters as default() and choice()

[michaelfig]

@erezrokah I'd like to make an attempt at dynamic filters.

For my use case, I'd like to run user-added filters as part of preprocessing all the pages on my site. ISTR that you had deliberately disabled filters when the processor is given. Would it make sense to allow a specific filter to declare that it should be used even for processors?

[erezrokah]

For my use case, I'd like to run user-added filters as part of preprocessing all the pages on my site. ISTR that you had deliberately disabled filters when the processor is given. Would it make sense to allow a specific filter to declare that it should be used even for processors?

Ha, you have better memory than me as I don't the remember the context for that decision.

I say go ahead and suggest a API for registering dynamic filters and we can discuss implementation.