Settings page needs HTML refactoring and UI improvements

[chexee]

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

Current Writing Settings screen

• 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.

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.

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.

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.

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.

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.

Didn't make it in by freeze, punting.

Related: #17526

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.

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).

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' );
});

Related: #15865

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

Another usecase for this: #18241

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

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

The API discussion has moved to #18285

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.

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

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).

In [18817]:

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

[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?

[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.

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

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.

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.

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).

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