Thanks, Elliot. This is going to require me viewing this video about 5 times, for it to sink in. Thank you very much for the time you've put into this.
Thanks for the comprehensive tutorial! Very helpful! One question though - wouldn't creating a block variation have been more appropriate in this case? Doesn't this approach limit the use of the core blocks to one instance only because all other instances would equally be affected by your customization even if you wouldn't need or want the customization for, say, a secondary image, or another site logo in the footer?
Great question 👍 If you’re referring to a style variation, I’m not certain that it would allow users to choose their own “alternative image” or “logo”; it would likely only result in a style change. My implementation demonstrates how users can define and use two different images. Additionally, there’s a conditional check based on the tag (), so the placement of the block wouldn’t be affected; it would be returned as intended. However, if there’s a bug I might have overlooked, I appreciate you’ve brought it to my attention, I’ll set up a test for that 🙌
@@elliottrichmondwpYou're right, you're checking for the "header"-template part. So, it probably won't matter much in most cases, where there's only one navigation menu in "header". Still, imagine you have two menus in the header, one main and one offering functional navigation for login, privacy and legal info. The other navigation block would be affected because all changes apply to "core/navigation", wouldn't it? That's why I was wondering about "block variations", which are not "block styles" and which would, I think, allow you to register a copy of the core block (like core wp does with the different embed formats that are all variations of core/embed if I'm not mistaken) with a different name and then only target that new block with your code instead of all core/navigation blocks. That way a potential second navigation block in the header would be unaffected by your changes. This is what the block editor handbook says about "Block variations" - "Variations are an excellent way to create iterations of existing blocks without building entirely new blocks from scratch." developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/ developer.wordpress.org/news/2023/08/29/an-introduction-to-block-variations/
@tsxpneo You raise a valid point, and indeed, there are multiple ways to achieve the same goal. Block Variations is just one of them, and each approach should be considered based on the specific problem at hand. My tutorial presents "an approach" to the problem, but there are certainly other ways to accomplish it. I could refactor my code to improve it, as there's always room for enhancement. If my approach involved manipulating the 'core/navigation' block, for instance, I would likely take a different approach. However, in this case, I'm targeting the 'core/site-logo' block, which is only saved once in the database. Moreover, I'm conditionally targeting an image to append an element ID only if an alternative image has been selected, and only in the template. Therefore, my approach would still function correctly even if the site-logo block were placed in the footer. It's also worth noting that this is a unique case for a client website. If it were for commercial release, such as in a theme, I would probably approach it with a variation so I thank you for your sharing your thoughts and insights on this! 👍
@@elliottrichmondwp You're absolutely right to emphasize that there's different ways to get to the same result. As I suppose most people I'm also still relatively new to block development and "modern WP development", so clearly my thoughts are mostly that: my thoughts. And I would like to thank you again for your tutorial which I find very helpful! It's also a testament to the level of complexity necessary in "modern development" compared to classic php theming when it comes to customization that cannot be done by patterns of core blocks and/or theme.json.
Yeah, I noticed that on one clip after I uploaded, apologies about that, not sure what’s happened but it was on a fusion clip 🤷♂️ rest assured it’s only on a small clip.
This is the best tutorial I’ve seen so far for extending core blocks. Thank you for your work!!
Wow! Thank you 🙏
Thanks, Elliot. This is going to require me viewing this video about 5 times, for it to sink in. Thank you very much for the time you've put into this.
More than welcome 👍
just wow very good explanation 👍
Thank you for the feedback 🙏
Subscribed, Gold content for learning Block theme.
🙏
Love your editing! Thanks for this new tutorial
Glad you liked it! And thank you so much for the positive feedback, much appreciated 🙏
thank you for this tutorial. I plan to start getting into extending core blocks
Go for it! Would love to know how you get on 👍
the audio is VERY choppy at 3:00-3:46
Yeah sorry about that, not sure what happened, only noticed it after the render, I’ll see if I get more info on what might have caused it 🧐
Thanks you , super usefull!!!!
Thanks for the feedback, glad you found it useful 👍
Nice! Thanks ❤
No problem 😊
Thank you!
Most welcome
Thanks for the comprehensive tutorial! Very helpful! One question though - wouldn't creating a block variation have been more appropriate in this case? Doesn't this approach limit the use of the core blocks to one instance only because all other instances would equally be affected by your customization even if you wouldn't need or want the customization for, say, a secondary image, or another site logo in the footer?
Great question 👍
If you’re referring to a style variation, I’m not certain that it would allow users to choose their own “alternative image” or “logo”; it would likely only result in a style change. My implementation demonstrates how users can define and use two different images. Additionally, there’s a conditional check based on the tag (), so the placement of the block wouldn’t be affected; it would be returned as intended. However, if there’s a bug I might have overlooked, I appreciate you’ve brought it to my attention, I’ll set up a test for that 🙌
I’m wondering the same thing. I’m new to all of this so my understanding is very limited but would this affect that block used elsewhere?
@@elliottrichmondwpYou're right, you're checking for the "header"-template part. So, it probably won't matter much in most cases, where there's only one navigation menu in "header". Still, imagine you have two menus in the header, one main and one offering functional navigation for login, privacy and legal info. The other navigation block would be affected because all changes apply to "core/navigation", wouldn't it? That's why I was wondering about "block variations", which are not "block styles" and which would, I think, allow you to register a copy of the core block (like core wp does with the different embed formats that are all variations of core/embed if I'm not mistaken) with a different name and then only target that new block with your code instead of all core/navigation blocks. That way a potential second navigation block in the header would be unaffected by your changes. This is what the block editor handbook says about "Block variations" - "Variations are an excellent way to create iterations of existing blocks without building entirely new blocks from scratch."
developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/
developer.wordpress.org/news/2023/08/29/an-introduction-to-block-variations/
@tsxpneo You raise a valid point, and indeed, there are multiple ways to achieve the same goal. Block Variations is just one of them, and each approach should be considered based on the specific problem at hand. My tutorial presents "an approach" to the problem, but there are certainly other ways to accomplish it. I could refactor my code to improve it, as there's always room for enhancement.
If my approach involved manipulating the 'core/navigation' block, for instance, I would likely take a different approach. However, in this case, I'm targeting the 'core/site-logo' block, which is only saved once in the database. Moreover, I'm conditionally targeting an image to append an element ID only if an alternative image has been selected, and only in the template. Therefore, my approach would still function correctly even if the site-logo block were placed in the footer.
It's also worth noting that this is a unique case for a client website. If it were for commercial release, such as in a theme, I would probably approach it with a variation so I thank you for your sharing your thoughts and insights on this! 👍
@@elliottrichmondwp You're absolutely right to emphasize that there's different ways to get to the same result. As I suppose most people I'm also still relatively new to block development and "modern WP development", so clearly my thoughts are mostly that: my thoughts. And I would like to thank you again for your tutorial which I find very helpful! It's also a testament to the level of complexity necessary in "modern development" compared to classic php theming when it comes to customization that cannot be done by patterns of core blocks and/or theme.json.
This might be helpful as I am playing with HTMX. Sound has an echo on it?
Yeah, I noticed that on one clip after I uploaded, apologies about that, not sure what’s happened but it was on a fusion clip 🤷♂️ rest assured it’s only on a small clip.
nice
isnt wordpress dead yet
Nope 😍