close

Make WordPress Core

Opened 4 months ago

Closed 4 months ago

#64305 closed defect (bug) (fixed)

Regression: Hidden async-upload input marked required in WP 6.9 RC3 prevents post publish

Reported by: yagniksangani's profile yagniksangani Owned by: wildworks's profile wildworks
Milestone: 6.9 Priority: normal
Severity: major Version: 6.9
Component: Posts, Post Types Keywords: has-patch reporter-feedback dev-feedback
Focuses: ui, accessibility, administration Cc:

Description (last modified by sabernhardt)

Issue Summary

In WordPress 6.9 RC3, the hidden file input field used for media uploads
(<input type="file" name="async-upload" id="async-upload">)
now contains a required attribute. Since this input is hidden in the post
editor UI, browsers block form submission and display an error:

"An invalid form control with name='async-upload' is not focusable."

This prevents publishing or updating posts, pages, and custom post types.

Steps to Reproduce

  1. Install WordPress 6.9 RC3 (clean installation or update from previous version)
  2. Edit or create a new post or custom post type
  3. Attempt to click Publish
  4. Observe browser console and publish failure

Expected Behavior

Publish should work normally, as in WP 6.8.x, where the async-upload input
does not have a required attribute.

Actual Behavior

The async-upload input is hidden but marked required → HTML5 validation blocks publish.

Comparison

Version async-upload required attribute Publish status
WP 6.8.3 No required Works
WP 6.9 RC3 required="required" ❌ Publish fails

Environment

  • WP 6.9 RC3
  • Tested with default theme (Twenty Twenty-Five) and no plugins
  • Chrome / Firefox both affected

Console Error

browser console screenshot

Attachments (3)

console-error-ss.png (27.8 KB) - added by yagniksangani 4 months ago.
browser console screenshot
env-issue-ss.png (83.2 KB) - added by yagniksangani 4 months ago.
envira gallery lite issue reproduce
sol-issue-ss.png (91.7 KB) - added by yagniksangani 4 months ago.
Soliloquy reproduce issue

Download all attachments as: .zip

Change History (39)

Image @yagniksangani
4 months ago

browser console screenshot

#1 Image @sabernhardt
4 months ago

  • Description modified (diff)

Image

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


4 months ago

#3 Image @desrosj
4 months ago

  • Milestone changed from Awaiting Review to 6.9
  • Version set to trunk

Moving to the 6.9 milestone for investigation.

The required attribute appears to have been introduced in [60449].

#4 Image @adamsilverstein
4 months ago

I was not able to reproduce this on trunk. I will try with the WordPress 6.9 RC3 zip.

#5 Image @adamsilverstein
4 months ago

I tried as fresh install from the RC3 zip and publishing a post went smoothly.

@yagniksangani Anything else you can share about your environment or steps to reproduce?

#6 Image @huzaifaalmesbah
4 months ago

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

  • WordPress: 6.9-RC3
  • PHP: 8.4.12
  • Server: nginx/1.29.1
  • Database: mysqli (Server: 9.4.0 / Client: mysqlnd 8.4.12)
  • Browser: Chrome 142.0.0.0
  • OS: macOS
  • Theme: Twenty Twenty-Five 1.3
  • MU Plugins: None activated
  • Plugins:
    • Test Reports 1.2.1

Actual Results

  1. ❌ I could not reproduce the issue.

#7 Image @wildworks
4 months ago

Since this input is hidden in the post editor UI, browsers block form submission and display an error:

I think this input field is typically only rendered on the media screen, so I don't understand why the error occurs in the post editor.

#8 Image @parthvataliya
4 months ago

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

  • WordPress: 6.9-RC3-61308-src
  • PHP: 8.2.26
  • Server: nginx/1.27.3
  • Database: mysqli (Server: 8.4.4 / Client: mysqlnd 8.2.26)
  • Browser: Chrome 140.0.0.0
  • OS: Linux
  • Theme: Twenty Twenty-Five 1.3
  • MU Plugins: None activated
  • Plugins:
    • Test Reports 1.2.1

Actual Results

  1. ❌ I could not reproduce the issue.

#9 Image @madhavishah01
4 months ago

I tested this on a fresh setup of WordPress 6.9 RC3 and PHP 8.4. I created a couple of new posts and both published without any issues. I’m not able to reproduce the problem on this version.

Image @yagniksangani
4 months ago

envira gallery lite issue reproduce

Image @yagniksangani
4 months ago

Soliloquy reproduce issue

#10 Image @yagniksangani
4 months ago

