Make WordPress Core

Opened 8 years ago

Last modified 3 years ago

#38097 new enhancement

Add ability to Settings API to assign positioning

Reported by: dartiss's profile dartiss Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: Administration Keywords: has-patch
Focuses: administration Cc:


When using the Settings API to add a settings field, particularly if adding to an existing settings screen, it would be nice to have some way of positioning the new field, as you can with add_menu_page, for instance.

So, I've just updated a plugin in which I've added a single settings to the existing "General" settings screen. It's date related and it would sit nicely in a specific position on that screen, but I have no control over it. So, a "position" field, as add_menu_page has, would be a nice addition to provide a more nuanced result.

Attachments (3)

38097.diff (2.6 KB) - added by kapilpaul 3 years ago.
Created patch.
38097.2.diff (1.8 KB) - added by kapilpaul 3 years ago.
Updated patch.
38097.3.diff (1.0 KB) - added by kapilpaul 3 years ago.
fix: coding standards

Download all attachments as: .zip

Change History (12)

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

3 years ago

#2 @peterwilsoncc
3 years ago

  • Milestone changed from Awaiting Review to 5.8

#3 @ribaricplusplus
3 years ago

Hi @dartiss,

We discussed this issue during a triage and agreed that this should be done.

For anyone interested in implementing a patch, here is a suggestion how it could be done:

Add $position to add_settings_field arguments, and then save it in $wp_settings_fields[ $page ][ $section ][ $id ] alongside other settings. Then before outputting fields in do_settings_fields we can do a sort so that the fields are output in accordance with $position.

#4 @dartiss
3 years ago


Having recently re-looked at this, the built-in core settings are hard-coded (i.e. they're not added by the Settings API), so these would need to be modified too, to allow more precise positioning of additional options.

#5 @poena
3 years ago

  • Milestone changed from 5.8 to Future Release

Moving to future release since no patch has been submitted yet.

3 years ago

Created patch.

This ticket was mentioned in PR #1311 on WordPress/wordpress-develop by kapilpaul.

3 years ago

  • Keywords has-patch added

This PR will add the ability to assign a position in settings API

Trac Ticket:

_Custom Settings added with Position_


3 years ago

Updated patch.

#7 @kapilpaul
3 years ago

  • Focuses administration added



I have added a patch for this issue. But still could not fulfill as @dartiss mentioned in the issue.

In options-general.php file settings fields are hardcoded. So there is no positioning that can be set as of now. Do we want to modify this as well to support the position? If so, then can you please guide/explain, so that I can implement it.


#8 @dartiss
3 years ago

Hi 👋🏼

Thank you @kapilpaul for the patch.

I see these as two issues but put them into one ticket as one was reliant on the other - I'm not sure if you want to split it or not.

The first stage, which you've done, is to add a positioning parameter to the Settings API so that we could define where on a screen a particular options should appear.

However, this doesn't allow you to do this with the existing default settings, as they're all hard-coded, rather than using the API. Let me give you an example - if I created a plugin that was to do with Pingbacks and I wanted to add a new option next to the existing Pingback option then, even with this new positioning parameter, you couldn't do it as the core settings isn't using the API.

So, the second stage is to modify the core settings so that they too using the API - it not only allows for the example that I just gave but is, well, let's be honest, it's just right that WordPress should be using its own APIs, where possible, to provide a standardised design.

I hope this explains it a little further.

3 years ago

fix: coding standards

#9 @kapilpaul
3 years ago



Thanks for explaining the issue. I was also thinking the same. But before changing the core things I thought It'll be better if I get a good direction for that.

Note: See TracTickets for help on using tickets.