Perhaps should do some more to make sure this is the expected value?

What is this doesn't return the expected img?

Instead of the search text, this code include the alt text from the oEmbed image.

I'm curious why this block is not more heavily relying on oEmbed. It could be an embed block very similar to the others in core, and then most of the markup for the block could be static with a bare URL which is converted into the iframe. I suppose the only problem with this is the Giphy oEmbed response doesn't serve back an iframe, so we'd need to filter it as well to replace the img with an iframe. This filter is where the AMP-compat code could go as well.

@jeffersonrabb Could you address Weston's question?

Looking at this PR today—sorry I've let it sit so long.

Just to make sure I understand the question, @westonruter you're suggesting that oEmbed be used universally for the block, not just for AMP pages as implemented here?

@jeffersonrabb hey! Yes, I'm curious why oEmbed isn't being used generally for implementing Giphy support.

Do you have display_errors turned on?

The error:

Cannot use output buffering in output buffering display handlers in Unknown on line 0

This may be due to a warning being printed out during post processing of the output buffer. See ampproject/amp-wp#1915 for a fix planned in the plugin.

But if that is the case, I want to know what the underlying warning was to trigger the error. Is there any previous log entry with a warning perhaps?

There is this warning:

WARNING: The PORT_WORDPRESS variable is not set. Defaulting to a blank string.

Humm. That seems like it's something specific to your environment. Where is PORT_WORDPRESS being read?

Also, try applying this patch to your AMP plugin:

diff --git a/includes/class-amp-theme-support.php b/includes/class-amp-theme-support.php
index 507919ec..2dd8a6b4 100644
--- a/includes/class-amp-theme-support.php
+++ b/includes/class-amp-theme-support.php
@@ -1672,6 +1672,8 @@ class AMP_Theme_Support {
 	 */
 	public static function prepare_response( $response, $args = array() ) {
 		global $content_width;
+		ini_set( 'display_errors', 0 );
+
 		$prepare_response_start = microtime( true );
 
 		if ( isset( $args['validation_error_callback'] ) ) {

Otherwise, it seems there is an error happening in \AMP_Style_Sanitizer::ampify_ruleset_selectors() but it's not clear what it is from the stack trace.

Is also related to running out of memory as was reported by someone else in ampproject/amp-wp#1915? So what happens if you modify your WP_MEMORY_LIMIT in wp-config.php to:

define( 'WP_MEMORY_LIMIT', '128M' );

PORT_WORDPRESS is indeed something from our Docker environment. @jeffersonrabb you can bypass this via this section of https://github.com/Automattic/jetpack/blob/master/docker/README.md

You can set the following variables on a per-command basis (PORT_WORDPRESS=80 yarn docker:up) or, preferably, in a ./.env file in Jetpack's root directory.
PORT_WORDPRESS: (default=80) The port on your host machine connected to the WordPress container's HTTP server.

Opening #11583 to track making that warning display only at more actionable times to avoid false issues like this. Sorry about that folks!