Media uploader does not restrict file upload `accepts` parameters based on current context

[worddean]

Previously titled "PDF uploads are treated like images: empty alt attribute and PHP notices". Changed to reflect the actual issue that needs to be solved in order to fix this.

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.

[joedolson]

It continues to be complicated to resolve the root issue. Punting to 6.7; but I mean it this time.

[joedolson]

Bumping, again.

[sukhendu2002]

Reproduction Report

Description

This report validates whether the issue regarding uploading a PDF in the Image block and subsequent errors when deleting the file from the Media Library can be reproduced.

Environment

• WordPress: 6.7
• PHP: 8.2.29
• Server: nginx/1.27.2
• Database: mysqli (Server: 8.0.40 )
• Browser: Chrome 131.0.6778.69
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins: None activated

Steps to Reproduce

1. Navigate to a post in the Block Editor.
2. Add an Image block to the post.
3. Use the "Upload" option in the Image block to upload a PDF file.
4. Observe that the PDF thumbnail is displayed with errors.
5. Delete the uploaded PDF file from the Media Library.
6. Return to the post or refresh the editor.

Actual Results

• After uploading the PDF thumbnail is displayed with errors.
  • Warning**: Undefined array key "file" in **/var/www/src/wp-includes/media.php** on line **1759**
  • Deprecated**: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in **/var/www/src/wp-includes/media.php** on line **1759**
• After deleting the PDF from the Media Library, the block in the editor displays the error message:"This image has an empty alt attribute: its file name is... .pdf".

[inesmedem]

I was able to reproduce this issue on my local WordPress installation.

It’s unclear what the expected behavior should be. If the PDF is not displaying on the front end, the user should receive a clear error message or warning, along with guidance on how to correctly upload and use PDFs. Alternatively, if PDFs are not meant to be uploaded through the editor in this context, the option to do so should be restricted to prevent confusion.

[joedolson]

Sigh. This has no progress yet, for the what...sixth consecutive release? And so it's clear, it's not that I haven't looked into it...I just haven't made any useful progress. It's a problem with passing information back and forth between different JS contexts, and it's really entangled.

Moving to 6.9, because I'm forever optimistic.

[ruturajraval2305]

Hi team,

I've attached a patch that safely resolves the PHP warning
Prevents PHP warnings like:

Warning: Undefined array key "file" in wp-includes/media.php on line 1759
Deprecated: preg_match(): Passing null to parameter #2 ($subject) is deprecated

These occur because PDFs don't always contain a top-level 'file' key in their attachment metadata, yet some core image logic assumes it exists.

Patch Summary:

Adds isset() and is_string() checks around $image_metafile? before calling preg_match() and wp_basename().

Avoids unnecessary errors when rendering or cleaning up PDF thumbnails in blocks like ImageBlock, which don’t strictly validate MIME type before usage.

Keeps existing logic untouched when valid data is present.

[ruturajraval2305]

Patch is here