[wp-trac] [WordPress Trac] #32396: Settings Reduction for 4.3

[WordPress Trac]

#32396: Settings Reduction for 4.3
----------------------------+------------------------
 Reporter:  chriscct7       |       Owner:  chriscct7
     Type:  enhancement     |      Status:  assigned
 Priority:  normal          |   Milestone:  4.3
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:
----------------------------+------------------------

Comment (by chriscct7):

 Replying to [comment:29 ryan]:
 > > It's much much easier to do this as a patch that people can just
 apply.
 >
 > That limits the testing audience to developers and usually means mobile
 won't be experienced at all due to the difficulties of mobile testing
 patches on localhost. The release lead makes the call, but I advocate that
 ux changes like this happen as feature plugins first. They're always
 possible, even if the plugin has to hijack the entire page. I've been
 casually shopping around for someone to do settings reduction as a plugin
 for a long time. This could be that plugin. I see it as an opportunity to
 start on a set of feature plugins that transform our ux and be a vanguard
 for feature plugin style development.


 Personally, I find the settings pages an extremely difficult area with
 which to extend. One thing that I would like to do is find a way of making
 those pages more extendable. Right now, the settings are pretty much just
 HTML coded straight onto a page, without any sort of register method that
 could be used to easily add, remove, or modify them. Long term I think
 that needs to change.

 I mean, don't get me wrong, I would love to see this as a plugin. And I
 would love to get more data on all the options so we can look at further
 reducing complexity even more, and faster. But in order to do the sort of
 refactoring that would be required to make changes like this one into
 feature plugins, it would require several people who can actively work on
 it, not just me. Feature plugins are great when the area they are working
 is extendable. But again we're talking about completely rewriting all of
 the settings pages, and that needs sheer manpower that I just don't have
 the short-term time to commit. It's not only a big task, but if we're
 going to make an API and then dogfeed the core settings that are already
 there into that API, it not only needs to be designed well, and tested
 well, it needs to be done very very soon to get it out for 4.3, so that
 we'd have a chance of getting the reduction done by 4.4.

 If a couple people want to step forward and work on a settings api for the
 setting pages, by all means I'm all for it, but in any case, I'd still
 like to see the suggested settings at bare minimum removed for new
 installs, and again we need a decision, possibly on existing ones as well.


 Now, someone asked for statistics.

 Here are the ones provided by .com for the settings we're proposing be
 removed (that are not part of another ticket). They rounded numbers up to
 the nearest 1, and ones that had less than 1% were reported as "<1%". Only
 2 settings that we asked for statistics for were more, rss_use_excerpt
 (see the note above about why .com's is baised upward from the rest of
 .org) was reported as 2%, and posts_per_page was reported as 1%. Both of
 those will get moved to general (not removed from new installs).

 These are from 87,000+ WordPress sites that are used internally by the
 .com team for making their own decisions on .com features, and basically
 the only tailoring done to them is that none of the included sites are
 spam websites. Other than that random sample, which is what we want.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32396#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform