It would be great to be able to use blocks outside modular content, as a way to reuse fields between multiple models.
To clarify:
Let say I have three models: news, articles and general_information. All these models share the fields title, subtitle, and the structured text field content. I want to be able to group all of these in to one block and then simply add that singular block to all models, to be able to for instance add blocks to the structured text field, and by then change all models directly.
This could be done now by using modular content, and limiting the records to one. However, from the editors perspective this is not optimal as you need to create the first record of you own, it also shows an unattractive message about this + the content is nested in the block frame and you cant use the full screen view of structured text.
A simple way to create shared single blocks between models would be of great use in many cases.
I second this request. In our evaluation of Dato vs ContentStack, this would be another big blocker to us switching to Dato. We make heavy use of the concept of blocks, and while a lot of it does occur in a modular content type field, we also heavily use these to add common fields across many templates ( models in Dato ). Things like Administrative options that need to be present and identical in all models and we have found that having to maintain them independently is not very scalable.
Is this in a sprint or at least part of a planning phase?
hey @jdesherlia thanks for your feedback, make sure to vote the feature requests to give them more prominance. We don’t have this in development yet, but we’ll surely consider it. We add the tag planned to all the features that we are working on.
Right now we have just released the new version of our Plugin SDK so we are considering new stuff soon.
Not sure if its the same thing we’re asking, I wanted to force display a block when a new instance of a model was created. I wrote a plugin to see if I could do a temporary work around. Working on some errors, in another thread, let me know if it does what you need. I’m hoping this because a native option, and raised anothe support request for a new field type.
@mat_jack1 thanks for the clarification on how this community is structured. I have added my vote to this feature request. Fingers crossed!
@emile.swain this looks pretty cool, and might fill the gap for now. You mentioned an issue with translations not working… Can you expand on what that limitation is? Otherwise, thanks for putting this together, I think it will be a very valuable plugin.
I don’t know anything about translations, though i’ve seen some code in other example plugins that i think related to the localisation part. I just ignored it.
i’ll try and find the link.
Is this something that might be picked up? We find ourselves wanting to reuse single blocks quite a lot but being hesitant since we have to use modular content which always creates an array. The behaviour I would expect is that if I restrict a modular field to max 1 block, it would be represented as an object instead (or another option to add a singular block into a model).
Yes @felicia.moller, if you restrict to one block we still return an array, but on the UI we automatically add the block, if only one block is available, have you seen this? For the editors is the same, we need to improve on the API side.
We are surely going to consider this in the future.
Is this still under consideration? We find our self spending a lot of time having to update many models separately that all share the same field structure. It would be so useful to be able to share a set of fields between different models.
So at the moment we’re working on a project with several different models based on content types, like News, Commissions, Portfolios, Events, aso. All these share the same structure, fields and final layout, with some exceptions, and we use Structured Text for the client to build block based layouts for each record, and a set of mandatory fields like Title, Image, Slug, Desc.
During the process of building the site we often find that we need to add or remove a block or two in the Structured Text fields, or we need to add a help text to the Slug field, or set a limit to the image sizes of the Image field. At the moment we now need to do that on every model, which is a bit time-consuming and it’s easy to forget something.
Coming from a WP background we’re a bit used to the ACF fields, where you can create a group of fields, which you then can choose to use on X amount of models. Most other things are 100 times better in Dato of course, but that function saves a lot of time and makes it way easier to manage your fields in a consistent way.
+1 to this feature (I think this feature is not getting more votes because the title is a bit misleading)
We’re making a heavy usage of blocks in our project, and most of them are used in a 1:1 fashion. We’d love to have the option to create 1:1 relationships between a field and a block, in a similar way as you can have a single or multiple links to models, so that:
Makes development easy. For example, if my model has a header field that will only have one block, it’s counter-intuitive to do header[0] to access the actual content, as well as naming it headers when there’s only one.
Avoid the unnecessary block layout in the UI. If there’s a 1:1 relationship with a block, I’d love the UI to pretend that there’s no block involved and show the fields as if they were first level fields of the model.
This is the only real issue I’ve encountered so far when working with Dato in the past few days.
My use case, is a reusable “style” field which holds something like “background_color” and “text_color” which almost every single type of block I make will want to have. Something like the discussed feature would help clear up a ton of copy pasting and manual setup of creating these fields on every block type, getting the preset color hexes from somewhere and pasting those, etc.
We find ourselves wanting to reuse single blocks quite a lot but being hesitant since we have to use modular content which always creates an array. The behaviour I would expect is that if I restrict a modular field to max 1 block, it would be represented as an object instead (or another option to add a singular block into a model).