With the release of 3.5 and our new block and layout fields, we completed a long journey to combine the popular Builder field by @timoetting with our Editor field and bring them both into the core as one. Both fields headed in a similar direction with modular content blocks, different block types for images, videos, etc. and an editing experience for editors that’s often easier to understand than something like Markdown. By combining them, we were able to get the best of both worlds. A more visual editing experience from the Editor and all the flexibility of custom blocks from the Builder.
This step was super important for us and for @timoetting. We realised that the Editor and the Builder are such complex plugins that their maintenance is a huge burden. @timoetting has a full-time job in an agency and our main focus is on the core of Kirby. By combining both fields and their functionalities, we are now able to treat the new Blocks field as first-class citizen. This helps us a lot to release bug fixes with the regular Kirby release cycle and be more on top of issues in general.
We had planned to phase out support for our Editor slowly and give you a grace period to migrate to Blocks. But the problems with the Editor in 3.5.x keep increasing and we don’t think it’s fair to keep you hanging around with a half-functional plugin.
That’s why we decided to deprecate it immediately and support you more actively with the migration from the Editor to Blocks. We will set the Editor repo to archive mode in the next days. If you have any issues with the migration, please just let us know and we will try to help you out: support@getkirby.com
We are aware that Blocks lack a few smaller features that the Editor plugin already offered. Keyboard shortcuts and copy & pasting HTML content are probably the most noticeable features. We will bring those to the Blocks field as well. That’s a promise. Copy & paste is almost there and keyboard shortcuts will follow.
With the new architecture of the Blocks field, we also have a much cleaner foundation for more features in the future. We’ve seen all the feature requests for the Editor that were not solvable. But they become a lot more likely now with the Blocks field in the core.
Copy & Past is not a small but a core feature. With blocks editors cannot select and copy multiple title and paragraph. This make this simple task incredibly tedious and frustrating.
Undo (CMD-Z) do not works properly neither. Instead of reverting the state of the page, each block in the field has it’s own history.
This is a massive amount of inconvenience and effort for the end users!
EDIT
When editor field are converted to block field it create create one block for each paragraph. With the copy/past and history problem mentioned editing long page is hell.
You are right that especially pasting content is not a small feature for editors. I meant “small” in comparison to the complexity of the entire field.
But the good news is that we have a way more promising future for copy & paste and especially for selecting content in the blocks field than we had in the editor. We already solved multi selection in the blocks field (hint: try Alt+click) and this will also make it far easier in the future to copy content from multiple blocks at once.
With such a block editor in general, it’s way harder to achieve basic copy & paste and history features. That’s one big disadvantage, but we still feel that the approach is superior in many other ways in comparison to a traditional WYSIWG field. We hope for a bit more patience here.
About paragraphs when converting editor blocks. This should actually not happen. Multiple paragraphs should be converted into a single text block. This is one main advantage of the Blocks field in comparison to the Editor plugin. I will double-check the converter script here.
Yes, that should be possible. The blocks field can parse HTML just fine. So going from Markdown to HTML to Blocks is not a big step. But of course you would not be able to use custom blocks so far.
I love that this feature will be baked into Kirby itself. Are you planning to cover all the features of the original builder plugin by TimOetting? What I love to see is the columns parameter, or something similar.
For a client’s project, we’re making heavy use of 2 and 3-column builders, with nested builders as well. It’s an app where we have Kirby as a headless CMS and Rails as the main app rendering templates (and data from two other sources). We’re literally halfway building the app and this change is surprising but very welcome.
One of the remaining issues we had with nested builders of TimOetting’s plugin, is dragging blocks from one (nested) container to another. That’ll be difficult with this setup as well since nested block blocks () are edited in a drawer. I suspect that’s something we’ll have to scrap altogether?
) are edited in a drawer. I suspect that’s something we’ll have to scrap altogether?