PDF uploads are treated like images: empty alt attribute and PHP notices

[worddean]

uploading a .pdf image in posts reads the following;
"this image has an empty alt attribute: its file name is.... .pdf"

I am a regular user since 1.5 versions of WP and this is my first bug, or error report. I tried downgrading, but it kept coming back error.

[audrasjb]

Hi @worddean, thank you for opening this ticket and welcome to WordPress Trac!

Self assigning for review.

[audrasjb]

@worddean could you please clarify which editor you are using when the issue occurs. I can reproduce it in the Block Editor but not sure it's what you are talking about.

For the moment, the block editor is not able to use PDF thumbnails. Worth reporting the issue about the weird message in Gutenberg GitHub repository.

[worddean]

Replying to audrasjb:

@worddean could you please clarify which editor you are using when the issue occurs. I can reproduce it in the Block Editor but not sure it's what you are talking about.

For the moment, the block editor is not able to use PDF thumbnails. Worth reporting the issue about the weird message in Gutenberg GitHub repository.

This is an example - ​http://istartonmonday.com/?p=75520 - as when you post a .pdf it shows and then you click on it to download

[audrasjb]

Reported upstream: ​https://github.com/WordPress/gutenberg/issues/18593

[afercia]

Seems to me after a page refresh (or navigating away and re-editing the post) there are also a couple PHP notices related to undefined index $image_meta['file']:

Notice: Undefined index: file in /srv/www/wordpress-develop/public_html/build/wp-includes/media.php 

on line 1535 and 1551. I can reproduce on 5.2 as well (haven't tested previous versions but it's probably there since 5.0?).

To start with, the media views shouldn't allow to select a PDF from the Image block, thus the attachment type should be filtered in the media modal.

[afercia]

This ticket was discussed during today's accessibility bug-scrub: part of the issue was already reported upstream on the Gutenberg repository. Other parts of this issue relate to the core media instead and should be addressed in core.

[afercia]

This ticket was discussed during today's accessibility bug-scrub: agreed this would be a nice fix for WordPress 5.5.

Reported also on the Gutenberg repo ​https://github.com/WordPress/gutenberg/issues/18593

[afercia]

This ticket was discussed during today's accessibility bug-scrub. It would need some prioritisation from the Media team and a Media focus lead yet-to-nominate for the 5.5 milestone.

[davidbaumwald]

This was discussed during today's scrub. With 5.5 RC1 approaching, this is being moved to Future Release. If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, please update the milestone accordingly.

[Mista-Flo]

Hi there,

I miss some points about this ticket, I need a better understanding.

Could you please provide steps to reproduce the issue @worddean?

Is this only affecting the block editor or also classic editor?

What do we want to fix here, what is the expected result?

EDIT: I better understand the issue when reading the Github issue actually, I'm not sure how to fix the issue though, the media library can be really tricky to modify.

[audrasjb]

As this issue didn't move during 5.6 alpha cycle, let's move it to Future release.

[joedolson]

The root problem here is that the uploader needs to be able to define the accept attribute. When you add an image, the modal only shows images; but you can upload anything, and then you can insert that new item into the image.

When the modal is limited to a class of media, the uploader should also be limited to that class of media.

[chaion07]

Hello @worddean and thank you for reporting this. We reviewed this ticket during a recent bug-scrub session. We are updating the milestone to Future Release. Thanks!

Props to @mukesh27

[joedolson]

The root cause here is that the uploader isn't getting an accept attribute that matches the current collection filters, so you can upload file types that aren't a match for what you can use in a given context.

The situation where a PDF is treated like an image is only caused because it's possible to do this; if we properly prevent uploads in these inappropriate places, then we don't have this issue.

[joedolson]

Moving to 6.5; this is too complex to get resolved in the remaining time this cycle.

[rajinsharwar]

So on this super OLD ticket, what I found is, this isn't really limited to the Image block. We can also upload PDFs in the Video block when we choose to add the file from the Media Library. ​https://prnt.sc/VbB6wxt2LxZJ

Again, if we try to do the same by clicking the "Upload" button, then we cannot do that, and get an error in the snack bar saying "Sorry, this file type isn't supported here". ​https://prnt.sc/RR1E-7TbfLmZ

So, this type of double behavior shouldn't be there as far as I think. It isn't logically/technically correct to add a PDF in an Image block, or a Video block. So, my suggestion is, to show an admin notice error when an unsupported file is being selected for a block from the Media Library popup, and block the file entry. We can show the same error like "Sorry, this file type isn't supported here" in an admin notice here: ​https://prnt.sc/9M2swXgNoblR when an unsupported file format is selected for the specific block.