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

Add Heading (and lists) to writer field#255

I understand the point that the writer should be as minimalistic text editor as possible. However, the ability to create headings should still be part of the writer field in my opinion.

On the one hand I still consider a heading as a part of the unit text and not necessarily as a separated content type, on the other hand this separation makes writing text incredibly complicated. If my customers have written a text and later want to add a subheading in between two paragraphs, they have to split the existing text into two blocks inside the blocks field, just to add another block for the heading between the two text parts.

From the developer’s point of view, I am also forced to use the rather complex Blocks Field in places where I really only want to display text.

My preferred solution would be that the writer works exactly like the existing textarea field, but omits the Markdown and Kirbytext hussle and generates a reasonable preview, like the current writer.

a month ago
2

I understand where you are coming from but this would somehow defeat the purpose of the blocks. Like now you can filter them by type, move individual parts around etc. Easily create ToCs without having to parse the field content. You would loose this way of working with blocks if suddenly all this stuff was in a single block type again.

a month ago
1

Well, I think Kirby should not be too oppinionated about how granually the different page blocks should in the end. Comming from my kirby builder background I see these blocks more as entirely separate content sections. Like having a text section (including subheadings and lists), image galleries, CTA sections, testimonials etc. . Having to split this text section into all the different markup types as separate blocks feels a bit too unhandy for me. A simple option in the writer field could solve this issue for me. And it would also make this field be more independent from the blocks field.

a month ago
4

I also find the new blocks to be a regression of the editing experience regarding text-heavy content.
Wouldn’t it be possible to reintroduce the editor plugin as a standalone block (maybe only text-related functionality)? So editors/devs can choose how to implement things according to their needs.

For instance, so find the number of clicks necessary to insert a heading Block and change it to h3, for example, a little annoying.

a month ago
4

Regarding long-form text editing I also vote for a two way strategy here (Writer and Blocks field) and would like to use a heading/lists option in the Writer field. I usually have to deal with a lot of content, where the Writer field is the perfect solution and would love to give my editors the most easy editing experience for their text.

a month ago

Honestly this would be such a fork i don’t think its a good idea. You would have two ways to add headings i will just be confusing.

Considering the amount of clicks… you can have your heading 1 block heading 2 block etc. And then the amount of clicks is the same and the way of adding content is the same.

a month ago

Just to be clear, with the two way strategy I meant having both options available from which the developer can choose from. Extended Writer or Blocks with a simple Writer.
Both ways at the same time are really not needed, this is indeed a problem, if the two are mixed together.
But maybe this is not a big issue, if the extended Headings are just an optional thing.

a month ago

Maybe the Writer could auto-detect if it’s in Blocks. If it is, it will automatically have the current behavior of only inline tag support. If it’s standalone, the default could be heading and list support with the option to disable that.

I’m just not 100 % sure if that would be confusing from a developer perspective.

a month ago

Why couldn’t the heading, text and list blocks just all use the writer field but with different configurations? That would, of course, require the writerfield to

  1. be able to handle text, lists and headings
  2. be able to be configured what content types it supports

The configuration for these blocks would then look somewhat like this:

fields:
  blocks:
    type: blocks
    fieldsets:
      heading:
        type: writer
        contenttypes:
          - heading
      text:
        type: writer
        contenttypes:
          - text
      list:
        type: writer
        contenttypes:
          - list

If I wanted to use the writer field to its full extend outside these predefined blocks, I could configure the field like this;

fields:
  myDreamWriterField:
    type: writer
    contenttypes:
      - heading
      - text
      - list
a month ago
3

I like that idea a lot! The existing heading and list blocks as well as the list field would then become simple aliases for the respective writer content types.

a month ago
1

A rough idea for a configuration syntax to make it even more flexible:

fields:
  writer:
    type: writer
    elements:
      - h3
      - h4
      - heading (= alias for h1 to h6)
      - ul
      - ol
      - list (= alias for ul and ol)
      - p
a month ago
2

I think the kirby way would be something like this:

fields:
  writer:
    type: writer
    elements:
      - h3
      - h4
      - heading # (Option 1) if you want all heading levels
      heading: # (Option 2) if you want to dive in and configure it in detail
        levels:
          - h2
          - h3
      ...
a month ago
1

My client’s find markdown to be intimidating. They find composing an article with blocks laborous. This feature, if implemented, would resolve the only gripe I’ve ever had with Kirby since day one. And we’re not asking to get too complicated with images or files, just the addition of headers and lists to the existing writer marks. Look what happened when a client of mine copied content into the writer field. See attached. Interesting.

a month ago
3
Changed the status to
Planned
a month ago
4

I’m changing the status to Planned to make sure we don’t forget about this. We may need to discuss this some more though.
@Bastian What do you think about it?

a month ago
1