Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#17163 closed enhancement (maybelater)

Allow plugins to specify how their settings page looks using the Settings API

Reported by: ptahdunbar's profile ptahdunbar Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

The settings API is great, but it would be even greater if the API gave plugins the ability to control how their settings are displayed on their pages instead of them being shoehorned into a table.

To fix this, we'll need to patch the following two functions:

  • do_settings_sections()
  • do_settings_fields()

Attached is a simple patch that allows plugins to filter the default display of sections and fields on a per page basis. It does this by adding a filter which specifies a callback function to handle the display of each section and field.

I'd love to get some feedback on this. I believe this enhancement would greatly improve the adoption rate of the settings API in plugins as it removes the contrains on how their settings get displayed thus making it more useable for complex/custom admin pages.

Attachments (1)

ticket.17163.diff (3.5 KB) - added by ptahdunbar 13 years ago.

Download all attachments as: .zip

Change History (10)

#1 follow-up: @andrewryno
13 years ago

I like the idea (more flexibility), but I feel this patch will just add too much to the settings API for people to use it. Now you would need to add in more markup in order to get something setup (if you don't use the default tables). It's much simpler when it generates everything. Then it also makes the admin panel more consistent and easier to use for users. Developers can already bypass the API and style it the way they want it as it is.

That said, in 3.3 I want to work on getting the settings API to switch from tables to divs. That would give developers slightly more flexibility since you can do more with divs and CSS. Still somewhat constrained, but much better than tables.

#2 in reply to: ↑ 1 ; follow-up: @ptahdunbar
13 years ago

Replying to andrewryno:

I like the idea (more flexibility),

good.

but I feel this patch will just add too much to the settings API for people to use it.

It currently doesnt add anything new for existing uses. It just adds a new optional step for developers who'd like to take advantage of the Settings API but have it displayed and styled the way they want it.

Now you would need to add in more markup in order to get something setup (if you don't use the default tables).

Again, there's no additional markup being added if your using the default output. For developers who want to custom the display, adding more markup is to be expected.

It's much simpler when it generates everything. Then it also makes the admin panel more consistent and easier to use for users.

WordPress has a variety of UI elements that it display data throughout the backend, and currently the Settings API restricts it to just the form-table styled table element.

Developers can already bypass the API and style it the way they want it as it is.

How so? Examples would be great.

That said, in 3.3 I want to work on getting the settings API to switch from tables to divs. That would give developers slightly more flexibility since you can do more with divs and CSS. Still somewhat constrained, but much better than tables.

What you just said, this exact use case, would be possible with my patch :D

#3 in reply to: ↑ 2 ; follow-up: @andrewryno
13 years ago

Replying to ptahdunbar:

It currently doesnt add anything new for existing uses. It just adds a new optional step for developers who'd like to take advantage of the Settings API but have it displayed and styled the way they want it.

I tried rewording that a bit after I looked at what you were proposing again. I don't mean extra for current uses since it's backwards compatible, but if you do want custom code, it initially to me seemed like much more code needed.

Again, there's no additional markup being added if your using the default output. For developers who want to custom the display, adding more markup is to be expected.

Above.

WordPress has a variety of UI elements that it display data throughout the backend, and currently the Settings API restricts it to just the form-table styled table element.

Yup, and I hate that it uses tables. :) Only the List Table API should really be using tables.

How so? Examples would be great.

As long as you use update_option() or post to options.php (just to name a couple) anything is possible. Just logged into a clients site and two plugins install that do this is All in One SEO and XML Sitemaps. If I looked through all the sites I've built, there would be dozens I could list off.

What you just said, this exact use case, would be possible with my patch :D

Awesome! I believe all that will be attached to #16413 since there also might be a few more changes to the settings pages (which may require changing the API).

#4 in reply to: ↑ 3 @ptahdunbar
13 years ago

Replying to andrewryno:

Replying to ptahdunbar:

It currently doesnt add anything new for existing uses. It just adds a new optional step for developers who'd like to take advantage of the Settings API but have it displayed and styled the way they want it.

I tried rewording that a bit after I looked at what you were proposing again. I don't mean extra for current uses since it's backwards compatible, but if you do want custom code, it initially to me seemed like much more code needed.

You'd write custom code regardless... hence the initial reason for being able to customize the display. this is already a given.

Again, there's no additional markup being added if your using the default output. For developers who want to custom the display, adding more markup is to be expected.

Above.

Above.

How so? Examples would be great.

As long as you use update_option() or post to options.php (just to name a couple) anything is possible. Just logged into a clients site and two plugins install that do this is All in One SEO and XML Sitemaps. If I looked through all the sites I've built, there would be dozens I could list off.

Sure. and what you just described is exactly why the adoption rate of the Settings API blows. Doing the manual route doesn't make use of the Settings API at all, which is the whole point of this ticket.

#5 follow-up: @scribu
13 years ago

The whole point of using the Settings API is to make WP handle the markup.

I agree that it's quite limited at the moment, but exposing the underlying HTML defeats the purpose.

Last edited 13 years ago by scribu (previous) (diff)

#6 @scribu
13 years ago

What I would aggree with is being able to pass a callback to draw a textarea instead of a simple text input, or some radio boxes etc.

Version 0, edited 13 years ago by scribu (next)

#7 @scribu
13 years ago

  • Keywords close added

Nevermind, this is already possible with add_settings_field().

Suggest closing as 'maybelater'. We should keep the basic structure private, for now, at least.

Last edited 13 years ago by scribu (previous) (diff)

#8 in reply to: ↑ 5 @azaozz
13 years ago

  • Keywords has-patch close removed
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Replying to scribu:

The whole point of using the Settings API is to make WP handle the markup.

Agree. We might look into expanding it a bit in the future to handle 1-2 more cases but don't see any point in letting plugins alter the internals. If you need something different for a plugin, just output it directly.

Note: See TracTickets for help on using tickets.