Closed jnetzlr closed 2 years ago
Forum discussion: https://forum.getkirby.com/t/issue-extending-blocks-type-text/20416
@bastianallgeier Is this an issue or enhancement or expected behavior?
@afbora I consider this an expected behaviour. The text blocks expects a writer field. But we need to document it and/or add error handling if another field type is chosen.
If the previews do not meet certain requirements, it would be nice if the default block appears instead of the warning.
@afbora that's a fantastic idea!
It also happens when using a custom block with a field called “text”. The only workaround i found is renaming the field or setting preview: false in the block’s blueprint
I can confirm the behavior described by @marianruberg
I would like to point out that a lot of people were using the builder plugins definining a custom text block, with a textarea field named "text" inside, a pretty common naming choice. Now switching to the new blocks field suddenly those textarea fields are broken because - I guess - the writer features kick in making the textare field totally unusable.
Having a feature somehow based on a field name without making that name reserved complicates a lot of real world situations.
What we could do is
k-textarea-input
instead of k-writer
for the block preview whenever the drawer's text
field isn't of type writer
k-writer
and activate it when the drawer's text
field isn't of type writer
✅
Description
I’m currently extending the text block type:
But when editing the block, there are p tags added to the content. Even while writing in the input field (while the right side modal of the block is opened) there are p tags added to each typed character.
Expected behavior
p tags shouldn't be added to the input field.
Kirby version
3.5
Desktop