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.

6 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.

6 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.

6 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.

6 months ago
6

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.

6 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.

6 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.

6 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.

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

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

3 months ago
1
Changed the status to
In progress
3 months ago
1
Changed the status to
In upcoming releases
3 months ago
5
J

You could leave it as a separate block to keep composability, by making the text field smarter : if you’ve ever used Notion (https://notion.so), you can either create blocks (literally what they call them too) by clicking, or using commands that you type in the text field (“/h3” creates a Heading 3, “/h1” a Heading 1, “/image” opens the popup to upload an image)

3 months ago
Changed the status to
In progress
2 months ago
2

Do you know the Koenig Editor of Ghost CMS (demo here: https://play-with-ghost.com/)?
It has a very clean and smooth writing experience by just showing a big editor window which can be extended by “Cards” (similar to Blocks) easily by a mouse click or keyboard shortcut.
If you don’t want to add a specific card just go on writing. It is also possible to change the order of those cards whenever you feel like it.
Similar to the mentioned Notion editor.
This direction could be a great update of the editor of Kirby in the future.

2 months ago
R

I like to solve the head and text problem with two separate fields in one block.
A header field is a text, a content field is a textarea with an editor.

I don’t like the free form of the header in the textarea itself. So I set those buttons off in the editor.

The problem with current Kirby is i cannot see the contents of both fields in a block in panel. so I had to use a block preview plug-in to show the fieldcontent directly in the panel.

I’m hoping this plugin will not be necessary anymore in Kirby 3.6.

a month ago