-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Block Supports: Add (failing) surrounding HTML tests #25053
base: trunk
Are you sure you want to change the base?
Conversation
Size Change: 0 B Total Size: 1.17 MB ℹ️ View Unchanged
|
Maybe if we can find some sort of invariant 🤔 Can we assume that the 'actual' block wrapper always has a class name that identifies it? ( |
Hmm, seems like we're injecting that class name right there. So that might be a dead end. But there is some aspect of atomicity to blocks; after all, I think we're basically iterating over them (both client and server side, IIUC). So there's a point where we should be able to get the block (without any prepended/appended stuff) -- and I think that point is before Edit: Meh, OTOH, a lot of dynamic blocks really use |
Actually, maybe it isn't. I think we can potentially query by class name on |
The main problem there could be that we have a method to automatically add an auto-generated block class name (if We might re-consider providing this helper to ensure that we invariably have a block class name available to select the block by. cc/ @youknowriad |
Here's how I see things: There's no hard-rule saying that a block content is just a single element (wrapper), a block can render multiple elements or none as well both in the client and the server. That said, for 1- We can say, they hooks apply to all top-level elements of the block I believe right now, the frontend does 1 while the backed does 2 (need to be verified) but for me, 2 seems the most logical. |
Yeah, that might make sense (though for consistency's sake, we might want to enforce the same constraints on all blocks, rather than just the ones that are affected by The backend is special in that it can append scripts etc. The problem with 1. on the backend is then that we use the same logic to insert a bunch of classnames and styles that we don't really want in e.g. a |
I think frontend |
I'd like to second this. And put this third option up for consideration:
Riad recently suggested — and I think it's worth mentioning it here — that, now with |
Description
Add tests that block content with appended, prepended, and surrounding HTML is preserved and block classes are correctly added to the block content. This includes a test added and fixed in #25028 that will fail. It includes two additional tests for prepended and surrounding HTML that will fail and demonstrate some issues with the
gutenberg_apply_block_supports
function.It raises an interesting question about
render_callback
with regards to the block supports functionality. Can block supports functionality work well with arbitraryrender_callback
output?The failing tests (note that 1 is expected to be fixed with #25028):