Thank you Brian for your well explained and nice video. I did something very similar, around two days ago, while working on the new #GatherPress blocks. I also wanted to get some button blocks prepared with data, used the Block Bindings API and were happily good, until I realised, my button blocks won’t be selectable from the inserter. That’s why I created an additional variation of the buttons block, with a nice icon, with my blocks prepared as innerBlocks, but without an isActive declaration. Once inserted this variation behaves like a normal buttons block. I found this to be more intuitive because it still allows to select the - in your example - the Amazon and the Goodreads block individually. Best regards, Carsten.
Brian, you are truly gifted at explaining complex techy topics in a very clear way. Really appreciate your content! When can we expect your first musical video, though? 🎸
You'll need to register "custom block binding sources" - here's a blog post that goes into more detail: developer.wordpress.org/news/2024/03/06/introducing-block-bindings-part-2-working-with-custom-binding-sources/
Great tutorial! Thank you for this, really helpful! A quick question, is there a way to make the link (the core button) open in a new tab? I can't find the block variation arguments that can set the open target.
Thank you for your explanation. Can you add some example how to display date in chosen format eg. 'Y-m-d'? I mean date, that is display from block variation based on block binding API.
You would most likely need to create a custom data source and return the data exactly how you want it. developer.wordpress.org/news/2024/03/06/introducing-block-bindings-part-2-working-with-custom-binding-sources/
Thank you very much, Brian, for this tutorial. I've been a long-time user of ACF and have been eagerly awaiting this. I have two questions: 1/ In your tutorial, when the fields are displayed in the single, they seem to have been made with ACF. Is that the case? I really don't want to go back to making my fields manually. 2/ Is it possible to use your method in the FSE templates?
1/ I did the test and it works. I declare the field in ACF UI and in my plugin (register_post_meta) with the same key. Is this the correct method? 2/ I tested it in the FSE templates and it works as well. Thank you again for all your shares. I do the same but in French.
Nice! For now this is the correct method. I believe ACF is going to set up their own integration in the future so you won't have to use register_post_meta, but I'm not sure when that will be released.
@@BrianCoords Thank you, Brian. ACF here has a huge opportunity to create custom FSE templates without a single line of code. Apparently, they are preparing something.
On the one hand, I'm glad that Gutenberg is finally embracing custom fields. On the other hand, I don't quite get it (and that may actually be me not getting it, of course). I mean, it would be one thing to basically have a proper ACF-style UI in the the editor where field-types could be chosen and the data could be entered. On the other hand, there's good reasons for separating those aspects. So I suppose custom fields will have to be defined but also likely also input somewhere else from where they're displayed, which means likely ACF or a revamped native UI. But then, as soon as a specific post has a specfic data structure supported by post meta, there will again be two input UIs for that post, one of which (the main editor) will then be mainly a preview area. Am I missing something?
No, I think you're correct. There are some redesigns coming in the next year or so that will hopefully make a nicer experience for editing metadata, but I do think there are a lot of situations where people do just want to fill out some custom fields that aren't inside the actual content. Like you'll always need that and it's helpful to see all your custom fields in one place. You can technically get around that by making a custom block with a two-way binding. The "post title" block is a good example of that, but what happens when you have a design where the post title isn't shown on the page anywhere? So you'll always need that second UI to just update data. But I do think it would be great if you could set up custom fields (and custom post types) in core WordPress without code or plugins.
Why wp always soo hard to make something, always complicated why it’s soo hard to migrate layout and design from figma, psd ? Any good full tutorials how it’s must do with good quality and understanding :( Why it’s doesn’t have a good structure how for example Laravel and docs …
I love Laravel but developer docs are a lot easier to write than visual builder docs. I agree though there should be more content and the process needs to get easier. I'd love to do a full build from Figma or from a design - it's on my list!
Thank you Brian for your well explained and nice video.
I did something very similar, around two days ago, while working on the new #GatherPress blocks. I also wanted to get some button blocks prepared with data, used the Block Bindings API and were happily good, until I realised, my button blocks won’t be selectable from the inserter.
That’s why I created an additional variation of the buttons block, with a nice icon, with my blocks prepared as innerBlocks, but without an isActive declaration. Once inserted this variation behaves like a normal buttons block.
I found this to be more intuitive because it still allows to select the - in your example - the Amazon and the Goodreads block individually.
Best regards, Carsten.
Oh interesting... I haven't looked too deeply into isActive, so I think I have some research to do. Thanks for the tip.
Enjoyed these block bindings API! Thanks for the explanations
Thanks Brendan- this feature has a lot of potential.
Brian, you are truly gifted at explaining complex techy topics in a very clear way. Really appreciate your content!
When can we expect your first musical video, though? 🎸
Thank you! And if I start playing music on this channel everyone will quickly be smashing the "UNSUBSCRIBE" button 😂
Trying to use blockVariations to display custom post type taxonomy meta as a featured image. Do you any idea where to start?
You'll need to register "custom block binding sources" - here's a blog post that goes into more detail: developer.wordpress.org/news/2024/03/06/introducing-block-bindings-part-2-working-with-custom-binding-sources/
Great tutorial! Thank you for this, really helpful! A quick question, is there a way to make the link (the core button) open in a new tab? I can't find the block variation arguments that can set the open target.
Yep - you need to add the "linkTarget":"_blank" attribute to your variation and it should populate that value when the buttons are added.
@@BrianCoords Thank you! Adding that works!!
Thank you for your explanation.
Can you add some example how to display date in chosen format eg. 'Y-m-d'?
I mean date, that is display from block variation based on block binding API.
You would most likely need to create a custom data source and return the data exactly how you want it. developer.wordpress.org/news/2024/03/06/introducing-block-bindings-part-2-working-with-custom-binding-sources/
Don't we need ACF anymore if it's once released?
ACF does a lot of other things, so I think it still has some value.
Thank you very much, Brian, for this tutorial.
I've been a long-time user of ACF and have been eagerly awaiting this.
I have two questions:
1/ In your tutorial, when the fields are displayed in the single, they seem to have been made with ACF. Is that the case? I really don't want to go back to making my fields manually.
2/ Is it possible to use your method in the FSE templates?
1/ I did the test and it works. I declare the field in ACF UI and in my plugin (register_post_meta) with the same key. Is this the correct method?
2/ I tested it in the FSE templates and it works as well.
Thank you again for all your shares. I do the same but in French.
Nice! For now this is the correct method. I believe ACF is going to set up their own integration in the future so you won't have to use register_post_meta, but I'm not sure when that will be released.
@@BrianCoords Thank you, Brian. ACF here has a huge opportunity to create custom FSE templates without a single line of code. Apparently, they are preparing something.
Hey Brian, i would love to see you explore the interactive api
There may happen to be some Interactivity API content coming in the next few weeks on my other channel: www.youtube.com/@viewsourcefm
@@BrianCoords lol i had no idea you had another one
Yep - it's a podcast with a co-host. We talk WordPress but we also dig into other tech like Laravel and Next.js and compare it to WordPress.
@@BrianCoords Thats dope, i work with all 3
On the one hand, I'm glad that Gutenberg is finally embracing custom fields. On the other hand, I don't quite get it (and that may actually be me not getting it, of course). I mean, it would be one thing to basically have a proper ACF-style UI in the the editor where field-types could be chosen and the data could be entered. On the other hand, there's good reasons for separating those aspects. So I suppose custom fields will have to be defined but also likely also input somewhere else from where they're displayed, which means likely ACF or a revamped native UI. But then, as soon as a specific post has a specfic data structure supported by post meta, there will again be two input UIs for that post, one of which (the main editor) will then be mainly a preview area. Am I missing something?
No, I think you're correct. There are some redesigns coming in the next year or so that will hopefully make a nicer experience for editing metadata, but I do think there are a lot of situations where people do just want to fill out some custom fields that aren't inside the actual content. Like you'll always need that and it's helpful to see all your custom fields in one place.
You can technically get around that by making a custom block with a two-way binding. The "post title" block is a good example of that, but what happens when you have a design where the post title isn't shown on the page anywhere? So you'll always need that second UI to just update data.
But I do think it would be great if you could set up custom fields (and custom post types) in core WordPress without code or plugins.
Why wp always soo hard to make something, always complicated why it’s soo hard to migrate layout and design from figma, psd ?
Any good full tutorials how it’s must do with good quality and understanding :(
Why it’s doesn’t have a good structure how for example Laravel and docs …
I love Laravel but developer docs are a lot easier to write than visual builder docs. I agree though there should be more content and the process needs to get easier.
I'd love to do a full build from Figma or from a design - it's on my list!