JavaScript for WordPress › Forums › Gutenberg Development › Working with deprecated block features/updating in the wild
- This topic has 2 replies, 2 voices, and was last updated 6 years ago by Phil.
-
AuthorPosts
-
September 26, 2018 at 5:12 pm #59800PhilParticipant
Hi there!
Can anyone shed some light on the block deprecation feature Gutenberg implements?
I’m having a hard time understanding how this feature adds benefit, as every time I try and make an update to my block I get slapped with a “modified externally” message and have to recreate the block. It seems like making markup changes to a block once it’s out in the wild is going to be pretty difficult.
It looks like Gutenberg goes into a little detail in the handbook (https://wordpress.org/gutenberg/handbook/block-api/deprecated-blocks/) on how we can update plugins without destroying/creating them again but does anybody know what the thought process is behind it? It seems really convoluted and unnecessarily difficult to understand, but maybe I’m missing something?
Great course by the way!
September 26, 2018 at 5:40 pm #59818Zac GordonKeymasterHi Phil!
Great question 🙂 I will be adding a short video on this in my next update (when GB get’s closer to an alpha release in Core).
This tutorial may help a bit too: https://atomicblocks.com/how-to-deprecate-gutenberg-editor-blocks/
The problem this solves is if you make a non-dynamic block and change anything in the save setting it will break the block. This is a huuuuge problem. So, the solution the Core team came up with is to provide old versions of your block that it can reference if anything changes. This prevents it from breaking.
It is a bit of a PITA and clunky I agree. However, one way to make it a bit nicer is to create a “versions” folder and save old versions in there as versions/block-name.X.X.js and then import and include reference to them in the deprecated setting. This will keep your code a little cleaner (like how we did with some of the icons and inspector settings in a few block examples).
Another approach is to make all your blocks dynamic and avoid this problem, but then you’re writing everything in PHP and JS and there is still a chance at some point you may make a change that breaks things.
Hope that helps explains things a bit?
Let me know if you hit any snags implementing or have any other high level questions about this 🙂
So glad you’re enjoying the course!
Cheers,
ZacSeptember 27, 2018 at 8:43 am #59900PhilParticipantThanks for the quick reply Zac.
That makes more sense, and the versioning idea will keep my main module clean which is great.
I’ll also take a look at the above article.
Thanks again!
-
AuthorPosts
- You must be logged in to reply to this topic.