VideoPress: Revisit block extension behavior

[mmtr]

Currently, the VideoPress extension for the block editor extends the core/video block in order to use the VideoPress player in both the editor and the published view if the video has been transcoded by VideoPress.

Since we're saving a different block output into the post content from whats core/video saves, we could lead to failures when the block markup is validated:

• When Jetpack is deactivated.
• On environments that can edit existing posts but where the Jetpack blocks are not loaded (i.e. WordPress mobile apps).

We should revisit the current approach, since this might not result in a great experience. One option is to change the block output server-side only and leave the core/video block unaltered. Another approach is to deactivate core/video and register a new block so we avoid conflicts.

Unfortunately, we should keep maintaining the current behavior as a deprecated version of the core/video block in order to handle video blocks that have been created until the new approach is available.

[creativecoder]

@lessbloat @cathymcbride I'm adding this one to the Manage backlog for increased visibility.

This is a long standing issue and has to do with how the VideoPress block was implemented to override the Core video block markup. I see at least one related user report.

Related Gutenberg Mobile issue: (Videos added/edited on the web don't load in mobile editor

I can replicate the problem by following the instructions in that issue.

[creativecoder]

More background discussion: pafL3P-pg-p2

[hypest]

Hello 👋! Is there any progress or maybe new understanding or plan for this ticket on the Jetpack side of things? Thanks!

[cathymcbride]

I'm not sure there has been any movement on this. @jeherve, do you?

[jeherve]

I don't believe the Video block is on anyone's radar at the moment; it's still in the Manage backlog as you can see on the project boards.

[jeherve]

Closing as this was addressed with the recent improvements made to the VideoPress block.