getkirby / editor Goto Github PK

• History in text and code blocks
• History for any other block changes

Editor block options don't follow the styling established in panel sections: they are greyed out and use a squared grey background on hover. This would look more consistent if the action button just turn black on hover without the background as they do in sections.

I see this is in my content file:

[
    {
        "attrs": [],
        "content": "Unsere Umgebung ver\u00e4ndert sich. Mal unmerklich, mal ganz offensichtlich. In seinem Projekt <a href=\"http://zeitsprung.animaux.de\">Zeitsprung</a> bringt Alexander Rutz das Gestern und Heute der Stadt Weimar fotografisch zur Deckung.",
        "id": "_9obatb19c",
        "type": "paragraph"
    }
]

Notice the \u00e4 for an ä. Is that encoding intended?

Would be nice to be able to add a class to the image block. Great for art directed posts.

Kirby 3.2.2
Latest plugin version
Firefox 68

It would be nice if it was possible to also apply snippets to inline elements like anchors, emphases and such.

It would be nice to have an api to programmatically adjust blocks:

• appending or prepending blocks,
• removing blocks,
• altering blocks (attributes, content, type)

This is really a tricky request:

The editor's block model is really powerful and will allow us to move away from complex subpage setups to handle modular content. And while adding blocks is easy, layout often requires additional wrappers (e. g. a div with a specific class).

I'm actually not sure if this is something for the editor to solve or if this is something that needs to be applied to the resulting markup in a separate step but wrapping blocks would be a needed feature.

Example: a page with an interview, imagine two custom blocks, one for questions, one for answers. In the frontend output, we'd like to wrap all answer blocks until the next question (or the end of the content) in a div with the classanswer.

There are a few naming inconsistencies across the plugin:

1. It‘s paragraph and image not p and img but it‘s h1 and ol and not heading1 and orderedlist. As this is nothing the authors will ever see, I'd opt for the short html notation developers are familiar with.
2. It's paragraph in the configuration but in the interface it's just "text". As one block is always one single paragraph that name makes more sense to me than "text" that could actually be anything else, too, like headings, lists and so on.

Allow for adding iframe embed code from third party sites like SketchFab.

It would be great if you could represent each valid kirbytag as an inline block. The same way you can click on a link to edit its text/URL, you could click on a tag to edit its various attributes. Custom tags could provide a function that the editor could use to render them somewhere for preview in the editor for even better UX.

This issue is only needed to embed the screenshot

When trying to reorder blocks, I have to focus the one I'd like to move. I'd expect this to work on hover already (click is fine for mobile, but it's unexpected on desktop).

Same is true for accessing the context menu.

While the duplicated block is stored in the content file, it doesn't show up on the frontend.

The content of the editor is being deleted, if there is an image-block without an image

With the editor already having an image block, it would be logical to also have other referencing blocks for pages, files (all types, not limited to images) and users.

This is complicated but would be fantastic for anything like nested lists, images within list items, etc.

The editor currently stores empty blocks. I'm not sure if that is always desirable. While I understand to tension to not mess with the author's intensions, it doesn't make sense to keep empty paragraphs from a semantical point in my eyes. At least, not for closing empty paragraphs (even more if there was a placeholder for adding new blocks, see #30).

The error disappears once the field key is added manually to the text file.

Version: Alpha 3

While advanced user will like the minimal nature of the editor, new users (aka clients) will most likely need to get used to the hidden powers of the field. While I understand that a line on the left hand side most likely indicates a blockquote this might not be obvious to new authors. It would be helpful have an info option to display the current type of a block:

text:
  type: editor
  info: {{ block.type }}

The prebuilt list of types of code in the drop down lists SASS but does not list SCSS. If you using to add syntax highlighting, it would be wrong because there are two completely different syntaxes for SCSS.

Add an SCSS option to it :)

Consider Adding a class to blockqoutes. Great for art directed posts.

The alignment of the image block is strange: the UI elements and the button text is not on the same baseline. The space between the buttons looks off due to the italic "or" (is this needed at all?).

Add a "Open in new tab"-checkbox to the link dialogue

Originally posted by @nilshoerrmann:

In the context of other fields, it's not clear why there is so much space left and right of the actual content blocks. My guess is that this should make sure we don't get too long lines and have a better readability. But in general this looks strange: so why not keep the padding as in the smallest breakpoint.

• to open the dropdown
• to duplicate a block

Add the option to add simple line breaks in Texts (
). At the moment thats not yet possible, or am missing something?

When looking a empty editor field or even when looking at a field with existing content, it's not very clear how to add new blocks. The arrow icon looks like a toggle for the context menu of the existing block only so I would not expect to find the "insert new" options there.

It would be helpful to have an empty line at the very bottom of the editor with – let's say – a plug icon or so that indicates to the users that they can add more blocks.

I use notion quite a lot for myself and there is always this feeling of freedom that you can write more. Basically there is always empty block at the end of editor.

To show in code - my naive implementation is here
iskrisis@5c014fe

If this was agreeable feature i think another low hanging fruit would be on hover of the bottom area show plus button that would straight open dropdown with Insert bellow options.

As with adding new blocks, deleting blocks is not an obvious action because it's hidden in the context menu. This will not be an issue for advanced users but new users will be lost at first. Either having a delete icon on the right or having the three dot icon known from section will help.

This has also been mentioned on Slack.

Currently the editor displays in English only. I'd expect translations for all languages support by the core.

The editor allows for custom block snippets, overriding the ones provided with the plugin. Thinking of our way to work and to layout, we'd usually need different output depending on the page/blueprint context: a project page might have other needs than a text page etc. But overriding a snippet will override it everywhere.

I already asked for a way to have different snippets based on the page context on Slack and the answer was that I could add a conditional inside my custom block snippet. While that is true and this is certainly the easiest way from the editor's (the plugin) perspective, having a folder convention for snippet variants would lead to much better experience me as editor (the author).

It would be nice to filter blocks similar to collections. Two types of filter seem to be interesting:

1. filtering by type and
2. filtering by attribute

This would give us the possibility to find the first paragraph for instance and use it as excerpt:

$page->text()->blocks()->filterBy('type', 'p')->first()->html()

Converted a textarea field to editor field on a very long article containing custom kirby tags, images and videos.

When the panel was reloaded, everything showed up properly in the panel, until I saved. Have to re-enter the images and video etc.