Wp-calypso: Pasting WordPress.com site link turns into Embed block with "This block has encountered an error"

[kriskarkoski]

Steps to reproduce

1. Starting at URL: In the Block Editor paste a link to a WordPress.com site (tested using an Atomic site)
2. The link will be converted to an embed block that shows the error "This block has encountered an error and cannot be previewed"

What I expected

The link to appear as an embed (which I think we currently block) or a normal hyperlink

What happened instead

The embed shows an error on the back end and nothing on the frontend.

Browser / OS version

I don't believe this is affecting a specific combination, but I am using Chrome 79.0.3945.13 on OSX 10.

Screenshot / Video

Context / Source

manual-testing, #user-report

[simison]

I could replicate this with Gutenberg 7.3.0 but not on 7.4.0, so I suspect this is fixed upstream already and will get fixed on .com once we upgrade.

[millerf]

Confirmed...

[kriskarkoski]

Nice, thanks for testing @simison @millerf , I forgot about us being out of sync

[millerf]

@lancewillett This issue can be closed. Not sure how to request it,...

[kriskarkoski]

I'll close it now that the new version is close to rolling out on WordPress.com that should fix this.

[lancewillett]

I'm able to reproduce the error with a non WordPress.com URL:

Trying:

• https://make.wordpress.org/core/2020/03/03/wordpress-5-4-field-guide/
• https://ma.tt/2020/03/dont-mute-get-a-better-headset/

Neither work when pasted into the block editor.

This WordPress.com URL does work as expected:

• https://sensible.blog/2020/03/25/from-panic-to-bewilderment/

[simison]

@lancewillett did you replicate with simple or atomic site? If atomic, what's the Gutenberg version?

[millerf]

@lancewillett I had no problem with those links...

[simison]

We've since upgraded to Gutenberg v8.0 so that might've fixed this. I think we were on v7.7.1 around March 30th and before that on v7.3.0.

[millerf]

I think it should be same to close it, then...

[simison]

Seeing this still happen with Gutenberg 8.0.0, directly via site's WP Admin (/wp-admin/post-new.php):

I think if you copy-paste two links, you'll get a list like in your screenshot (https://github.com/Automattic/wp-calypso/issues/39935#issuecomment-626770387), and if you copy-paste them individually, you'll get "embedding" prompt which fails.

[simison]

It's something here I think:
https://github.com/WordPress/gutenberg/blob/4857ad58c1241b3d63d21a6880c989b85746c3dc/packages/block-library/src/embed/edit.js#L50-L61

[millerf]

On my local env:

On Wordpress:

I am not sure what is the difference with the wp-admin editor.

[millerf]

I don't see it on wp-admin...

[sirreal]

Pasting the URLs

• https://make.wordpress.org/core/2020/03/03/wordpress-5-4-field-guide/
• https://ma.tt/2020/03/dont-mute-get-a-better-headset/

Both links error on Simple sites (running Gutenberg 8.0.0, iframed and WP Admin).

I tested with a Gutenberg development build. Both links work fine:

I tested on Atomic and both links work fine. The issue is something specific to Simple sites.

[simison]

@sirreal did you test with Calypso iframe or directly in wp-admin? I see the errors happen with iframe on Simple site.

[sirreal]

@sirreal did you test with Calypso iframe or directly in wp-admin? I see the errors happen with iframe on Simple site.

My comment was unclear, I always observe this issue on Simple sites. It appears to be something specific to them.

[Addison-Stavlo]

Testing on simple, ephemeral JN, and local Gutenberg:

For simple, the url ends up in text in a paragraph block:

on the ephemeral JN, the embed block appears with its failure message:

Locally the link embeds as expected:

behaviors seem consistent between Iframe and wp-admin as well. I have not encountered the "this block as encountered an error and cannot be previewed" result as noted above though.

[yansern]

Seems like the issue is that core-embed/wordpress block is being unregistered after it was registered.

This leads back to unregisterWordPressEmbedBlock() in gutenberg-wpcom-embed.js.

[yansern]

The unregisterWordPressEmbedBlock() can be traced back to r201315-wpcom.