@adamsilverstein @madhavishah01 @parthvataliya @wildworks @huzaifaalmesbah

To reproduce the issue easily, please install any of the following plugins and try creating a gallery. When you click Publish, Save, or Update, the buttons do not work. The browser console also shows related errors.

Try with one of these plugins to reproduce the issue:
https://wordpress.org/plugins/envira-gallery-lite/ OR
https://wordpress.org/plugins/soliloquy-lite/

This issue occurs on WordPress 6.9 RC3, but everything works correctly on WordPress 6.8.3.

It appears to be happening because, in WordPress 6.9 RC3, the core code adds required to the file upload input here:

<input type="file" name="async-upload" id="async-upload" required>

This required attribute was not present in 6.8.3, and when added, it blocks publishing/updating if no file is uploaded, causing the buttons to fail.

Attached screenshots:
env-issue-ss.png​
sol-issue-ss.png​

#11 Image @wildworks
4 months ago

@yagniksangani Thank you for the detailed exploration! I realized the underlying problem.

Steps to reproduce

  • Install and activate Envira Photo Gallery plugin
  • Access Envira Gallery > Add New Gallery
  • Just click the Puglish button
  • Nothing happens and your browser console logs the message An invalid form control with name='async-upload' is not focusable.

I think this problem occurs when the media_upload_form() function is executed within a form element.

In fact, Envira Photo Gallery plugin executes such code: https://github.com/gnanet/envira-gallery-lite/blob/c41a5348511c0b39f57719d2e62ac69beb9a5007/includes/admin/partials/metabox-gallery-type.php#L32

This issue can affect many consumers, so I think it should be fixed in 6.9 if possible, or at least 6.9.1.

cc @ocean90 @joedolson @mukesh27

Image

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


4 months ago

#13 Image @ravichudasama01
4 months ago

I tested it on a fresh install of 6.9 RC3 with the Envira Gallery plugin, and I get the same error in the console: ‘An invalid form control with name="async-upload" is not focusable.’ The Publish button does nothing.

Kindly refer below screenshot:-
https://www.awesomescreenshot.com/image/57616599?key=108008d8989f08287a0cb9dad6bc121a

#14 Image @madhavishah01
4 months ago

@yagniksangani Thank you for the Detailed Description

I tried the second plugin (Soliloquy Lite) on a fresh 6.9 RC3 install, but I wasn’t able to reproduce the issue. My slider got published in one go and there were no console errors.

Kindly refer below screenshot:-
https://www.awesomescreenshot.com/image/57617325?key=e6b0ec6b9ff23a5e49841be36e395b52

Image

This ticket was mentioned in Slack in #core-test by yagniksangani. View the logs.


4 months ago

#16 Image @wildworks
4 months ago

I tried the second plugin (Soliloquy Lite) on a fresh 6.9 RC3 install, but I wasn’t able to reproduce the issue.

In my testing, the issue can also be reproduced with the Soliloquy Lite plugin.

#17 follow-up: Image @sabernhardt
4 months ago

Could the required attribute be added only if ( 'media' === get_current_screen()->id )?

Image

This ticket was mentioned in PR #10558 on WordPress/wordpress-develop by @adamsilverstein.


4 months ago
#18

  • Keywords has-patch added; needs-patch removed

#19 in reply to: ↑ 17 Image @adamsilverstein
4 months ago

Replying to sabernhardt:

Could the required attribute be added only if ( 'media' === get_current_screen()->id )?

Good idea @sabernhardt - I tried adding this in https://github.com/WordPress/wordpress-develop/pull/10558

Last edited 4 months ago by adamsilverstein (previous) (diff)

#20 Image @adamsilverstein
4 months ago

  • Keywords reporter-feedback added

Testing with Envira Gallery I verified the error is fixed by the PR.

#21 Image @wildworks
4 months ago

Could the required attribute be added only if ( 'media' === get_current_screen()->id )?

I think whether or not it depends on the media screen seems a bit unstable. This may be an edge case, but try the following steps.

Since this is a JS-less upload form, the input element needs the required attribute to prevent form submission when no file has been uploaded, but with PR 10558 applied the required attribute disappears.

Ideally, the required attribute should only be added when the HTML upload UI is visually displayed. In other words, the required attribute should probably be removed dynamically via JS.

I can't think of any specific code right now, but I'm personally leaning towards reverting [60449] in the 6.9 release in order to implement it after more careful testing.

#22 Image @krupajnanda
4 months ago

@yagniksangani Thanks for the report!

