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.

3 months ago
4

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.

3 months 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.

3 months ago
6

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.

3 months ago
5

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.

3 months 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.

3 months 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.

3 months 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.

3 months ago

Waiting for this feature so much. For example, now client sent large article in word with 20 headings and lists, and it’s so much time to add everyting separately. I just want to paste it.

2 months ago
4

I love the separation of block types in layout pagetypes and I think that it would make sense to add headings and lists to the writer field for pages with much text.

a month ago

This was the one complaint a recent client had - they were copying and pasting in long artciels and not thrilled to have to add blocks for headers, which can be quite a fiddly process in a large doc.

6 days ago
?

In 98% lists are embedded and a part of one textblock. And you define it as a list, while you write. While a headline can be set over a video, code, image etc, a list mostly doesn’t stays alone. Thats why (I think) the list is better in the writer-field.

5 days ago

Interestingly, the writer field already supports list and heading nodes, even if there is no way to add them unless you write them in Markdown.

However, the old Editor plugin had an import option that automatically created the needed block types from text. This is a feature I find missing in the current blocks field implementation. In a Layout field it should probably create one layout with all blocks from such imported text. Such an importer would probably solve half of the issues mentioned here.

5 days ago

Yes, the option for lists and headings seems to be still sleeping in the code of the Writer. I also saw that when I tried to build my own solution based on it.

To your other point: I really think that dividing the text sections (hadings, paragraphs, lists) into different blocks causes more problems than it solves. With simple cut & paste I already have a best practice to move these text components around. The editor had the huge drawback that you could not select multiple text sections at the same time, as you intuitively should be able to do with text. This was a direct result of the decision to treat text types as single blocks. The only usecase that benefits from this fine-grained subdivision is when I subsequently want to move other block types, such as an image between text sections. But all the resulting problems that come along with this is not worth it in my eyes.

5 days ago
1
Changed the status to
In progress
a day ago
1
Changed the status to
In upcoming releases
a day ago
4