Site Editor Compatibility: Podcast Player block issues in editor and front end views

[andrewserong]

In the new site editor in Gutenberg (/wp-admin/admin.php?page=gutenberg-edit-site), there are some issues with the Podcast Player block within the editor and on the front end of the site. The issues include:

• Within the editor, the styling and behaviour for the player doesn't appear to be rendering (perhaps an issue with how the block works with the site editor iframe?)
• On the front end of the site, the player itself isn't being rendered / loaded

Steps to reproduce the issue

1. Grab an RSS feed from your favourite podcast (here's one for Distributed.blog: https://distributed.blog/category/podcast/feed/)
2. With the Gutenberg plugin active (>=10.4.0-rc1), activate a block-ready theme (like tt1-blocks)
3. In the site editor, insert a Podcast Player block into the Footer template part
4. Add the feed URL from your favourite podcast and click embed
5. Observe that the player isn't rendered correctly.
6. Save the template part and view the front end of your site
7. Observe that the podcast player interface isn't loaded / rendered

What I expected

• The player to be available within the editor canvas and to be styled correctly.
• The player to be available on the front end of the site

Editor view	Front end view

What happened instead

• The player is not available within the editor canvas
• The player was not rendered on the front end of the site

Editor view	Front end view (note missing player)

[ramonjd]

It looks like podcast player enqueues assets from the mediaelement core lib: https://github.com/WordPress/WordPress/tree/master/wp-includes/js/mediaelement

So we're going to need a way to ensure all block dependencies can be copied into the site editor context.

I'm starting to think core should be offering a solution to this.

[sdixon194]

I just did some more testing in preparation for the 9.9 release, but it looks like this issue is happening for me again 🤔 @ramonjd would you be able to take another look?

[ramonjd]

I just did some more testing in preparation for the 9.9 release, but it looks like this issue is happening for me again 🤔 @ramonjd would you be able to take another look?

Thanks for the ping @sdixon194

Could you fill me in on how you tested this?

I just checked with release candidate (9.8.1-918672803-g67226f6) and bleeding edge (9.9-alpha-974918035-gf25064c), and embedding the podcast player block works as expected on the site editor and frontend end (using Gutenberg 10.9.1)

Edit: Working okay in Atomic, but in WPCOM I do see this:

I'll try to debug. It was working when we tested, honest! :D

[ramonjd]

As far as I can tell, the Site Editor in WPCOM is no longer loading mediaelement-css and wp-mediaelement-css, which are required for the podcast player to function correctly.

I'm not yet sure when or how this changed as we tested in WPCOM at the time and it was working.

My only guess is that it's due to a Gutenberg change, but I can't be sure. Still looking...

wp_enqueue_style( 'wp-mediaelement' ); is being called in the podcast-player.php

🤷

[ramonjd]

Okay, I think it's because we haven't implemented the changes required by WordPress/gutenberg#31873, which was merged after our changes.

We need to add 'style' => 'wp-mediaelement', to the register_block function.

Now it works

cc @glendaviesnz for sanity check

Edit: So I think the solution is to add that line, since WPCOM is running the required Gutenberg version (10.9.1) in order for it to work. It looks like we can roll back the workaround in maybeCopyElementsToSiteEditorContext for WPCOM at least, but for sites running previous versions of Gutenberg that support site editor, we may want to leave it in until we can fully test.

Leaving in maybeCopyElementsToSiteEditorContext shouldn't affect WPCOM as the method checks to see if the enqueued asset id is present before trying to add it in again.

[sdixon194]

Brilliant, nice sleuthing and thanks for the quick fix!