@adamsilverstein The issue with the Envira Gallery plugin mentioned earlier has been addressed with the PRhttps://github.com/WordPress/wordpress-develop/pull/10558. I tested that it works as expected now. So the fix works for standard media screens, and the plugin-specific problem is resolved. ✅

However, it’s still a good idea to carefully test the legacy uploader and other similar plugin workflows before finalizing the fix in 6.9, or consider implementing conditional logic for the required attribute based on the actual UI being displayed. As @wildworks mentioned we may have many more edge cases here.

#23 Image @wildworks
4 months ago

Another intermediate solution is to simply remove the required attribute from the input element, so that:

Case 1: When the multi-file uploader is enabled

The media uploader should continue to work as before in any environment, including the Envira Gallery plugin.

Case 2: If the browser uploader is enabled and your browser has JS enabled

If no file is attached, the JS will disable the upload button, so the form will not be submitted.

Case 3: If the browser uploader is enabled and your browser has JS disabled

In this case, the form will be submitted without attaching a file, but validation will be performed on the server side, and the message "No file was uploaded." will be displayed. Since cases where JS is disabled are rare these days, I think this case is acceptable.

#24 Image @adamsilverstein
4 months ago

That makes sense @wildworks - I would support a revert for now.

#26 Image @wildworks
4 months ago

I submitted a new PR 10564 based on this comment.

#27 Image @ellatrix
4 months ago

  • Keywords commit added

At just a few days before the release, it's probably good to get a few more eyes and agreement on it. But to me this looks straightforward: let's simply revert this problematic one line as suggested by Aki and reopen #63561. The other changes in that commit don't depend on it being required, so it looks good to me.

Last edited 4 months ago by ellatrix (previous) (diff)

Image

@krupajnanda commented on PR #10564:


4 months ago
#28

@t-hamano I have tested this PR and verified all these scenarios mentioned here.

  • Default Media Uploader ✅
  • Legacy Media Uploader ✅
  • Backward compatibility with third-party plugin. Eg. Envira gallery ✅
  • Also, did a quick round of regression testing for different scenarios like drag-and-drop images, image short-code, multi file upload functionality etc just to ensure everything else is working as expected. ✅

Please confirm if there is anything I have missed. 🙇🏻‍♀️

#29 Image @immeet94
4 months ago

https://github.com/WordPress/wordpress-develop/pull/10564
I tested this PR and confirmed that all the following scenarios work correctly:

Default WordPress Media Uploader — ✅
Legacy / Classic Media Uploader — ✅
Backward compatibility with third-party plugins (e.g., Envira Gallery) — ✅
Thanks.

Image

@yagniksangani commented on PR #10564:


4 months ago
#30

@t-hamano, Thanks for the fix. I have tested this PR and verified all the mentioned scenarios.

✅ Default Media Uploader
✅ Legacy Media Uploader
✅ Backward compatibility with third-party (Checked with Envira gallery and Soliloquy Slider Plugins)

Just to confirm, will this issue fix be included in the WordPress 6.9 release?

Image

@wildworks commented on PR #10558:


4 months ago
#31

Closing this PR in favor of #10564

#32 Image @wildworks
4 months ago

  • Owner set to wildworks
  • Resolution set to fixed
  • Status changed from new to closed

In 61320:

Media: Remove required attribute from media uploader file input field.

This commit removes the required attribute from the file input element in the media uploader to avoid browser form validation issues and ensure that the form element is submitted correctly.

Props adamsilverstein, ellatrix, desrosj, huzaifaalmesbah, immeet94, krupajnanda, madhavishah01, parthvataliya, ravichudasama01, sabernhardt, wildworks, yagniksangani.
Fixes #64305.

#33 Image @wildworks
4 months ago

  • Keywords dev-feedback added
  • Resolution fixed deleted
  • Status changed from closed to reopened

I will reopen this ticket for a backport to the 6.9 branch.

#34 Image @wildworks
4 months ago

  • Keywords commit removed

Image

This ticket was mentioned in Slack in #core by akshayar. View the logs.


4 months ago

#36 Image @cbravobernal
4 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 61333:

Media: Remove required attribute from media uploader file input field.

This commit removes the required attribute from the file input element in the media uploader to avoid browser form validation issues and ensure that the form element is submitted correctly.

Reviewed by cbravobernal.
Merges [61320] to the 6.9 branch.

Props adamsilverstein, ellatrix, desrosj, huzaifaalmesbah, immeet94, krupajnanda, madhavishah01, parthvataliya, ravichudasama01, sabernhardt, wildworks, yagniksangani.
Fixes #64305.

Note: See TracTickets for help on using tickets.