Make WordPress Core

Opened 4 years ago

Last modified 2 years ago

#51417 new defect (bug)

TinyMCE stripping <picture> tags

Reported by: grzegorzjanoszka's profile Grzegorz.Janoszka Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.5.1
Component: TinyMCE Keywords: needs-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

We have new, way more efficient graphic formats coming - avif and webp. They are already supported by Firefox and Chrome. The recommended and backwards compatible method of inserting them is using a picture tag with an img fallback, for example:

<source srcset="example.avif" type="image/avif">
<source srcset="fallback.webp" type="image/webp">
<img src="fallback.jpg" alt="AVIF example with WebP and JPEG fallback">

Using the filter tiny_mce_before_init I can make TinyMCE accept the code if it is not surrounded by caption shortcode. Unfortunately the editor handles the [caption] code in javascript, the file is wp-includes/js/tinymce/plugins/wpeditimage/plugin.js
and it has a filter:

img = c.match( /((?:<a [^>]+>)?<img [^>]+>(?:<\/a>)?)([\s\S]*)/i );

which removes everything except a and img tags. So <picture> and <source> become stripped. There is no filter nor configuration to modify how that JS works.

I am not asking for a full <picture> support in WordPress. All I would love to see is to see TinyMCE not stripping <picture> and <source> tag when I place them inside caption. All the rest of WP support for AVIF can already be achieved using the existing filters like image_send_to_editor.

Attachments (1)

class-wp-rest-taxonomies-controller.php (9.7 KB) - added by paypressprinter 3 years ago.

Download all attachments as: .zip

Change History (6)

#1 @azaozz
4 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

I am not asking for a full <picture> support in WordPress.

Why not? It would be great to add imho :)

I've looked at what would it take to add full <picture> support to WordPress. The above is just one place that needs fixing, another is in wpautop(), and another is the block editor's image, gallery, media and text, etc. blocks. Then there is the question of adding "responsive images support" similar to srcset and sizes attributes in img tags. Of course, each of these would need a separate ticket.

Seems that adding support for <picture> to the rendering of [caption] shortcode in the classic editor will only need changes to the regex here: Note that the [caption] shortcode is rendered differently in the classic editor and on the front-end. The difference is only in the "wrapper" element(s), so perhaps replacing <img> with <picture> would not introduce back-compat problems.

#2 @azaozz
4 years ago

Thinking a bit more: <picture> will have to be "excluded" from wpautop, similarly to how <pre> is excluded, or chances are that there may be some stray <br> and/or </p> if there are line breaks before/after <source>.

#3 @Grzegorz.Janoszka
4 years ago

Yes, the caption shortcode is processed in two places - on the server (PHP code) and in the editor (JS). There first one is a similar regex in the PHP code of caption wrapper in wp-includes/media.php

if ( preg_match( '#((?:<a [^>]+>\s*)?<img [^>]+>(?:\s*</a>)?)(.*)#is', $content, $matches ) ) {

This one however can be dealt with by creating your own version of the [caption] shortcode. After few minutes of coding you have it done. Of course it would be awesome to have it update to accept picture and source tags, but we can make do.

The huge problem is the JS code of the editor which can't be changed at all by actions and filters.

#4 @SergeyBiryukov
4 years ago

  • Description modified (diff)

This ticket was mentioned in Slack in #core-media by antpb. View the logs.

2 years ago

Note: See TracTickets for help on using tickets.