-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Pattern: process embeds #55979
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
Pattern: process embeds #55979
Conversation
Embed blocks inside patterns were not being processed when viewing a site. This focused change addresses that issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! The change is working well for me following the testing steps in #46556.
template-parts does a lot of other stuff in addition
You mean the content processing above the autoembed call? I don't think we need that or I expect it would have been added by now. It's not necessary for embeds to work.
Also to your question in the linked issue
I'm not sure why the embed HTML generation code isn't part of the embed block itself
This is likely because it's not needed for the embed block itself, as this issue only happens when it's added in places like template parts and patterns but perhaps @talldan has more context as he worked on the original workaround for block widgets
It might be good to audit whether things like
I think it's a historical WordPress thing. Embeds were always processed by the code that renders a post (before blocks existed), and the same approach had to be kept after blocks were introduced to ensure that classic and block embed content worked the same way. Especially given classic and block content can still co-exist in the same post. The same approach to processing embeds has now expanded to template parts, templates etc, as they're essentially also responsible for rendering a post. It could be something to revisit, I do like the idea of moving the processing to the block. |
Thanks @tellthemachines & @talldan
Yep, that's what I meant. Not specifically that it was required for embeds, but that it might have the same problem as embeds. It looks like convert_smileys and texturize both still work in patterns. I don't think shortcodes do, but i'm not sure how they should be written anyway - I could be doing it wrong. Happy to leave that can of worms out of scope. I don't have commit permissions btw - I'm not able to merge this change myself. |
Yeah no worries, that's fine! |
Embed blocks inside patterns were not being processed when viewing a site. This focused change addresses that issue.
What?
Process
embed
blocks inside a pattern file so that the media is embedded rather than just outputting a URL.Why?
Gutenberg lets you create patterns that include embed blocks. When the pattern is included in a template file the embed in the editor properly embeds and shows the embedded item. When the front-end is viewed the embed is not processed and instead it just shows a URL.
The front-end should display what Gutenberg does.
Additionally, this works for template-parts, and for patterns included by template-parts, just not for patterns included by templates.
This addresses #46556
How?
The PHP
render_callback
function for thecore/pattern
block now uses WP_Embed::autoembed to expand any autoembeds. I've copied how template-parts does the same thing, but template-parts does a lot of other stuff in addition, I don't think they are needed for embed purposes but maybe they should be applied too?Testing Instructions
Here's a git diff to emptytheme you can use to do steps 1-3: test.patch Download it to the root of your gb and then
git apply test.patch
Testing Instructions for Keyboard
N/A
Screenshots or screencast