-
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
Fix WordPress block resolution and embeds as reusable blocks #10035
Conversation
@@ -249,7 +249,7 @@ function do_blocks( $content ) { | |||
|
|||
return $rendered_content; | |||
} | |||
add_filter( 'the_content', 'do_blocks', 9 ); // BEFORE do_shortcode(). | |||
add_filter( 'the_content', 'do_blocks', 7 ); // BEFORE do_shortcode() and oembed. |
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.
Allows embed blocks to be used as reusable blocks
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.
I think this change broke the dynamic blocks in the frontend if you have any meta box in the editor.
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.
@youknowriad this change has even more consequences. For one, it completely invalidates gutenberg_wpautop()
who will have has_blocks()
check always fail (because do_blocks()
already killed markup), causing gutenberg_wpautop()
to immediately execute wpautop()
on everything. I wouldn't be surprised if that's what's causing #11031 and other new broken autop rendering issues popping up now.
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.
yes, I noticed too. We're working on fixes in #11050
@@ -65,7 +69,7 @@ export function getEmbedEdit( title, icon ) { | |||
const switchedPreview = this.props.preview && this.props.attributes.url !== prevProps.attributes.url; | |||
const switchedURL = this.props.attributes.url !== prevProps.attributes.url; | |||
|
|||
if ( switchedURL && this.maybeSwitchBlock() ) { | |||
if ( ( switchedURL || ( hasPreview && ! hadPreview ) ) && this.maybeSwitchBlock() ) { |
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.
Try switching the block if the URL changes, or we get a preview. To switch to a WordPress block, we need the preview.
const previewDocument = document.implementation.createHTMLDocument( '' ); | ||
previewDocument.body.innerHTML = html; | ||
const iframe = previewDocument.body.querySelector( 'iframe' ); | ||
|
||
if ( ! iframe ) { | ||
return; | ||
return this.props.attributes.className; |
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.
This function could be refactored a bit to avoid so many returns. Could remove this if statement, change the one below to if( iframe && iframe.height && iframe.width )
, and then move the remaining return this.props.attributes.className;
to the very last line of the function.
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.
Gah yes, I missed a refactor pass!
@@ -128,7 +132,22 @@ export function getEmbedEdit( title, icon ) { | |||
if ( includes( html, 'class="wp-embedded-content" data-secret' ) ) { | |||
// If this is not the WordPress embed block, transform it into one. | |||
if ( this.props.name !== 'core-embed/wordpress' ) { | |||
this.props.onReplace( createBlock( 'core-embed/wordpress', { url } ) ); | |||
this.props.onReplace( | |||
createBlock( |
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.
Not really a thing to fix in this PR, but I thought i'd mention that it'd be tidier if maybeSwitchBlock
returned the value of createBlock so that it becomes purer and somewhat side-effect free (depending on what createBlock does).
Its caller could call this.props.onReplace with the result (if there is one).
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.
Yes, too many side effects caused this problem. Separating the preview->attribute generation from the code that set the attributes let us fix this, same should be done here. Once this is in I'll do it as a chore
PR.
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.
I'm not all that familiar with some of the code being changed, so I think it'd worth getting someone with more familiarity to review as well.
I tested though and the fix works well. Also seems like it'd be a good fix to get in, as the editor crashes whenever hovering over the reusable block in the block switcher (I imagine that's the preview), so it's quite a nasty bug!
@talldan thanks :) I've added it to the 4.0 milestone so it should get into the review queue for other peeps. There will be some happy people on my twitter timeline once 4.0 gets out!! |
Merged |
@talldan can you do another round of testing and merge it if everything goes well? |
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.
I gave it a good test and no issues, and the explanations make sense.
A few things in the embed block could do with a bit of a tidy up, but that's not really the fault of this PR - so lets get it in!
@talldan an embed block refactor and tidy and unit test is on my list of stuff to do. It's kinda of grown organically... like a mold. |
Kudos @talldan for doing another review so quickly, much appreciated 💯 |
…ss#10035) * Fix WordPress block resolution and embeds as reusable blocks * Let's not infinitely recurse and crash. * Reduce the amount of return points * Doc update
Description
There were a couple of problems using Embed blocks as Reusable blocks.
Pasting a WordPress URL created an embed block, but did not resolve the block to a WordPress block. This meant that if you tried to edit a post with the resulting block in it, and converted it to a Reusable block, it would crash. The crash was caused because the new block had the preview data already available, and so the block resolution would kick in and try to replace it with a WordPress block, but
this.props.onReplace
was not available, so, we got the crash seen in Weird behavior trying to save a WordPress embed as reusable block #9938 . This is fixed in this PR by making sure that the block resolution works and carries across all attributes set on the Embed block when we're embedding WordPress content. It's more complex for WordPress embeds because we need to get back the embed preview to detect it's WordPress and switch to the correct block. We can't go by the URL as we can for the other blocks because there is no regex that can determine a URL is WordPress.The
do_blocks
filter ran beforedo_shortcode
but afteroembed
, so reusable embed blocks did not get their URL processed. This PR changes the priority to fix this.Fixes: #9938
How has this been tested?
Run through the steps in #9938
The embed block should become reusable, and render correctly on the published post.
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: