-
Notifications
You must be signed in to change notification settings - Fork 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
Pasting WordPress.com site link turns into Embed block with "This block has encountered an error" #39935
Comments
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. |
@lancewillett This issue can be closed. Not sure how to request it,... |
I'll close it now that the new version is close to rolling out on WordPress.com that should fix this. |
I'm able to reproduce the error with a non WordPress.com URL: Trying:
Neither work when pasted into the block editor. This WordPress.com URL does work as expected: |
@lancewillett did you replicate with simple or atomic site? If atomic, what's the Gutenberg version? |
@lancewillett I had no problem with those links... |
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. |
I think it should be same to close it, then... |
Seeing this still happen with Gutenberg 8.0.0, directly via site's WP Admin ( I think if you copy-paste two links, you'll get a list like in your screenshot (#39935 (comment)), and if you copy-paste them individually, you'll get "embedding" prompt which fails. |
Pasting the URLs
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. |
@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. |
The @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. |
That was mainly a refactor that moved the function to another file. It was first introduced in D25893-code.
The rationale was that at that point we were not able to embed WordPress content in WordPress.com simple sites (#28326 (comment)). If that is no longer an issue I agree we can remove the function. |
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. |
IIUC, embeds work vaguely as follows in Gutenberg:
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 |
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" |
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, ***@***.***> 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
<#39935 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAVJABQI6APZ6UZTRIJ5DDR7MGQLANCNFSM4LDETEUA>
.
|
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. |
Found the relevant PR I think: WordPress/gutenberg#24090 Edit: This is what the relevant part looks like in that PR: https://github.com/WordPress/gutenberg/pull/24090/files#diff-56fcc4a2c51b3f80f9ae35c2b3b94b34R122-R133 |
The above PR was just merged and the logic for WordPress embed block discovery hasn't changed. |
Actually, things are a bit harder now 🤔 Before, we could unregister the With WordPress/gutenberg#24090, we can no longer unregister the |
I stand corrected: https://developer.wordpress.org/block-editor/data/data-core-blocks/#removeBlockVariations |
Okay, I can work with this. I'll file an upstream fix. |
@ockham since you're making changes with There is proper backwards compatibility with So you'll have to fill this property properly. If you need any help please let me know! |
WIP fix here: WordPress/gutenberg#24559 |
More in
|
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 🤞 |
@ockham I find it interesting that WordPress embed has already stopped working with Gutenberg Edge (8.9-rc1). 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? |
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 |
Actually we can close this issue (fixed in Gutenberg v8.9) and create a new if this is something that we should tackle. 😄 |
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: #39935 (comment) |
I can repro this in a vanilla Gutenberg install, so I think we'll need to report this in the GB repo. |
|
Steps to reproduce
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
The text was updated successfully, but these errors were encountered: