-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Epic: Block Hooks Features for WP 6.5 #54904
Comments
One more item to consider would be to potentially iterate over the Plugins section UI in the sidebar panel based on the comments about different expectations from folks that were testing it so far: #53987 (comment), #53987 (comment) and #53987 (comment). I expect it will come back regardless after the call for testing when more people have a chance to play with the integration in the editor. |
Update: It was brought to @gziolo's and my attention that the performance of patterns is currently lacking in WP 6.4 (Beta), which is particularly apparent when using TT4. @dmsnell found that
All of them have since been benchmarked and/or profiled, and only one of them turned out to deliver actual improvements. We'll thus land WordPress/wordpress-develop#5399 in time for Beta 3; there's also WordPress/wordpress-develop#5421 which might improve performance some more (but still needs verifying). Other than than, @ndiego has done some preliminary testing of Block Hooks; we might try to make some further improvements (or at least file some issues/tickets) based on his results. |
Hey all 👋 I was just trying to create a demo of Block Hooks and it leaves me wondering whether I'm missing something 🤔 As far as I can tell from the documentation we can only define a block type where the additional elements should get injected. Is this correct? I'm asking because I think that may be a pretty large limitation of the API currently. I had though this would work a bit more like CSS selectors where I could "query" for a block insertion point via a more complex selector like The issue I am running into is that in a block based theme all the available blocks are used for so manny different things that it's almost impossible to make a blanked statement that a new block should be inserted after every author block for example. Because taking the example of the post author block it may be used very differently on a single post template compared to an archve template that renders query loops with the author of each post displayed within. This is even more true when thinking about more generalized blocks such as the Another thing I was hoping for is to target specific variations of a block. For example if one has a custom variation of a product query it would be really cool to say append a block to the post template in the product query variation of the query loop. Thanks in advance for any response :) And I get that this is the first MVP version of this. I just want to make sure I'm not missing something :) |
Thinking about this more, I think one of the original goals of this was to make it possible for plugins like WooCommerce to automatically inject their "Mini Cart" block into the main navigation of the site. However, if I get this right currently, that wouldn't be possible because all you could do is say add it to all navigation menus. But since most themes have way more than one menu that doesn't seem feasible 🤔 |
@fabiankaegy I'm not sure I understand this statement, which makes me wonder if I'm missing a larger Block Hooks understanding/requirement for implementation altogether. I'm currently trying to test an ACF Block by just dropping in the I'm using
I'm running WP 6.4 Beta 3 through WordPress Beta Tester plugin on Local and I have Gutenberg plugin installed and activated. The Like Button plugin's block shows fine. However, my block does not display at all. What am I doing wrong? 🤷 |
@colorful-tones What I mean by that is that the API currently only supports this: {
"blockHooks": {
"core/navigation": "lastChild"
}
} and not {
"blockHooks": {
// core/template-part/header meaning the header variation of the template part block
"core/template-part/header core/navigation": "lastChild"
}
} |
@fabiankaegy I see what you mean and that makes sense. I did not expect that level of explicitness for this first iteration of this new API, but I can certainly see how I would want it to get there quickly 😄 |
I've just tried
|
ACF Blocks requires a block's In the case of a ACF Block being added via a block hook, unless the template is edited and saved, that never happens - so we abort rendering because we can't figure out the block's type or data. If you make any changes to the template, This issue is likely specific to ACF Blocks (although, there definitely could be other blocks that setup some data to the block comment on We'll work around this by inheriting more defaults from |
Update: After landing WordPress/wordpress-develop#5399 (which sought to improve Block Hooks performance, see #54904 (comment)), it was unfortunately discovered that that change broke template parts. We managed to file and land a fix just in time for Beta 3; however, that fix also undid most of the original performance gains, as was found by @felixarntz 😕 After some discussion with Felix, we then filed a two-part fix seeking to avoid |
@fabiankaegy @colorful-tones @lgladdy -- Apologies for not engaging in the conversation, I was a bit busy with the aforementioned issue last week. I won't be working tomorrow but hope to catch up with y'all on Tuesday! |
@ockham I appreciate the update. No apologies necessary. You’re obviously busy and I hope you enjoy your day off. ❤️ |
We discussed this a bit more elsewhere, but since that issue isn't (only) about Block Hooks, I wanted to bring back that conversation here. FWIW, I succeeded having a Mini Cart block inserted after the Navigation block. The containing Header template part doesn't have any modifications; it seems like the Navigation block falls back to a list of select pages (although not a "complete" page list; possibly a menu created by WooCommerce during setup?) |
Thank you for sharing that! :) How in the world did the Looking at the actual template part file here: https://github.com/WordPress/wordpress-develop/blob/6528d9840b6800edfb8e75c4924936bb14b3f31b/src/wp-content/themes/twentytwentyfour/parts/header.html#L18 there is no Ref to be found. Since that is env specific :O I am really surprised by those results. Really interesting & cool :) Thank you! |
Hi, following this Make post, I did some testing with the PHP It's working fine with |
Yeah, it is quite curious 🤔 My best guess is that the gutenberg/packages/block-library/src/navigation/edit/index.js Lines 245 to 252 in 7e3b80c
The counterpart logic for the frontend seems to be somewhere around here: gutenberg/packages/block-library/src/navigation/index.php Lines 435 to 455 in 7e3b80c
The Navigation block is a rather tricky beast. FWIW, it's on our TODO list for 6.5 (see updated issue description) to make it work with |
Thank you for reporting, and apologies for the late reply, @pagelab! I'll try to reproduce this on my end. |
@ockham Yes, there were no modifications, as in your picture (Customized: No). |
Thank you @pagelab! I haven't gotten around to investigating the issue just yet but will do so this week 😄 |
Update: I got a basic version of hooked blocks insertion into modified templates/parts/patterns to work in WordPress/wordpress-develop#5523. I've started to spin off smaller PRs to land individually; among them #55811 and WordPress/wordpress-develop#5608, which are ready for review. I plan to land those PRs this week and will continue to break out PRs, polish the code, and add test coverage. |
@pagelab I finally managed to test hooked block insertion into a We had one thought: Is it possible that the Group block you're trying to have the dynamic year block inserted into isn't a "direct" child of the Footer template part, but is instead part of a pattern that's used in the Footer? That could explain why it's not working for you, as the filter's Another idea: Since you're trying to insert your block as the |
Sorry for the delay, @ockham; I've missed the notification.
That is exactly what happened. I'm testing with TT4, and indeed it uses a pattern to define the contents of its default footer template part ( <!-- wp:pattern {"slug":"twentytwentyfour/footer"} /--> The
Yes, the |
Thank you for confirming, @pagelab (and apologies for my delay 😅 ) Somewhat relieved that it's at least expected behavior; although it indicates that it'd be desirable to maybe provide more context (not just the "immediate" surrounding one) 🤔 |
Update: A bit less progress in the past couple of weeks as I had to tend to some other things. I've filed WordPress/wordpress-develop#5712 to supersede WordPress/wordpress-develop#5523, as I wasn't quite happy with the function signature of I'm hoping to land that PR this week, albeit potentially only the parts that persist the information about hooked blocks in the anchor block's I also replied to some feedback on the make/core post and filed one ticket based on that feedback. |
I've been looking at making some of our WordPress plugins (particularly WooCommerce extensions) work well in a block-based world, and the Woo devs suggested that dropping some of our feedback here might be helpful. Let me know if you need any more information!
|
Update: I’ve spent most of last week exploring potential solutions to the sibling block alignment issue that was brought to my attention: I started out with a proof of concept that would set a hooked block’s Since there’s a risk that that might be too arbitrary or "overbearing", I also explored a correctly. WordPress/wordpress-develop#5835 that a block developer could use to write the code that's needed to set the Finally, I also tried a variation of the latter approach that would solely extend the existing I’ve tried to list pros and cons for the latter two approaches. I’ll continue exploring these options a bit more this week before deciding on how to proceed. |
Update: It was a pretty productive week for Block Hooks:
This is nicely reflected by a number of now-ticked checkboxes in the issue's TODO list 😄 As we're approaching the cut-off date for GB changes to be included in WP 6.5, my focus this week will be on finally unblocking WordPress/wordpress-develop#5726 (see). @swissspidy suggested adding a non-dynamic version of the Finally, @jsnajdr was kind enough to file a PR to introduce an |
Update: The last week saw a bit more of experimentation, with four new PRs opened, only half of which are probably worth pursuing in the short term. I spent some time last week trying to update GB's Block Hooks compatibility layer for WP < 6.4, which I thought might be a requirement to also add a compat layer for WP < 6.5. While it looks like I got that to work, it also turned out to be a distraction ❌ I then also tried to make hooked blocks insertion into the Navigation block work when used on WP 6.4 (rather than I then finally started working on setting the While working on this, I discovered that we the client really needs a way to ask the server for a list of hooked blocks for a given anchor block in a given context (e.g. within a Single template, or a header area template part). I spent a bit of time thinking what a REST API endpoint to that effect would look like and then started working on one 🚧 GB 17.7 RC 1 will be published on Wednesday, which is the last GB version whose code will be included in WP 6.5 by default. My plan is to finish work on |
Now that we are past the Beta 1 cut off point I'm removing this tracking issue from the 6.5 Project board. From now on the board should only contain individual bugs that we want to still fix before 6.5 gets released. |
Update: Near the beginning of the past two-week period, @tjcafferkey found and subsequently fixed a bug that had hooked blocks inserted twice into the Navigation block when running the GB plugin with WP The focus of the last two weeks was resolving the mismatch between editor and frontend for newly inserted anchor blocks in order to unblock injection of hooked blocks into modified templates (WordPress/wordpress-develop#5726). To that end, @tjcafferkey and I continued work on the client-side PR to set the We managed to merge the client-side PR, which was good enough to unblock hooked blocks injection into modified templates, allowing me to finally land WordPress/wordpress-develop#5726 🎉 However, it became apparent that we wouldn't be able to land the controller in time for WP 6.5's Feature Freeze. We were considering to let Core committers know about the issue and potentially seek "task (blessed)" status for it in order to continue work on it after Beta 1. That was until last Monday when @gziolo suggested an alternative approach, which turned out much better in a number of ways (didn’t require creating a new controller, kept logic contained on the server side). I managed to get a basic PR up and running by Monday evening, and thanks to Tom’s help, review, and testing, I was able to land it just ahead of Beta 1 🙂 I also reverted the client-side PR from our previous approach that we’d already merged, since we’re not going to need that now. There's a bit of follow-up work needed now that we've made some changes to how the |
Update: We landed the fix for the Navigation block. I then filed tickets and PRs for the feature requests I'd gotten recently:
Both were fortunately accepted for 6.5 and have already been committed 🎉 Since WordPress/wordpress-develop#6136 changed the signature of the Tom then kindly filed a fix for a bug that was reported two weeks ago. With WP 6.5 Beta 3 scheduled for tomorrow, I'll prioritize reviewing and landing the bugfix. That aside, I have to start writing the Dev Note for Block Hooks in 6.5. I'll also stand by for other bugs that might crop up. |
Update: I filed and merged a fix to display the Block Hooks toggle based on the presence of the I also published the Dev Note for Block Hooks in WP 6.5. I was alerted to two issues that seem to have been caused by our recent changes to Block Hooks and will need to investigate them: #59516 and https://core.trac.wordpress.org/ticket/60671. |
Update: Our major focus last week was on fixing two issues with garbled entities that were both caused by changes to Block Hooks (one of them affecting the Navigation block, the other one affecting template parts). We managed to fix them both in a similar way, by using a filter instead of an action in order to avoid an additional The fixes are on track for inclusion in RC2, pending a package sync for #59561, and a backport from Core There's a minor follow-up work in WordPress/wordpress-develop#6244 that I'll also backport to 6.5. Other than that, I'll keep my eyes open for any other potential bugs. I might also start working/helping with some Block Hooks related documentation. |
Update: Last week, I realized that as a side effect of using the Additionally, it was reported that creating a new Navigation post object via the REST API didn't work; this was fixed by @tjcafferkey. We've started filing a few issues to cover some of the changes we'd like to make to Block Hooks after 6.5, namely:
With RC3 scheduled for tomorrow, we're hoping to land the fix for the wrong |
Do you plan to open a new epic for WP 6.6, or should we put these items in a new section under Block API overview issue? |
Please create a new epic :D <3 and let's please close this one out when ready! |
Closing in favor of #60252. I've carried over the open issues and tickets from this issue and applied some preliminary gardening. I'll continue to do so over the next couple of days. @leewillis77 Apologies for not replying to your comment, I must've somehow missed it. I'll reply shortly over on the new issue! |
Block Hooks have been formerly know as Auto-inserting Blocks.
Plans for WordPress 6.5
ignoredHookedBlocks
metadata upon saving(Will be be fixed by the enabling Block Hooks for user-modified templates/parts/patterns.)(Edit: No it won't)allowedBlocks
field and control for users #53989allowedBlock
attribute that's currently used by a number of blocks; AFAICT, it's only handled on the client side, and basically passed through to theInnerBlocks
component as a prop. I'm a bit hesitant to use something like this as it seems currently really up to each individual block, with no standardization, especially on the server (e.g. in the shape of block-supports).Other
get_hooked_blocks()
to check impact wordpress-develop#5399"multiple": false
.useOnce
."multiple
field was originally introduced for a post editor context; it isn't really well-defined in a template/Site Editor, as @gziolo has observed.block.json
hasautoInsert
field? (Doesn't cover blocks that are auto-inserted programmatically.)The text was updated successfully, but these errors were encountered: