Make WordPress Core

Opened 13 years ago

Last modified 4 months ago

#16413 accepted enhancement

Settings page needs HTML refactoring and UI improvements

Reported by: chexee's profile chexee Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: settings-api
Focuses: ui, accessibility Cc:

Description

The settings pages haven't had much attention or improvement in a while.

We need to refactor the HTML on the settings pages, as they are still using tables instead of divs.

We also want to make some minor UI improvements including:

  • clearer differentiation between option groupings
  • using consistent text styles for descriptions and links (including the time zone/date format comment)
  • restructure for better readability

Comment if you have any other

Attachments (10)

Screen shot 2011-01-30 at 1.21.58 PM.png (195.1 KB) - added by chexee 13 years ago.
Current Writing Settings screen
16413.diff (154.7 KB) - added by andrewryno 13 years ago.
16413.2.diff (25.8 KB) - added by andrewryno 13 years ago.
16413.3.diff (168.5 KB) - added by andrewryno 13 years ago.
Screen Shot 2011-09-15 at 12.32.25 PM.png (26.0 KB) - added by andrewryno 13 years ago.
Known issue (network/site-settings.php) that I couldn't figure out at the time
16413.install-rtl.patch (441 bytes) - added by SergeyBiryukov 12 years ago.
16143-network.diff (36.2 KB) - added by andrewryno 12 years ago.
16143-options.diff (47.5 KB) - added by andrewryno 12 years ago.
16143-settings-api.diff (1.3 KB) - added by andrewryno 12 years ago.
settings-1.png (221.6 KB) - added by melchoyce 10 years ago.

Download all attachments as: .zip

Change History (93)

@chexee
13 years ago

Current Writing Settings screen

#1 @markjaquith
13 years ago

  • The spacing between radio buttons varies quite a bit.
  • In many cases, description paragraphs seem heavy. Too verbose.
  • The "Press This" bookmarklet presentation needs some inspiration. Bookmarklets are a tricky concept to convey, so put on your thinking caps here.

#2 @ptahdunbar
13 years ago

  • Cc trac@… added

#3 @saracannon
13 years ago

  • Cc sararcannon@… added

#4 @ryelle
13 years ago

  • Cc ryelle added

#5 @andrewryno
13 years ago

  • Cc andrewryno@… added
  • Keywords changed from settings, ui to settings ui

I've only done minimal testing since so much time was taken to just get all the HTML converted in the first place. Luckily all of the fixes will just need to be CSS changes. HTML should be solid.

I left a lot of the CSS in place for the tables for plugins that don't use do_settings_sections() and do_settings_fields() and just embed their own tables. Also haven't changed any presentation since others need to be in on that discussion on what needs to be done overall. This was just to convert from tables to divs so we can move ahead with any changes easily.

TODO:

  • Install.php/setup-config.php (was working on them, but since they uses 3 columns, I didn't want to mess with it too much).
  • Testing, testing, testing.

@andrewryno
13 years ago

@andrewryno
13 years ago

#6 @andrewryno
13 years ago

  • Cc andrewryno@… removed

It seems like we might be moving to using the Settings API to output all of the markup, so in order to change from tables to divs, all the settings should be run through the API.

This is where I got on the general page. I've never really used the API before, but it seems a little verbose. Just wanted to get a second opinion before I do the rest of the pages.

#7 @andrewryno
13 years ago

  • Cc andrewryno@… added

#8 @goto10
13 years ago

  • Cc dromsey@… added

#9 @scribu
13 years ago

  • Keywords has-patch needs-refresh added
  • Milestone changed from Awaiting Review to Future Release

Looks ok to me. Needs refresh, though.

Since these patches get stale really fast, I don't think you should start working on the other screens until this task is blessed and has a committer at the ready.

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

#10 @andrewryno
13 years ago

Yeah I was expecting a refresh when I made it. I was also just wanting to get comfortable using the settings API. nacin also told me to wait until 3.3 gets started, so going to do that. On hold until then.

#11 @nacin
13 years ago

  • Milestone changed from Future Release to 3.2
  • Owner changed from saracannon to nacin
  • Status changed from new to accepted

I am tempted to stick to 16413.diff for 3.2, and leverage the settings API in 3.3. I wouldn't waste time on trying to refresh these, as I'm still undecided on the final direction for 3.2. Either way, I am accepting this for inclusion and will work on it in the coming days.

#12 @jane
13 years ago

  • Milestone changed from 3.2 to Future Release

Didn't make it in by freeze, punting.

#13 @scribu
13 years ago

Related: #17526

#14 @ryanimel
13 years ago

  • Cc ryanimel added

#15 @scribu
13 years ago

Re 16413.2.diff: to reduce verbosity, we could wrap all the settings for each screen in a class and use a helper instead of add_settings_field() directly.

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

#16 @scribu
13 years ago

16413.class-wp-settings-page.diff implements the wrapper class I mentioned and uses it on the media settings screen (I chose it because it's smaller, so it's less likely for the patch to get stale).

#17 @scribu
13 years ago

One problem with my patch and also with andrew's is that settings that are added by plugins, hooked into 'admin_init' for instance, would now show up before the default ones, instead of after:

add_action( 'admin_init', function() {
	add_settings_section( 'test', 'Test', '__return_false', 'media' );
});

#18 @scribu
13 years ago

Related: #15865

#19 @ctsttom
13 years ago

Whats the deal with this ticket now, I have a +1 from me, I think its a great idea for WP3.3

#20 @scribu
13 years ago

Another usecase for this: #18241

#21 @chexee
13 years ago

I'd like to work some on this and get this into 3.3 :]

#22 @ctsttom
13 years ago

  • Cc me@… added

@chexee that would be amazing if you could, I would love to see this added!

#23 @scribu
13 years ago

  • Keywords has-patch needs-refresh removed
  • Summary changed from Settings page needs refactoring and UI improvements to Settings page needs HTML refactoring and UI improvements

The API discussion has moved to #18285

#24 @sabreuse
13 years ago

  • Cc sabreuse@… added

#25 @ryan
13 years ago

  • Milestone changed from Future Release to 3.3

#26 @ciobi
13 years ago

  • Cc ciobi added

#27 @dremeda
13 years ago

  • Cc dre@… added

#28 @andrewryno
13 years ago

First pass at redoing the patch.

Replaced EVERY form-table in the backend, since I think I missed several in my last patch.

I've checked every table and it all looks good for me in Chrome. I'm doing testing in all other browsers tonight (I have a feeling there will be some IE fixes). Just uploading this now in case someone else wants to help me test it early on (I can't test on IE until a bit later tonight).

I also need to test backwards compatibility for plugins that hardcode the tables using the built-in classes. I didn't change anything with regards to the table styling, but need to make sure nothing broke.

@andrewryno
13 years ago

@andrewryno
13 years ago

Known issue (network/site-settings.php) that I couldn't figure out at the time

#29 @andrewryno
13 years ago

Uploaded screenshot of one issue I'm aware of. It looks like network/site-settings.php isn't outputting the last option with a form wrapper. I didn't dig into why but it wasn't obvious to me.

I will also be rechecking all these pages for valid HTML (which should also help check if I missed a tag or something).

#30 @nacin
12 years ago

In [18817]:

Kill the tables in install.php. props andrewryno. see #16413.

#31 @SergeyBiryukov
12 years ago

[18817] (if stays in for 3.3) needs RTL adjustments. Done in 16413.install-rtl.patch.

Or is it better to leave RTL sync for beta?

#32 @nacin
12 years ago

  • Keywords 3.4-early added
  • Milestone changed from 3.3 to Future Release

[18817] is all that'll occur for 3.3. I was just seeing how things looked. Punting the rest. I'll drop in the RTL fixes now, thanks.

The moment we branch for 3.4, this is going in. Needs to happen so it doesn't go too stale.

We probably need to break this into multiple patches: Patches for setting screens, patches for CSS only, patches for do_settings_* only, patches for other tables elsewhere, etc.

#33 @koopersmith
12 years ago

See #18865 for a bug caused by [18817].

#34 @nacin
12 years ago

In [18897]:

Revert [18817]. Adding the new HTML to setup-config would make translation files stale, and I'd rather i18n that file first (see #18180). fixes #18865, see #16413.

#35 @andrewryno
12 years ago

Once branched, I'll go ahead and refresh the patch (I know for sure the CSS needs a refresh) and break up the patches myself.

#36 @chipbennett
12 years ago

  • Cc chip@… added

#37 @andrewryno
12 years ago

Attached first 3 patches for main network screens, options screens, and the settings api (do_settings_*). Working on the others tomorrow hopefully.

Remaining occurences:

./wp-admin/custom-background.php:190:<table class="form-table">
./wp-admin/custom-background.php:257:<table class="form-table">
./wp-admin/custom-header.php:486:<table class="form-table">
./wp-admin/custom-header.php:532:<table class="form-table">
./wp-admin/custom-header.php:583:<table class="form-table">
./wp-admin/edit-form-comment.php:88:<table class="form-table editcomment">
./wp-admin/edit-tag-form.php:38:	<table class="form-table">
./wp-admin/includes/file.php:1021:<table class="form-table">
./wp-admin/includes/meta-boxes.php:777:			<table cellpadding="3" cellspacing="5" class="form-table">
./wp-admin/includes/meta-boxes.php:890:<table class="form-table" style="width: 100%;" cellspacing="2" cellpadding="5">
./wp-admin/includes/ms.php:622:	<table class="form-table">
./wp-admin/includes/template.php:1105:		echo '<table class="form-table">';
./wp-admin/install.php:95:	<table class="form-table">
./wp-admin/install.php:224:<table class="form-table install-success">
./wp-admin/network/site-users.php:257:	<div class="form-table">
./wp-admin/revision.php:156:<table class="form-table ie-fixed">
./wp-admin/revision.php:212:$args = array( 'format' => 'form-table', 'parent' => true, 'right' => $right, 'left' => $left );
./wp-admin/setup-config.php:119:	<table class="form-table">
./wp-admin/user-edit.php:205:<table class="form-table">
./wp-admin/user-edit.php:243:<table class="form-table">
./wp-admin/user-edit.php:335:<table class="form-table">
./wp-admin/user-edit.php:368:<table class="form-table">
./wp-admin/user-new.php:265:<table class="form-table">
./wp-admin/user-new.php:311:<table class="form-table">
./wp-includes/post-template.php:1310: *   (string) format : 'list' or 'form-table'. 'list' outputs UL, 'form-table'
./wp-includes/post-template.php:1313: *                     form-table format.
./wp-includes/post-template.php:1315: *                     used in form-table format.
./wp-includes/post-template.php:1326: * @todo split into two functions (list, form-table) ?
./wp-includes/post-template.php:1371:		if ( 'form-table' == $format ) {
./wp-includes/post-template.php:1398:	if ( 'form-table' == $format ) : ?>

Then finally the CSS (which I'm working on as I go through the screens so I can get a more complete patch).

#38 @unknowndomain
12 years ago

  • Cc unknowndomain added

Hey folks,

Wanted to notify you of a call to action on this tickets blocking ticket:
http://core.trac.wordpress.org/ticket/18285#comment:76

Thanks

Tom

#39 @nvwd
11 years ago

  • Cc nowell@… added

#40 @unknowndomain
11 years ago

  • Keywords 3.6-early settings-3.6 added; 3.4-early removed

#41 @unknowndomain
11 years ago

  • Keywords 3.6-early removed

#42 @SergeyBiryukov
11 years ago

  • Component changed from UI to Administration
  • Keywords ui-focus settings-api added; settings ui settings-3.6 removed

#43 @toscho
11 years ago

  • Cc info@… added

#44 @melchoyce
11 years ago

  • Cc melissachoyce@… added

#45 @helen
11 years ago

  • Milestone changed from Future Release to 3.8
  • Owner changed from nacin to helen
  • Status changed from accepted to assigned

Going to make good on a promise. Necessary CSS (of the reusable component variety) will be developed in MP6 and then HTML rejiggering patches can proceed from there. Reassigning to myself just for tracking - all are welcome and encouraged to contribute.

#46 @Kuzmanov
11 years ago

wp-admin/options-*.php
wp-admin/press-this.php
wp-admin/setup-config.php
wp-admin/themes.php
wp-admin/update-core.php
wp-admin/user-edit.php
wp-admin/user-new.php
wp-admin/widgets.php
wp-admin/custom-background.php
wp-admin/custom-header.php
wp-admin/edit-form-advanced.php
wp-admin/edit-form-comment.php
wp-admin/edit-tag-form.php
wp-admin/import.php
wp-admin/install.php
wp-admin/my-sites.php
wp-admin/nav-menus.php
wp-admin/network.php

are using tables.

#47 follow-up: @unknowndomain
11 years ago

It might be worth noting that #18801 is pretty much a dupe of this in some ways.

#48 in reply to: ↑ 47 ; follow-up: @helen
11 years ago

Replying to unknowndomain:

It might be worth noting that #18801 is pretty much a dupe of this in some ways.

Nah, wouldn't consider it a duplicate. Do think both should be fixed together.

#49 in reply to: ↑ 48 @unknowndomain
11 years ago

Replying to helen:

Replying to unknowndomain:

It might be worth noting that #18801 is pretty much a dupe of this in some ways.

Nah, wouldn't consider it a duplicate. Do think both should be fixed together.

I think #15865 is related, perhaps we could work together on this, I could do the Settings API stuff, if you can do the HTML/CSS refactoring in time to allow me to do the Settings API stuff.

#50 @trishasalas
10 years ago

  • Cc trisha@… added

#51 @cochran
10 years ago

  • Cc christophercochran@… added

#52 @mordauk
10 years ago

  • Cc pippin@… added

#53 @TJNowell
10 years ago

  • Cc contact@… added

#54 @helen
10 years ago

  • Milestone changed from 3.8 to Future Release

Sigh. Still not there yet. Reusable form CSS still needs to happen. If anybody wants to come help out: https://github.com/helenhousandi/wp-style-guide/

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


10 years ago

#56 @jenmylo
10 years ago

Working with @melchoyce on settings ui redux. We're talking about multiple columns, breaking out of the standard a little. Will use this ticket for wireframes/patches etc. Note that this ticket's stated issue was css vs tables and UI, not a new API. :)

@melchoyce
10 years ago

#57 follow-up: @melchoyce
10 years ago

settings-1.png explores combining the Setting pages into one long, continuously scrolling page. Sections are linked from a persistent navigation bar at the top, which changes to reflect the "current" section as you scroll.

You might also notice that we've created a new "setup" section that contains some of the most commonly changed settings. This is to allow new or casual users to quickly change the settings that matter to them, without overwhelming them with tons of different sections to search through to change basic settings up-front. We'd also like to look at reorganizing a lot of the sections to make a little more sense. Would swapping out which section a setting appears in have any effect on plugin or theme authors using the settings pages?

For now, these wireframes are just for discussion. We'll post a final with the specific groupings when we are ready for a patch.

#58 @Ipstenu
10 years ago

I think the setup section makes sense unless we're going to call in 'General' settings tab in the General settings page.

On Network we call it "Info" (see #26953 for THAT nightmare). Should we strive for parity there and matchy-matchy? (I don't care which one, and maybe if it was 'setup' people would think 'Oh so I don't change this randomly...')

This ticket was mentioned in IRC in #wordpress-dev by ipstenu. View the logs.


10 years ago

#60 @johnbillion
10 years ago

One bit of feedback: The intermediate "Save" buttons below each section could be confusing. Do they save the entire page (probably) or do they save just the section preceding the button?

#61 in reply to: ↑ 57 @obenland
10 years ago

Replying to melchoyce:

Would swapping out which section a setting appears in have any effect on plugin or theme authors using the settings pages?

Probably not since they currently don't have a (easy) way to remove core settings. We will have to make sure that the existing calls to do_settings_fields() and do_settings_sections() let the registered settings show up in the right (meaningful) context though.

#62 @Ipstenu
10 years ago

What Obenland said. It might impact documentation and screenshots, but as long as we're not nuking the hooks, we should be fine :)

#63 follow-up: @toscho
10 years ago

What will happen with links to these pages? When I add a field to one of the existing setting pages, I link to it from other screens (plugin list for example). Will all plugins using admin_url( 'options-discussion.php' ) . '#foo' break?

#64 in reply to: ↑ 63 @Ipstenu
10 years ago

Replying to toscho:

What will happen with links to these pages? When I add a field to one of the existing setting pages, I link to it from other screens (plugin list for example). Will all plugins using admin_url( 'options-discussion.php' ) . '#foo' break?

That depends on how we chose to make the tabs/sections. If we make it all one page, then we'll have to figure out some way not to break those links (maybe filter somehow?). If we make it 'tabs' like we have on the Multisite networky page, then they can keep their URLs.

Which is better? Probably one page for usability, since it's not THAT much stuff, but maybe we should consider the tabbed view as a step one? (Spitballing ideas here). I don;t know how hard it is to have WP detect "Oh you're looking for options-<anything>.php? That's options.php now. Lemme take care of that!"

This ticket was mentioned in IRC in #wordpress-dev by SergeyBiryukov_. View the logs.


10 years ago

This ticket was mentioned in Slack in #accessibility by toscho. View the logs.


9 years ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


9 years ago

#68 @joedolson
9 years ago

  • Focuses accessibility added

Adding the accessibility focus so that we're keeping an eye on future changes here.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


9 years ago

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


9 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-multisite by ipstenu. View the logs.


9 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


9 years ago

#74 @robertwhitis
8 years ago

It would be really awesome if there was only one Save button, and it was always in the same spot for a core settings page.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


8 years ago

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


8 years ago

This ticket was mentioned in Slack in #accessibility by sergey. View the logs.


8 years ago

#78 @afercia
8 years ago

Not exactly a "settings page" but somehow related: #37848.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


8 years ago

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


7 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#82 @joedolson
13 months ago

  • Owner changed from helen to joedolson
  • Status changed from assigned to accepted

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 months ago

Note: See TracTickets for help on using tickets.