FR: Ability to define block templates

[theskyfloor]

The idea would be to allow a template to be made (i.e. 2-column, with image on the left and text on the right) but it would just spin up a neo block and children using the existing structure of the neo field. This would let me define layouts for my clients without sacrificing flexibility when they want to make a change, add a column, or rearrange the column order.

[benjamminf]

This is a cool idea which I've had for a while now. I haven't yet come up with the UX for creating/using block templates, but it's something I'm aiming to have in version 2 of Neo, which will be coming with the release of Craft 3. Feel free to post how you'd think it could work 👍

[Emkaytoo]

I've given this some thought, too. My guys were looking at how we could manage blocks outside the context of a field, and then use the field as a "block selector" to essentially include the blocks.

My first thought went to using the sidebar are to define blocks, and then adding an "include" feature to the Neo field config. The UI for the block builder could be the same, just sans a few features like child blocks and top-level (which should be defined in the field, imho).

I did a few quick in-browser shots just to show the concept (don't judge).

In this second one, you'll notice a selector, a Relabel field (shameless plug , eh?), and that the Field Layout tab is gone. You'll also notice in the Neo config sidebar that one can still define custom blocks in this field, usable only in this field.

In the Defined Blocks area everything looks the same, except I added an "Export to block manager" link that would...well...export the field-defined block to the block manager to be included. This would be useful if a block that was created on the fly became more reusable as the site grew.

When I find some time, I can mock up the Block manager, but the UI should be pretty similar to avoid have to learn two UIs.

[Emkaytoo]

Addendum: in my ideal world, the blocks would be independent models. It would make adding and managing them using The Architect a little easier, and would move the Neo field and Craft closer to a Django-like model where all content models are files.

[theskyfloor]

Good thoughts! My thought would be to have a different UI related to a button similar to "Add a group" this button would activate the UI to create a block template. When it is complete you name it and it either automatically goes into a Matrix collapsed menu/selector called "Templates" or you can maybe just assign the template block to an existing group... leaving the naming up to you. The main way to differentiate the template blocks from the regular blocks would be an icon or color.

Something like this. Although even working in this concept for 5 seconds reminded me of why I wish there was more variation/separation between blocks, etc in Craft/Matrix/Neo. It is all a big gray blob sometimes. Not Benjamin's fault though he is working well within the style guidelines.

EDIT: oh yeah the other thing to note is content isn't part of the template block style in this imagination. So layout can be done with simple placeholders. I can easily see why being able to pre-fill out fields could be useful in this concept though (i.e. background image, a certain preselected class, or image float).

[theskyfloor]

In some ways I almost feel like this concept is less useful unless there is a "page layout" view where you can actually seeing content side by side if you are making a column builder but on the other hand the savings in time building layouts and maintaining flexibility could be worth it.

[benjamminf]

A bit late to the party, but I really like the ideas you guys have come up with! I've put a lot of thought into them over the last month and I think I have a good idea on how to tackle both of them. I want to address both ideas in their own comments, which might be a couple of days from now.

My one concern is by adding these features, it increases the complexity of the plugin substantially. Neo is already pretty confusing to beginners as it is. And these features are definitely for the power user. With that in mind, I still think these features will be very useful, so my current plan is this: separate them into a secondary plugin. I think Neo with it's current feature-set is enough for most users. A secondary plugin (Morpheus? I'm open to name suggestions) could address these features, plus some more authoring tools that I've been dreaming about (field minimap, built-in columns, etc).

As a side note, I have made a start on Neo for Craft 3, and it's being built with the following in mind:

• Be very friendly to plugins – provide not just a better API for the PHP, but also one for the front-end. The goal is to be able to easily access and modify a Neo field's blocks, block types, etc. through a JS API. I also plan on having the front-end available on NPM, so other plugins can leverage the UI.
• Full support for console – provide a full-featured set of console commands for managing Neo fields and their blocks.
• Fully unit tested across front-end and backend – the biggest pain for me right now is the lack of testing, so it's very hard to know if a new version of Neo will not break anything. It's the main thing that's keeping me from having a reasonable release cycle, as I need to run the new version for a while until I'm comfortable that it works before officially releasing it.

This plugin, and especially this new version, is a huge undertaking for just myself. The reality is I'm a very busy person even without my open-source projects and these features will most likely not get developed for quite some time after the initial release. I hope with an open API for developers to learn and use, it'll give you a chance to extend Neo with the functionality you need in particular.

[ttempleton]

This is planned to be added to version 5.1 for Craft 5, except with the ability to set an entry type to use for your block type, instead of custom block type templates.