[abhishekfdd]

In the media grid and media modal, upload size errors show the filename twice: once in the upload-error-filename span of the tmpl-uploader-status-error template, and again inside the message, because wp.Uploader.errorMap.FILE_SIZE_ERROR inserts file.name into pluploadL10n.file_exceeds_size_limit.

This PR is an alternative approach to #11332. Thanks to Presskopp for the original report and patch.

Changes

• Adds a file_size_exceeded string to pluploadL10n in script-loader.php: "This file exceeds the maximum upload size for this site."
• Uploader.errorMap.FILE_SIZE_ERROR in wp-plupload.js now returns that string instead of interpolating the filename.

The shared tmpl-uploader-status-error template in media-template.php is unchanged. It still shows the filename in its own span for every error, and the message stays escaped with {{ data.message }}. #11332 removes the filename span and switches to {{{ data.message }}}, which drops the filename from all other upload errors (for example, disallowed file types) and stops escaping all error messages, including server- and plugin-supplied ones.

handlers.js (uploadSizeError(), used by the "Add New Media File" screen) is unchanged as well. It renders only the message, with no separate filename, so file_exceeds_size_limit and its %s remain correct there.

Notes

• FILE_SIZE_ERROR stays a function rather than becoming a plain string, so external code calling wp.Uploader.errorMap.FILE_SIZE_ERROR( file ) keeps working. Core's own caller already handles both forms.
• Trade-off: code that renders wp.Uploader.errors messages without the filename will no longer see the filename in the size error message. The file is still available on the error model (error.get( 'file' )).
• Out of scope: with client-side media processing, if plupload's max_file_size is filtered above wp_max_upload_size() (for example via plupload_default_settings), the upload-media pipeline's own size check rejects the file with a message that also contains the filename. That edge case is noted on the ticket as a follow-up.

Testing

Tested on a local wordpress-develop environment with a temporary mu-plugin that filters upload_size_limit down to 100 KB, and a second one that makes wp_handle_upload_prefilter return the error Blocked <b>by plugin</b> for a specific file. Both were removed afterwards and are not part of this PR.

Results in Media > Library (grid), compared across trunk, #11332, and this PR. Chromium uses the client-side (REST) upload pipeline, and WebKit uses the classic async-upload.php path.

Case	trunk	#11332	This PR
File over the size limit	Filename shown twice	Filename once (bold, inside the message)	Filename once (own line), message without it
Disallowed type (.exe, .svg)	Filename + message	Message only, no filename	Filename + message
Mixed batch (oversized + 2 disallowed)	Every error names its file	Only the size error names its file	Every error names its file
Server/plugin error containing HTML	Filename + tags shown as literal text	No filename, HTML rendered	Filename + tags shown as literal text

E2E: tests/e2e/specs/media-library-client-side-upload.test.js

• trunk: 16 passed
• Fix #64931 - duplicate filename display in media upload errors  #11332 (applied on current trunk): 3 failed, 13 passed. The failing assertions are the .upload-error-filename checks at lines 447, 643 and 893 ("shows an error for a disallowed file type", "surfaces a pipeline error with its message and file name", "reports the HEIC error when neither the browser nor the server can convert it"). Each fails with "element(s) not found".
• This PR: 16 passed

Also ran npm run build:dev, npm run grunt -- jshint:corejs (no issues), and phpcs on script-loader.php (no issues).

Trac ticket: https://core.trac.wordpress.org/ticket/64931

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Implementing the change, running the local and e2e test comparisons, and preparing this PR. I reviewed the code and test results and take responsibility for the change.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

Core Committers: Use this line as a base for the props when committing in SVN:

Props abhishekfdd, dhruvang21.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[dhruvang21]

LGTM