Longform Content with CKEditor - separate field contents into "text blocks" and "entries blocks" so we can loop through them

[piotrpog]

Although this is related to ckeditor which has separate repository, i feel that ckeditor is such integral part of craft development that this discussion could be started there.

The problem:

Even if we include entries partials into ckeditor field, all that is returned by the field in the template is just a markup. This can cause some complications when trying to build layouts.
For example, consider standard approach of having "container" class wrapping your contents. Its around 1000px wide on desktop and centered in the middle of the viewport. If we output the text content into the container, all is fine. But if we include some partials into ckeditor that should stretch to the full screen width - they will be still enclosed in the container.

Another problem would be if we use something like tailwind prose class - this class adds default styles to rich tech content such as <p> or <ul> tags. But it can also mess up styling of partial components included inside ckeditor field.

Proposed solution:

Add some method to the ckeditor field that would return array - each position would be either text "block" or "block" containing the partial component html. Developer could just loop through them and decide what to put into the container class. This is how it works with Vizy plugin.

Hacky solution:

For now i have managed to solve this problem using Retcon plugin.

{% set htmlContent %}
<div class="text-editor__content">
    {{ block.b_textEditor }}
</div>
{% endset %}
{% set htmlContent = htmlContent|retconWrap( '.text-editor__content>*:not(section)', 'div' ) %}
{% set htmlContent = htmlContent|retconAttr( '.text-editor__content>*:not(section)', { 'class' : 'container' } ) %}
{{ htmlContent }}

In this example, i just wrap every first level html tag returned by ckeditor in div that has "container" class. I exclude <section> tag from these, as every partial component i use is wrapped in this tag.
Kinda ugly as now we have hundreds of containers, but works for now.

[brandonkelly]

Another way you could achieve that would be to wrap the entire contents in a container, and then have each partial template close the container first, and open a new one after outputting its partial content.

You could even have it based on a custom breakContainers _globals variable, so the partials only do it when instructed.

{% if entry.myCkeField|length %}
  {% set content %}
    {% set breakContainers = _globals.get('breakContainers') ?? false %}
    {% do _globals.set('breakContainers', true) %}
    <div class="container">
      {{ entry.myCkeField }}
    </div>
    {% do _globals.set('breakContainers', breakContainers) %} 
  {% endset %}

  {# output the contents, but with empty container divs removed #}
  {{ content|retconRemoveEmpty('div') }}
{% endif %}

Then from your partial templates:

{% if _globals.get('breakContainers') %}
  </div>
{% endif %}

... partial content ...

{% if _globals.get('breakContainers') %}
  <div class="container">
{% endif %}

[piotrpog]

That's a pretty good idea. However, as i understand, using _globals is right now the only way to pass variables to partial component? If we could loop through partial blocks and text blocks, we could just use a render method directly and pass variables to this method.

[brandonkelly]

Yeah not saying it’s the cleanest solution, but it’s something that would work today.

[piotrpog]

Do you think something like my proposed solution could be included in 5.2 or 5.3?

[brandonkelly]

Definitely not 5.2 which is already feature-locked and in beta.

The idea has come up before, and I haven’t figured out exactly how I’d want to solve it yet, but I’ll keep thinking about it.

[thupsi]

As for the layout part, there are ways to achieve what you describe with css grid. One way to go about it is detailed here. Though I definitely support your FR since it would allow more fine tuned control of the output.

[rynpsc]

For me what I really wanted from Craft was something like the Bard field in Statamic or Kirbys Block field i.e. a Matrix like API but a streamlined interface which gives the best of both worlds. I thought originally that was the plan for Craft with the talk of the use of something like TipTap and structured data.

The update to CKEditor is nice and can get you out of a hole but I don't think it's a complete solution. Hopefully something like Bard/Blocks is still on the cards 🤞

[brandonkelly]

Splitting rich text content across multiple fields within separate blocks/entries is a pretty terrible AX for longform content, which is why we did nested entries in CKEditor to begin with.

[mmikkel]

...this kind of veered into discussing UI/AX, but I think the crucial missing piece for a lot of folks is simply the ability to somehow be able to easily differentiate between "rich text" vs. nested entries when outputting CKEditor fields – in order to, for example, add different containers around, or class names to, the rich text parts and/or the nested entries.

I know that CKEditor content is stored as a single blob of HTML with nested entries inside in <craft-entry> tags; i.e. the content is not "structured" as such in the db. But, maybe it'd be feasible to add a method (ckeditorField.asArray() or similar?) to CKEditor fields that used regex or something on that HTML under the hood, and returned the content as an array of text and entry "nodes":

[
   {
      type: 'text',
      html: '<p>Look! I'm rich text!</p><p>I'm a different paragraph</p>'
   },
   {
      type: 'entry',
      html: '<article><h2>Nice nested entry</h2></article>'
   }
]

Something like that would make it possible to do something like this very easily:

{% for item in entry.ckeditorField.asArray() %}
    {% if item.type == 'text' %}
        <div class="wysiwyg">{{ item.html }}</div>
    {% else %}
        {{ item.html }}
    {% endif %}
{% endfor %}

[piotrpog]

Thats pretty much what i was thinking. Although for the nested entry positions, we could just have entry object instead of html, and developer could just run render() on it as needed. It would be also possible to pass some variables into entry template, as a parameter of render() method.
Should not be that hard to do, just run some regexp to separate raw field content into portions of html and portions containing reference to entry ids, which right now are by default replaced by rendered partial template.

[thupsi]

Splitting rich text content across multiple fields within separate blocks/entries is a pretty terrible AX for longform content, which is why we did nested entries in CKEditor to begin with.

I know why you did this, and I agree. I much prefer the new CKEditor for longform content from a purely UI/AX point of view.

[thupsi]

for the nested entry positions, we could just have entry object instead of html, and developer could just run render() on it as needed.

Yep, that sounds cleaner to me.

[brandonkelly]

Making this possible for CKEditor 4.1 (#241).

[piotrpog]

Awesome, thanks!

[brandonkelly]

CKEditor 4.1.0 is out with that change! (Requires Craft 5.2+.)

[christopherhealey]

Very pleased with this update, thanks for the speedy implementation Brandon!