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

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.

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.

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.

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

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

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.

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.

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.

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?

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.