Skip to content
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

Merged
merged 6 commits into from
Oct 19, 2018

Conversation

notnownikki
Copy link
Member

@notnownikki notnownikki commented Sep 19, 2018

Description

There were a couple of problems using Embed blocks as Reusable blocks.

  1. 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.

  2. The do_blocks filter ran before do_shortcode but after oembed, 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:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@@ -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.
Copy link
Member Author

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

Copy link
Contributor

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.

Copy link

@lkraav lkraav Oct 25, 2018

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.

Copy link
Contributor

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() ) {
Copy link
Member Author

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;
Copy link
Contributor

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.

Copy link
Member Author

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(
Copy link
Contributor

@talldan talldan Sep 20, 2018

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).

Copy link
Member Author

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.

Copy link
Contributor

@talldan talldan left a 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!

@notnownikki notnownikki added [Type] Bug An existing feature does not function as intended [Feature] Blocks Overall functionality of blocks labels Sep 21, 2018
@notnownikki notnownikki added this to the 4.0 milestone Sep 21, 2018
@notnownikki
Copy link
Member Author

@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!!

@notnownikki
Copy link
Member Author

Merged master to pick up the responsiveness changes there.

@notnownikki notnownikki requested a review from a team September 28, 2018 09:22
@mcsf mcsf modified the milestones: 4.0, 4.1 Oct 5, 2018
@gziolo
Copy link
Member

gziolo commented Oct 19, 2018

@talldan can you do another round of testing and merge it if everything goes well?

Copy link
Contributor

@talldan talldan left a 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 talldan merged commit 3168158 into master Oct 19, 2018
@talldan talldan deleted the fix/reusable-embed-block-crash branch October 19, 2018 09:50
@notnownikki
Copy link
Member Author

@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.

@gziolo
Copy link
Member

gziolo commented Oct 19, 2018

Kudos @talldan for doing another review so quickly, much appreciated 💯

@mtias mtias added the [Block] Embed Affects the Embed Block label Oct 19, 2018
antpb pushed a commit to antpb/gutenberg that referenced this pull request Oct 26, 2018
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Embed Affects the Embed Block [Feature] Blocks Overall functionality of blocks [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Weird behavior trying to save a WordPress embed as reusable block
7 participants