Question: version control

[wiwimaster]

Hi, it would be great to understand how Block lab handles block updates. The more features are added to Block Lab, the more existing blocks will need updates. How should those changes be handled? I didn't find any documentation on https://getblocklab.com/docs/

So I guess there are two scenarios: 1) version control exists, but the documentation is not there, or 2) there is no version control (yet). In case 1), please add the documentation how to handle this properly by scenario to https://getblocklab.com/docs/. In case 2), I recommend thinking about this, as it secures the long-term success of this plugin.

I imagine several scenarios where I add, change, remove or exchange block elements in a block. One use case e.g. is the migration from 20+ manually inserted text fields to the repeater field. Here, I would remove the 20+ fields and set them up again as one text field in a repeater frame. Another (more simple) example would be the addition of a field.

Thanks :-) Jan

[kienstra]

Hi @wiwimaster, Thanks for bringing this up, and for adding specific use cases.

There isn't a 'version control' system for Block Lab (other than this repo for the actual plugin 😄), nor a UI for migrating block fields.

I imagine several scenarios where I add, change, remove or exchange block elements in a block.

• If you add a field to a block, the block should still be valid in the block editor, and all of the previous fields should still be available. The new field will also be available.
• If you change a field, for example from a Text field to a checkbox, the output could change, depending on the field type. But if you change the field slug (name) entirely, that's a problem, unfortunately. You'd have to enter the value again.

One use case e.g. is the migration from 20+ manually inserted text fields to the repeater field. Here, I would remove the 20+ fields and set them up again as one text field in a repeater frame.

Unfortunately, there's no way to do this now, other than manually. I can see how that'd be a big hassle to manually re-enter the values 😄

Were you thinking that a UI for this would help?

Another (more simple) example would be the addition of a field.

This should work fine. For example, if there's a block that has a Post field, adding a Text field won't change the Post field, and the Text field should work as expected.

[wiwimaster]

Thanks, sure :-)

I believe that it would help already to explain how changes on blocks should happen, and what consequences an addition, change, removal would have on both future and past entries. This is mainly what you described and I recommend to put this on a support page.

On the migration from single fields to repeater fields, I am not sure how big of an issue this is. I'm an early user of Block Lab and this feature didn't exist then - so I would benefit from that; but I don't know whether this is something the current, average user would need.

[kienstra]

I believe that it would help already to explain how changes on blocks should happen, and what consequences an addition, change, removal would have on both future and past entries. This is mainly what you described and I recommend to put this on a support page.

Thanks, that's a great suggestion. I don't think there's any documentation of that.

[kienstra]

Thanks a lot for being an early user. It means a lot that you trust us with your development, and that you're helping with suggestions.