Add disable arg or attributes arg to wp_dropdown_categories() & wp_dropdown_pages()

[wpsmith]

It would be beneficial to be able to add disabled="disabled" attribute to the select tag or add multiple attributes to the select tag.

Related: #20156, #20167

[wpsmith]

Disabled arg for wp_dropdown_categories()

[wpsmith]

Extra attributes for wp_dropdown_categories()

[wpsmith]

Disabled arg for wp_dropdown_pages()

[wpsmith]

Extra attributes for wp_dropdown_pages()

[prionkor]

+1 we need it on all dropdown functions.

An array of attribute could be passed. Like:

$args = array(

'attrs' = array(

'multiple' => 'multiple',
'disable' => 'disabled'

)

)

It will allow users to add extra attribute like classes or any other html 5 attributes on the dropdown.

[lumpysimon]

+1 for this, I'm having to use jQuery at the moment to achieve this.

[johnbillion]

Patch needs a refresh.

[garrett-eclipse]

+1
Currently utilizing jQuery or rebuilding the $output through the wp_dropdown_cats filter.

This PR adds a disabled boolean argument to both wp_dropdown_categories() and wp_dropdown_pages(). When set to true, the generated <select> dropdowns are rendered with the HTML5 disabled attribute (<select disabled>).

Trac ticket: #20810

[softglaze]

Test Report

Tested PR #12145, applied to ticket/20810 at a554ae14ae.

Environment

WordPress: 7.2-alpha-20260820.014058
PHP: 8.3
Serving: build/ (a build has run)
Multisite: no, and not available in this app
Standing on: ticket/20810
Trunk commit: a554ae14ae
Ticket: #20810
Applied: PR #12145, onto a554ae14ae

Steps taken
Created a fresh wordpress-develop site with the toolkit and let it install and build, then started the dev server and recorded what the two functions emit on unpatched trunk.

Applied PR #12145 to that site, ran npm run build so the PHP changes reached the tree the server mounts, and started the server again.

Called both functions through an mu-plugin on the running site rather than reading the diff: wp_dropdown_categories( array( 'echo' => 0, 'disabled' => true, 'hide_empty' => 0 ) ) and wp_dropdown_pages( array( 'echo' => 0, 'disabled' => true ) ), and the same two calls again with the argument left out.

Expected
With disabled => true the generated <select> should carry the HTML5 disabled attribute, and without the argument it should be unchanged from before.

Actual
Before the patch, on trunk, the argument was ignored by both functions:

wp_dropdown_categories <select name='cat' id='cat' class='postform'>
wp_dropdown_pages <select name='page_id' id='page_id'>

After applying the patch and rebuilding, both honour it:

wp_dropdown_categories <select disabled name='cat' id='cat' class='postform'>
wp_dropdown_pages <select name='page_id' id='page_id' disabled>

And with the argument left out, neither emits the attribute, so nothing changes for existing callers:

wp_dropdown_categories <select name='cat' id='cat' class='postform'>
wp_dropdown_pages <select name='page_id' id='page_id'>

Result: Works as described.

Notes
Tested on Windows 11 with the site served from build/ by WordPress Playground, single site.

The patch applied cleanly to a checkout of today's trunk, all four files, no fuzz.

I did not run the PHPUnit tests the PR adds; this is a behavioural check of the two functions on a running site.

Reported by @softglaze, using the WordPress Contributor Toolkit.