Custom fields auto-focus

[jane]

When you are on the post editor (page editor, whatever), if you want to create a new custom field and click on Create New, it should auto-focus on the text input field that appears.

[batmoo]

Moved inline javascript to post.dev.js and set the field to auto-focus.

Should the input be reverted back to the select once a new custom field is added? It just seems weird (possibly confusing) because of the "cancel" link.

[karmatosed]

I agree that the input should revert once custom field is added, without cancel link. If this is still an issue it will need a patch check due to age.

I am tackling this during weekly ux-feedback triage.

[sabernhardt]

Changing the focus behavior might help, yet I'm more concerned about the lack of a label on the meta key input field. So even if you think to use Shift + Tab to go back to the meta key input, a screen reader cannot say what you are editing.

[franrosa]

Maybe I am missing something here, but would not adding a text input on the list of options to either search existing fields or writing the name of a new one to add eliminate the need to have that dual UI with that confusing New/Cancel pattern?

It would be similar to the existing UI for links, with the added option to 'Create new' when no result is found. (Quick mockup for clarity: ​https://drive.google.com/file/d/1VvPlU_j5aXDTN445CkeMmGNpBk2dVko8/view?usp=sharing)

[sabernhardt]

datalist concept

[sabernhardt]

updating focus and labels in current interface

[sabernhardt]

This is a feature of the classic editor that the block editor adopted. There was some ​trouble creating a custom fields UI element there in the months before WordPress 5.0, which could be easier now. Discussion about an element like the block editor's link autocomplete would fit better in the Gutenberg repo.

Yet your suggestion led me to think about the native ​datalist element. Firefox still has a bug with the dropdown, but the element could be worth considering.

15631-datalist.diff

• Replaces select with a datalist of the same options
• Uses the "Name" table header as the label for the input field
• Removes the "Enter New"/"Cancel" toggle link
• Would need CSS editing for the dropdown triangle position

I also created 15631.2.diff to follow prior feedback:

• Ensures that the "Name" table header as the label for the select element
• Creates a "New custom field name" ARIA label for the input field
• Converts the toggle link to a button
• Moves focus to the input after clicking "Enter New", and to the select after "Cancel" or "Add Custom Field"
• Keeps the JS inline (I would have added it to post.js, but the block editor apparently does not load it)

[ryokuhi]

We reviewed this ticket today during the Accessibility Team's bug scrub.
The ticket needs testing to check if patch 15631.2.diff still applies clearly or if a refresh is needed.

[annashopina]

Test Report
This report validates that the issue is still reproduced.
Patch tested: https://core.trac.wordpress.org/ticket/15631
Environment
OS: macOS 13.1
Web Server: Nginx
PHP: 8.0
WordPress: 6.3
Browser: Chrome 111.0.5563.146
Active Plugins:
Classic Editor
Actual Results
The issue was not resolved with a patch.
Additional Notes
Steps to reproduce:
Install and activate Classic Editor
Open any post/page
Open 'Screen options
Enable 'Custom fields'
Add custom field
Observe where is the focus
Add Inline:
Actual result: It's not auto-focused on the text input field that appears.

Expected result: It should auto-focus on the text input field that appears.

[joedolson]

Note: the test by @annashopina looks like it was testing whether focus was moved when using the 'Add Custom Field' button, but this ticket is about moving focus to the text field when 'Enter New' is chosen to define a new custom field name. So that test isn't valid.

I just tested, and the patch tests fine. I'm uploading two patches; 15631.3.diff is a refresh of the previous patch, 15631.4.diff changes the 'Enter new' button to use the button-small appearance (matching the delete/update buttons on existing fields & avoiding the semantic confusion of something that is a button but looks like a link) and moves the 'Add Custom Field' button out of the table, because the semantics don't make sense.

[joedolson]

Refreshed patch

[joedolson]

Use button appearance & move add custom field out of table

[oglekler]

Hi @joedolson, can you please check the patch, somehow it is not applicable.

I added a screenshot to get more clarity on what custom fields are.

Info to test:

• Activate Classic editor (if applicable)
• Open a page to edit
• Open Screen options (right top corner of the window) and add a checkmark to Custom fields
• Scroll the page down and start to add Custom fields

• Deactivate Classic editor (if applicable)
• Open a page to edit
• Open settings (three vertical dots in the right top corner)
• Choose Preferences, open the Panel tab and switch Custom fields to on
• Click Enable & Reload
• Scroll page down and start to add Custom fields

[joedolson]

@oglekler I'm not able to reproduce any problems with applying the patch; can you provide any additional detail?

[joedolson]

Moving focus to the select input after adding a custom field fails the first time a custom field is added, because the select does not yet exist.

This also causes a weird visual where the new custom field input disappears when you add the first custom field.

I think that changing the visibility of the custom field interface doesn't make sense when adding custom fields; it's a better user experience in my opinion if adding a custom field doesn't otherwise update the UI - just adds the new field.

[oglekler]

@joedolson I cannot apply patch to trunk even if files are in place and there shouldn't be any conflicts within the code 🤷

$ git apply 15631.4.diff
error: wp-admin/css/edit.css: No such file or directory
error: wp-admin/includes/template.php: No such file or directory

$ git apply --directory=src/ 15631.4.diff
error: patch failed: src/wp-admin/css/edit.css:1068
error: src/wp-admin/css/edit.css: patch does not apply
error: patch failed: src/wp-admin/includes/template.php:724
error: src/wp-admin/includes/template.php: patch does not apply

[joedolson]

I haven't tried the patch on git; I've only been working in SVN. Seems unlikely that would be the issue, but it's possible. I can convert this to a PR and see if you can apply it then.

Not a final patch; shifting to PR for testing.

Removes focus change & input change on adding custom field; changes context of wp lists .add method.

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

[joedolson]

PR removes focus change after adding a custom field and moves the nonce inside the table, where wpList.nonce() expects to find it.

[oglekler]

@joedolson thank you, I was able to install the patch. Cursor is inside as required after pressing button "Enter new", I was able to add data, to use tab to navigate and update meta. Screenshot is above.

Software: WP (6.3-alpha-55505-src), Google Chrome 114.0.5735.134 (desktop).

[joedolson]

Thanks, @oglekler

[sabernhardt]

If anyone wonders about keeping the #postcustomstuff #newmetaleft a selector when the link was replaced, ​some plugins add their own a element in a newmetaleft container (including WooCommerce).

[joedolson]

I've explored a few of the plugins listed, and haven't found anything to actually test. Simple Job Board doesn't use a link; they use a div, and operate it using their own custom JS. Backup & Restore WordPress only has that reference in something that looks like a local vendor reference, not an actual used file. WooCommerce has the reference, but it doesn't seem like it's actually being used? At least, in testing, custom fields on orders used the core implementation. So, I don't know how much of a concern this really is...I think this should just move forward as is. If there are problems, we'll find out.

[joedolson]

In 56018:

Editor: Improve accessibility of new custom field UI.

Add labels; change Enter new/Cancel link to a button; move focus to input when creating new field; move Add Custom Field out of fields table.

Props jane, batmoo, karmatosed, franrosa, sabernhardt, annashopina, oglekler, joedolson.
Fixes #15631.

Closed in r56018