WordPress embed block working differently in the editor for different domains

[bobbingwide]

I'm raising this against oik-css initially for no other reason than the fact that I've already changed it for bobbingwide/oik-css#11.

While working on bobbingwide/oik-css#11, I noticed a number of other anomalies with WordPress embeds.

• When using the editor some of the embeds just display the blockquote link and caption
• Others display the embedded content.
• On the front end the blocks are correctly displayed.

I also had problems when trying to embed content from s.b/wordpress into s.b/cwiccer; both local sites.

Side note

If you take the URL for the fetch that failed with a 404 and paste it into the browser then you get

{"code":"rest_forbidden","message":"Sorry, you are not allowed to make proxied oEmbed requests.","data":{"status":401}}

But this is a red herring.
That's the expected response when the request is sent from the browser.

This is similar to the problem reported in Gutenberg issue number 22104, which has been closed as Unable to Reproduce.

Investigation required

There are two problems to investigate:

1. Why don't embeds from remote ( live ) sites show the embedded content in the editor?
2. Why are embeds from local sites (sub-directory installations) being rejected?

[bobbingwide]

In further checking, embed requests from sub domains of a WordPress Multi Site network do work in a local installation.

[bobbingwide]

2. Why are embeds from local sites (sub-directory installations) rejected?

Explanation for the local embeds failing

My guess for local subdirectory installs is that the http requests are failing due to sslverify being true and a certificate failure.
I confirmed this guess.

There is a filter that we can hook into in order to set 'sslverify' => false.

$args = apply_filters( 'oembed_remote_get_args', $args, $url );

I already have code in oik that implements a solution for local URLs
as part of the plugin update logic

add_filter( "http_request_args", array( "oik_remote", "bw_adjust_args" ), 10, 2 );

Perhaps it can be used for the oembed_remote_get_args filter as well.

And also take into account the latest functionality in WordPress 5.5 to check the environment type.
As this should only operate in a local development environment.

[bobbingwide]

I applied the change to the oik base plugin. The content is now being embedded, but it's the same as for the first screen capture.
We only see the Link and the (optional) caption. Here bw_jq_with_pullquote is being embedded from s.b/oikcom.

Now it's time to determine why the embedded content is not being displayed in the editor.

[bobbingwide]

Now it's time to determine why the embedded content is not being displayed in the editor.

Similar problems have been reported as Gutenberg issues. See WordPress/gutenberg#21029 (comment)

[bobbingwide]

I'm now going to transfer this issue to the oik base plugin since it's in that plugin that I've implemented the workaround to set sslverify to false for a local install.
Note: I need the workaround because I've never discovered the secret to getting SSL verification to work between local development installs.

[bobbingwide]

Now it's time to determine why the embedded content is not being displayed in the editor.

This screen capture shows the embedded content from https://s.b/wp55/2020/08/28/embed-me.

The iframe was there, but a style on the iframe was clip: rect(1px, 1px, 1px, 1px);
I couldn't see it, until I unchecked the style in the console.
I also needed to uncheck the position: absolute; to allow multiple embeds to display nicely.

I also needed to uncheck the position: absolute; to allow multiple embeds to display nicely.

The problem occurs in WordPress 5.5 and Gutenberg 8.8.0

[bobbingwide]

Discovered that unchecking the position: absolute element.style is the easiest way to workaround the problem.
I also seem to have rediscovered WordPress/gutenberg#14659.
For a recent test, the Write caption... entry field is a long way below the white box for the embedded content in the iframe.
The div class=wp-embed ... in the iframe is 610.4 x 224.6 but the iframe is 600 x 338.

[bobbingwide]

Explanation for the hidden iframe

It transpires that WP_oEmbed_Controller::get_proxy_item() is returning the HTML that contains the style that hides the iframe.

C:\apache\htdocs\cwiccer\wp-includes\class-wp-oembed-controller.php(229:0) 
WP_oEmbed_Controller::get_proxy_item(2) 61 2 
2020-08-28T14:11:58+00:00 0.726184 0.000326 
cf=parse_request 6695 8 0 2097152/2097152 256M F=381 data stdClass Object
(
    [version] => 1.0
    [provider_name] => WordPress 5.5 Multi Site
    [provider_url] => https://s.b/wp55
    [author_name] => wp
    [author_url] => https://s.b/wp55/author/wp/
    [title] => No me!
    [type] => rich
    [width] => 600
    [height] => 338
    [html] => <blockquote class="wp-embedded-content" data-secret="uemtLx0MHZ">
<a href="https://s.b/wp55/2020/08/28/no-me/">No me!</a>
</blockquote>
<iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" 
style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" 
title="&#8220;No me!&#8221; &#8212; WordPress 5.5 Multi Site" 
src="https://s.b/wp55/2020/08/28/no-me/embed/#?secret=uemtLx0MHZ"
 data-secret="uemtLx0MHZ" width="600" height="338"
 frameborder="0" marginwidth="0" marginheight="0" scrolling="no">
</iframe>
    [thumbnail_url] => https://s.b/wp55/wp-content/uploads/2018/12/torque-toons-gutenberg-maze-1280x1792.png
    [thumbnail_width] => 600
    [thumbnail_height] => 840
)

This is because of some logic in wp_filter_oembed_result.
If there's a blockquote in the result it changes the iframe tag to add the style.

if ( ! empty( $content[1] ) ) {
		// We have a blockquote to fall back on. Hide the iframe by default.
		$html = str_replace( '<iframe', '<iframe style="position: absolute; clip: rect(1px, 1px, 1px, 1px);"', $html );
		$html = str_replace( '<blockquote', '<blockquote class="wp-embedded-content"', $html );
	}

There's probably a good reason for this but it eludes me.
Apparently WordPress sites aren't trusted providers.
Well, how do we know it was a WordPress site?

This logic isn't run when the embed is performed locally as the data is returned earlier

// Short-circuit process for URLs belonging to the current site.
		$data = get_oembed_response_data_for_url( $url, $args );

		if ( $data ) {
			return $data;
		}

[bobbingwide]

Conclusion

To enable content from other local sites to be embedded I can use the filter function. See #158 (comment)

To enable content from remote sites to be displayed in the editor I could disable the processing in wp_filter_oembed_result
by removing the filter function added by default-filters.php

add_filter( 'oembed_dataparse', 'wp_filter_oembed_result', 10, 3 );

This nearly works but the second and subsequent embeds still show the blockquote link. Only the first has been hidden with display: none.

[bobbingwide]

This nearly works but the second and subsequent embeds still show the blockquote link. Only the first has been hidden with display: none.

The correct conclusion for this part of the problem - only displaying the link - has now been implemented in Gutenberg. See the above issue.

I can therefore close this issue when I’ve checked it out the fix for both parts of the problem.