@mmtr What was the reason behind unregistering the WordPress embed block? If we do not need to do that anymore, then we could remove that function.

Here's a phab patch to remove it - D47668-code. If not, just abandon the patch.

[mmtr]

The unregisterWordPressEmbedBlock() can be traced back to r201315-wpcom.

That was mainly a refactor that moved the function to another file. It was first introduced in D25893-code.

@mmtr What was the reason behind unregistering the WordPress embed block?

The rationale was that at that point we were not able to embed WordPress content in WordPress.com simple sites (https://github.com/Automattic/wp-calypso/issues/28326#issuecomment-446836982).

If that is no longer an issue I agree we can remove the function.

[ockham]

Thanks @yansen, and @mmtr for the pointer!

I think #28326 is key here. It was a deliberate decision to remove the WordPress embed block, since we don't support non-WP.com WordPress embeds on WP.com out of security concerns. (As #28326 explains, this was the case even before the block editor.)

I think that the problem is now that if a user inserts an WordPress site URL, we still trigger the embedding behavior that tries to turn that URL into the corresponding block -- which is no longer there. The fix should be to "unregister" the embed transform for WordPress site URLs.

[ockham]

IIUC, embeds work vaguely as follows in Gutenberg:

• User enters URL
• Gutenberg creates a generic core/embed block with a preview (really just an <a href={ url }>{ caption || url }</a>) of the referenced URL (see)
• Gutenberg looks at that URL and decides whether it can turn the generic core/embed one into a more specific one (which will have a better preview of the URL, e.g. the familiar layout of a tweet or an Instagram post).
• Gutenberg _also_ looks at the preview HTML to determine whether it contains class="wp-embedded-content" to determine whether the URL points to a WordPress page (since those cannot be simply determined by looking at the URL). If it is, it uses the core-embed/wordpress block.

The relevant code seems to be here: https://github.com/WordPress/gutenberg/blob/af53147b3adf1951aeac7bdbbf3b7a574d8bc610/packages/block-library/src/embed/util.js#L113-L128

If the core-embed/wordpress block is unregistered, that latter part fails.

[ockham]

I _think_ that the correct fix needs to be made against Gutenberg (in https://github.com/WordPress/gutenberg/blob/af53147b3adf1951aeac7bdbbf3b7a574d8bc610/packages/block-library/src/embed/util.js): If a "specialized" embed block isn't available, don't attempt to transform the "generic" core/embed block into it. (I think this fix is _necessary_, but probably not _sufficient_.)

[simison]

I think there's some work going on in core to turn all those specific embed
blocks into variations of that base block.

Would they help?

On Thu, 6 Aug 2020, 23:24 Bernie Reiter, [e-mail] wrote:

I think that the correct fix needs to be made against Gutenberg (in
https://github.com/WordPress/gutenberg/blob/af53147b3adf1951aeac7bdbbf3b7a574d8bc610/packages/block-library/src/embed/util.js):
If a "specialized" embed block isn't available, don't attempt to transform
the "generic" core/embed block into it. (I think this fix is necessary,
but probably not sufficient.)

This might still give us a "generic" core/embed block for a WordPress
URL, even if in this case, we might really just want to show the URL (and
not embed/preview at all). For cases like these, maybe we need a mechanism
to unregister embeds altogether (rather than just their individual block
types).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Automattic/wp-calypso/issues/39935#issuecomment-670173932,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAVJABQI6APZ6UZTRIJ5DDR7MGQLANCNFSM4LDETEUA
.

[ockham]

I think there's some work going on in core to turn all those specific embed
blocks into variations of that base block.

Would they help?

I'm not sure TBH. That work might be largely orthogonal -- I assume there will still be logic to turn a "generic" embed block into a WordPress embed block, so we'll still need to do something about that.

[ockham]

I think there's some work going on in core to turn all those specific embed
blocks into variations of that base block.

Found the relevant PR I think: https://github.com/WordPress/gutenberg/pull/24090

Edit: This is what the relevant part looks like in that PR: https://github.com/WordPress/gutenberg/pull/24090/files#diff-56fcc4a2c51b3f80f9ae35c2b3b94b34R122-R133

[ntsekouras]

I assume there will still be logic to turn a "generic" embed block into a WordPress embed block

The above PR was just merged and the logic for WordPress embed block discovery hasn't changed.

[ockham]

I assume there will still be logic to turn a "generic" embed block into a WordPress embed block

The above PR was just merged and the logic for WordPress embed block discovery hasn't changed.

Actually, things are a bit harder now :thinking: Before, we could unregister the core-embed/wordpress block (and I would've needed to add logic to packages/block-library/src/embed/util.js to check whether that block is registered, before attempting to transform into it).

With WordPress/gutenberg#24090, we can no longer unregister the core-embed/wordpress block, since it has become a block variation of the core/embed; and I don't think there's an API to unregister a singular variation of a block (yet).

[ockham]

I don't think there's an API to unregister a singular variation of a block (yet).

I stand corrected: https://developer.wordpress.org/block-editor/data/data-core-blocks/#removeBlockVariations

[ockham]

Okay, I can work with this. I'll file an upstream fix.

[ntsekouras]

@ockham since you're making changes with embed please keep in mind that the logic for detecting a possible better embed match has changed and is using providerNameSlug field: https://github.com/WordPress/gutenberg/blob/8474a2edcf302b7a383839801156d077cf7810c9/packages/block-library/src/embed/util.js#L108.

There is proper backwards compatibility with core but I've noticed in .com the above field providerNameSlug is not filled by some middleware you have there, I guess. This will cause problems with older embed blocks as it compares them with current version and the providerNameSlug adds css classes based on provider, that makes them invalid.

So you'll have to fill this property properly. If you need any help please let me know!

[ockham]

WIP fix here: https://github.com/WordPress/gutenberg/pull/24559

[lsl]

More in

• D47668-code
• D48438-code

[ockham]

This has been addressed by WordPress/gutenberg#24559 (which will probably be released as part of the next Gutenberg release, v8.9). Once that release is installed on WP.com, and once we land D48267-code, the issue should be fixed :crossed_fingers:

[david-szabo97]

@ockham I find it interesting that WordPress embed has already stopped working with Gutenberg Edge (8.9-rc1).
Since D48267-code is not merged (and I'm not on sandbox), it shouldn't work. I guess.

I tested it on Simple site + Gutenberg edge sticker.

As you can see I embedded multiple WordPress links (links from this discussion) and it's not showing an error, but it's not embedding it as a WordPress embed variation either. Since D48267-code isn't deployed, it should embed it as a WP embed variation. Am I missing something?

[david-szabo97]

EDIT:
~TLDR: We need this patch: D48267-code~
TLDR: oAuth embed auto discovery embeds the iframe

Figured it out. It's actually being embedded:

But you can see an inline style there on the iframe: position: absolute;clip: rect(1px, 1px, 1px, 1px); which is basically hiding the embedded content.

wp-embed.js is supposed to remove that inline style, but since we don't have that on WP.com, it's not happening.

[david-szabo97]

A fix to get rid of autoembedding:

remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );
remove_filter( 'widget_text_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );

Since many sites are probably using bare links (which are being replaced by autoembedding), this is a really bad idea to do right now. I'm not sure if we should even think about removing autoembed feature of WP from WPcom.

cc @ockham

[david-szabo97]

Actually we can close this issue (fixed in Gutenberg v8.9) and create a new if this is something that we should tackle. 😄

[ockham]

Thanks a lot for your research, @david-szabo97 !

I also think we can close this issue for now. I agree that we probably don't want to get rid of the auto-embedding -- that behavior likely predates Gutenberg, so it's probably established at this point.

I'll file an issue for this part though since this seems wrong: https://github.com/Automattic/wp-calypso/issues/39935#issuecomment-686524172

[ockham]

I'll file an issue for this part though since this seems wrong: #39935 (comment)

I can repro this in a vanilla Gutenberg install, so I think we'll need to report this in the GB repo.

[ockham]

I can repro this in a vanilla Gutenberg install, so I think we'll need to report this in the GB repo.

https://github.com/WordPress/gutenberg/issues/25344