January 19, 2018 at 5:05 pm #38789
Any recommendations on how to handle template changes to custom blocks longterm? At this time, if the template changes one would need to update each page when there custom block exists. Not great for longterm scalability.
I’m finding that I can create a block and use it on multiple pages as expected. If I later update the template, I need to go into each page and update the block manually because the block HTML is written statically into the post_content.
For example, I have a client who embeds a shortcode we created which displays an “Add to Cart” up-sell within blog content. Creating a custom block would make perfect sense in this case, but if we ever needed to change the layout, needing to update each post manually would be a real hassle.
I brought this up in the Gutenberg repo and confirmed my understanding of this problem, but don’t really see a great fix: https://github.com/WordPress/gutenberg/issues/4550#issuecomment-358374519
This seems like this severely limits the options for custom blocks and for long term usage on client websites. Best solution I can think of at the moment is find/replace of the HTMl in the database.
Any thoughts?January 19, 2018 at 8:38 pm #38819Zac GordonKeymaster
I cheat a bit and asked this question in the Core #editor-js Slack Channel and got this response from a core developer:
“that’s an interesting one. If I had to imagine, you would offer a per-block transformation routine (similar to the
migrateAPIs) that would match every existing block of the template to a new state/different block. Might happen on loading a post, or could be done in bulk.”
I realize this goes a bit beyond the scope of the content current in the course and is a tiny bit of an edge case, but not really.
Would be happy to chat this out, if you wanted to explore a solution around this.
Hope this helps a bit! Good question 🙂January 19, 2018 at 8:55 pm #38821
Yeah, I agree that some sort of updater would be required. Bulk would make sense to me, as you may not want to listen for every block type, on every page, on every load.
I feel this is something which the standard user might not run into, but imagine needing to re-update every blog post every time you updated a widget or reconfigure a CPT setting. I’m excited for the blocks, because it finally offers a good chance for loading dynamic content within pages and posts, but until some method of updating presents itself I have a hard time seeing any value to custom blocks in large scale environments.January 19, 2018 at 8:56 pm #38828
Thanks for asking around!January 27, 2018 at 10:38 pm #39869rosswintleParticipant
Glad you asked this question. I just watched episode 04.08 (On the save setting) and realised that output markup is written to the post content at post-save time and had the same question: what if my block markup changes?
This makes developing custom blocks pretty tricky.
This is quite a big issue in my opinion.January 27, 2018 at 11:31 pm #39879Zac GordonKeymaster
If block content may change or need to be loaded dynamically then the suggested block architecture would be to use a dynamic block that is actually rendered on the frontend with PHP and therefor can stay dynamic.
Unless I’m misunderstanding, this may be a separate issue from the one mentioned about swapping templates, but still an important question!
Let me know if that answers your question.January 29, 2018 at 11:38 am #40030rosswintleParticipant
I think I’ve decided that this is OK. For the sorts of “structured” data that I would normally want to do this for, the block can save that to post meta and the meta data can be used in PHP template files as I would normally do.
@hallme, can’t you just write the shortcode out from the block’s
saveattribute?January 29, 2018 at 4:25 pm #40050
@rosswintle I’ve not tried it, but I believe the shortcode could work. I gave that example as a question on how to build and maintain a custom block, less on how to update the existing update (also an important question, though.)
After reading a pretty great blog post on how Human Made set up their homepage in Gutenberg, I went back and re-watched the dynamic block videos. I had been expecting to build the block interior with JSX and the REST API in the save function, but it seems like the preferred method is to use a PHP callback. Zac mentions in the Alt Dynamic Block video that there may be a way of doing everything in JS, but it has not established itself as a “standard” yet.
I’ve tested this, and found that by editing the PHP function, the front end of the block will update automatically. This solves most of my concerns about the viability of custom blocks, but it does not immediately solve for block data migration or wrapper name updates.
- You must be logged in to reply to this topic.