Blueprint editor#20

A visual editor for blueprints, which would administrate all the yaml settings for you.

This would really help speed up kirby dev, I always mess up the yml indentation and live in the field docs.

A visual editor which shows all possibilities, depending on the fieldtype, would really speed up the whole building-process for new websites. For now, i always have to switch between searching the docs, editing the blueprint and reload the panel.

It would also be interesting to edit blueprints from within the actual page view. Like changing field order in the panel directly.

Oh, my, goodness, yes please. I would love this. I dislike editing YAML or trying to remember how to structure blueprints or what options are available for each field/structure/extends/defaults/templates/etc., etc. This is an awesome idea.

The concept of coding up the blueprints is a plus in my book. I found that a visual builder gets very clicky (e.g. lots of click, inputs, selects, clicks… ) Ever use Processwire? Coding those blueprints does require some referencing from time to time, but it’s very fast and efficient (plus ditches any bloat required to make that process visual).

@Chris I guess this will not change, you can still edit manually.

@Chris I’ve used processwire and statamic and both offer a very helpful visual interface for creating blueprints - i really like them!

I don’t support it.
The beauty of Kirby is that you have to build the blueprint yourself. But after that, it doesn’t change under any circumstances. We can see it as a drop-in, if you are willing to understand the blueprint, you are probably open to further understanding the system.
Let’s not be WordPress and not want to be everyone’s CMS. The world would be a better place if more people used Kirby.
But I don’t think it’s a situation to start diluting its user base either. Let’s be honest yaml is not a complicated thing.
I understand that it would speed up the work, but if this development is included, the system may become more unstable. I don’t think anyone wants that. Afterwards, if there are bugs in the yaml editor, that will be the problem. It is better to have a stable system than a system that is full of all kinds of convenience additions that make it unstable.
Please don’t repeat the instability of WP.

How will having a user interface that generates YAML blueprints make the system unstable?

It’s a feature you wouldn’t even have to use it if you don’t want…

If you want to make the world a better place with more people using Kirby, how about being more open to features that prevent people using it? Nobody is asking for wordpress like sillyness, this is a feature that other advanced CMS’s include without issue (Craft CMS, Statamic etc).

Well said Maxwell. I switched to Statamic mainly because manually writing yaml files was tedious and confusing. Still following here hoping one day this blueprint editor will arrive.
I really don’t understand what problem have those who oppose it. If you wanna live in the XIII century and do superflous manual work you can continue to do it even if the editor exists.

I also support your answer Maxwell! It’s just a graphical interface that helps us to write YAML files. That’s it. I really don’t understand people who object to such optional features. Presumably, as a protest, they only use operating systems without an UI and remember telephone numbers instead of storing contacts in their mobile phones. 😉

Every feature has a technical debt. This feature, the ability to visually compose all options of a blueprint, is no small feat. I’d imagine it would add some debt. Maybe that’s a larger install size, more server resources to run this particular feature, additional documentation, potential security risks, potential compatabilty issues, etc.

The more you have, the more you have to maintain. Every time Kirby has some blueprint enhancement this feature would need to be worked on, documentation updated, etc. That’s a lot of time invested for the Kirby team. And for what, the ability to compose blueprints which is already possible? I’d rather see time invested in improving my end-product to the client, the best content managing expierence possible.

At the same time, not having this feature is also a debt because it turns people away from using the system in the first place and less licenses are sold.

There’s no need to turn this into a heated debate. There are good arguments on both sides. Our position is that we have been working on this for a very long time on an on/off basis. The power of our blueprints is that they are very flexible with tons of options and ways to combine and extend sections and fields. This flexibility leaves us with a very complicated baseline to build a blueprint editor and this is what we still struggle with. A lot of the work for v4 has been about new interface foundations that we need for the editor. I.e. the full-width interface, new drawer API and other stuff.

We still need a good way to support field and section plugins. We will need a good way to handle extended sections and fields and the editor needs to be able to auto-generate the settings UI for fields and sections from code. Otherwise this will turn into an ongoing monster project with every change.

I can only say that we also think that such an editor would move Kirby forward and that we spend a lot of energy on it already and will keep on doing so. But we don’t have an ETA for it yet. Please, don’t argue over it. I’m sure that we will find a good solution for everyone in the end and of course it will always be possible to just keep on writing YAML if you don’t need or like it.

I think adding a

• 'editable: true/false' option for YAML/Blueprint files and
• a config flag along the lines of 'editable-blueprints' => ['blueprintA', 'BlueprintB', 'user-generated']

could solve some issues. It could allow adding template-blueprints to the list of editable ones and allowing/disallowing user-generated ones.

If I create a blueprint for a custom template file, I’d like to stop users from editing the blueprint — as that will also edit the blueprint for all users of that installtion and might break it. But some bleuprints would be nice if the user could edit it.