Remove Liquid support for Html/Markdown Field/Part

[BenedekFarkas]

Due to the lack of support in WYSIWYG editors mixing those different syntaxes and it's a feature for power users/admins, not just content editors. Use Liquid Part instead.

The relevant files to change are the same as in #18802.

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[MikeKry]

Would you like to remove Liquid support in HTML fields completely, or would there still be an option to render Liquid as proposed in #18802? Does this change also include shortcodes?

If Liquid support were to be removed completely, this would be a major breaking change that would effectively block updates for our older solutions. Currently, there is no migration tool available to update all existing content in HtmlFields, which could leave many users unable to upgrade.

[BenedekFarkas]

#18802 is about surfacing the setting (to enable/disable Liquid rendering) correctly, but the plan now is to remove it completely for HTML and Markdown Part/Fields.

If Liquid support were to be removed completely, this would be a major breaking change that would effectively block updates for our older solutions.

We are taking that into consideration!
This might be a silly question, but wouldn't simply migrating the content of Html Field into a Liquid one yield the same output?
Automating that would be fairly simple.

[MikeKry]

A database-level migration could theoretically be possible. However, there is currently no standalone Liquid field (only LiquidPart), so everything depends on future implementation.

In addition, LiquidPart/Field does not currently have GraphQL support. Introducing it could lead to a breaking change—HtmlField exposes a nested Html property in GraphQL, which would likely need to be renamed to Liquid for LiquidPart/Field. That would require updates across all affected GraphQL queries and views.

While this could be implemented, it is unclear to me what the concrete benefits would be and whether they would outweigh the effort required to update existing projects. I am also not fully convinced by the argument that this is primarily for power users. In our experience, there are many real-world scenarios where clients actively use Liquid themselves when editing websites.

Another consideration is that we use HtmlField, for example, for email templates, where Liquid is used to populate user-specific data. In this context, HtmlField makes sense because it combines HTML markup with Liquid templating.

I do appreciate the improvement introduced in #18802, which provides a way to disable Liquid where it is not needed. However, I would not recommend removing Liquid support entirely from HtmlField - not sure about MarkdownField as we do not use this one.

[BenedekFarkas]

I see!

IMO it's weird indeed for MD to support Liquid, so I'm OK with getting rid of that (unless it proves to be useful).

As for HTML, that seems much more legit and you have a strong case for it, especially regarding GraphQL.
BTW did you customize the editor experience in any way?