Settings Reduction

[chriscct7]

One of WordPress's many core philosphies is decisions instead of options based on the majority. In recent years, WordPress has worked on simplifying the administration and new-to-WordPress experience. As a result of these talks, and my ongoing work on the ancient ticket report, we're proposing the removal of some of the lesser used options in WordPress core.

This ticket is strongly related to (#22942), where we're removing email to post for all installs from WordPress core, as it is inherently broken.

As part of the work into this ticket, several hosting providers have provided usage data for core options, specifically the % of installs where the value of the core setting is not on the default.

Here is an overview of the proposed movement of options:

Settings Removed:

• mailserver_url (post to email leaving core)
• mailserver_login (post to email leaving core)
• mailserver_pass (post to email leaving core)
• mailserver_port (post to email leaving core)
• default_email_category (post to email leaving core)
• default_category (moving to the post category page in #31483)

Possibly removed based on usage under 1% (from WordPress.com data, normalized) :

• avatar_default
• show_avatars
• avatar_rating
• default_post_format
• ping_sites
• posts_per_rss

Settings Under Consideration for Removal pending media numbers from GoDaddy + Page.ly:

• thumbnail_size_w
• thumbnail_size_h
• thumbnail_crop
• medium_size_w
• medium_size_h
• large_size_w
• large_size_h
• uploads_use_yearmonth_folders
• rss_use_excerpt

Settings Moved to General:

• posts_per_page
• page_on_front
• page_for_posts
• blog_public

The two options we have for each setting is to:

• Remove the setting (hide it) just for new installs (continue showing for existing installs)
• Remove the setting for all installs

For each setting, existing hooks can be utilized (as well as just a simple update_option call) to continue using the setting after it's been removed or hidden.

As it stands right now, the following option pages would not show for new installs (or if we decide to remove the settings existing ones as well):

• Writing
• Reading
• Media (pending data)

All settings pages would be mapped as was done previously for the privacy page in 3.5.
Thus any plugin currently hooking into any of the removed tabs would not be affected.

From a UX standpoint, the second most commonly used WordPress setting (behind site URL) is the posts_on_front/page_for_posts selector, currently on the reading page. Under this proposal, the option would be relocated to new installs (or existing if removal of tab for existing installs) to right underneath the site url field on the general tab which makes sense as one of the more used WordPress settings should be on the default settings page.

The goal is to finish getting usage data for the remaining settings this week, and to have a patch ready within the next 2 weeks. Decisions on whether to remove settings on existing installs will need to be made on an option by option basis and should be done as soon as possible to expedite the patch process.

[chriscct7]

It should be noted a preliminary patch for this is done, which will just need to be tweaked based on the decisions for the settings

[chriscct7]

Related (email to post settings): #32397

[chriscct7]

Accidental close

[paulwilde]

It's worth noting that neither image_default_size or image_default_align are exposed in the UI.

[chriscct7]

Replying to paulwilde:

It's worth noting that neither image_default_size or image_default_align are exposed in the UI.

Those were not intended to be in the list. Removed.

[kraftbj]

Press This was removed from Settings->Writing in [31534] & [31743].

[chriscct7]

Replying to kraftbj:

Press This was removed from Settings->Writing in [31534] & [31743].

Indeed. Was looking at 4.2 when this project started

[chriscct7]

The last of our stats we requested should be in next week. At this point, my thought is to develop the patch sans-media for this and then let's merge that, and then:
if we get the media stats in time: do it in 4.3
else do it in 4.4 along with a planned look at the discussions settings page

Will start working on this tomorrow and can we plan on asking for feedback during dev chat next week @obenland? The goal is to have this finalized by midweek next week

Does anyone have an opinion about removing vs hiding the settings on new installs?

[obenland]

Replying to chriscct7:

can we plan on asking for feedback during dev chat next week?

Sure can. Feel free to comment on the agenda in case I forget.

Besides that, please feel free to get in touch with people encouraging them to comment in this ticket.

[Stagger Lee]

What would replace native image preset sizes ?

If you remove settings for them then we can end with 3 unused and undesired image sizes nowhere used on site, but still generated unnecessary.

If I have understood all this correctly ?

[chriscct7]

Replying to Stagger Lee:

What would replace native image preset sizes ?

If you remove settings for them then we can end with 3 unused and undesired image sizes nowhere used on site, but still generated unnecessary.

If I have understood all this correctly ?

The native image sizes would not be removed there would just no longer be a massive set of settings for them. On new installs (this does not effect existing ones at this point in time) if you wanted to change the sizes you would need to use update_option or the filters for them.

[Stagger Lee]

My humble opinion is you should adopt Simple Image Sizes plugin in the core. It should be easy for beginners, they cannot use filters and functions.php.

Dont go Joomla way, continue on same path as Drupal. (fast not right comparation, Joomla doesnt have image sizes at all)

[chriscct7]

Replying to Stagger Lee:

My humble opinion is you should adopt Simple Image Sizes plugin in the core. It should be easy for beginners, they cannot use filters and functions.php.

Dont go Joomla way, continue on same path as Drupal. (fast not right comparation, Joomla doesnt have image sizes at all)

The goal is to to follow the core philosophy of decisions, not options. In that respect, if (we're still waiting on more statistics from hosting providers for media) the main settings for images aren't used because people let the themes and plugins dictate them, there's no reason to keep those settings if less than 1% of existing users use it for new installs. Plugins like Simple Image Sizes provide a way for those who do need a UI.

[Stagger Lee]

A OK, how do you will. Despite I use this screen heavy on ALL my WP installations, I will easy manage it in functions.php too.

But you are making WordPress less serious in CMS competition. This part is an vital organ of one CMS and should be proudly visible and shown to all, despite what statistics say.

I did not know statistics say so, have all the time imagined this screen is somehow poor and under developed, compared to Drupal.

[chriscct7]

Update before the core meeting. Due to lack of enough data for the media page, we're going to hold off on touching that tab until 4.4 (where we'll also look at reducing the number of discussion page settings).

For 4.3 we are considering the removal of the writing and reading option pages.

From these pages:

Settings removed from other tickets:

• mailserver_url (post to email leaving core)
• mailserver_login (post to email leaving core)
• mailserver_pass (post to email leaving core)
• mailserver_port (post to email leaving core)
• default_email_category (post to email leaving core)
• default_category (moving to the post category page in #31483)

Removed based on usage under 1% (from WordPress.com data, normalized) :

• avatar_default
• show_avatars
• avatar_rating
• default_post_format
• ping_sites
• posts_per_rss

Additionally rss_use_excerpt would either need to be removed or relocated (probably to General). If you go by .com's statistics for that, it's 2%. However, as pointed out by @kraft, .com's numbers on this particular statistic are biased upwards as it serves a second usage as it controls how much of the post is displayed in the WordPress.com Reader.

Settings Moved to General:

• posts_per_page
• page_on_front
• page_for_posts
• blog_public

Now, for each option we remove we have 2 removal options:

• Remove the setting (hide it) just for new installs (continue showing for existing installs), like we did with smilies + XHTML
• Remove the setting for all installs

For each setting, existing hooks can be utilized (as well as just a simple update_option call) to continue using the setting after it's been removed or hidden. Plugins that map settings to these pages will have the settings remapped accordingly, exactly the way it happened when (for example) the privacy option page was removed.

The highest priority item on this ticket is the decision on whether to remove the settings from existing installs as well.

[chriscct7]

A couple other notes:

It should be noted one of the nice things this ticket does is let us move the front page/blog page setting, one of the most used settings in WordPress, to the default settings page (general). This avoid a needless click and search for new users.

The point of removing settings is based on the core philosophy of decisions not options. Options used by under, and in many cases well under, 1% of users is a severe detriment to the usability of WordPress, particularly for new users. Right now, a new user to WordPress has to wade through 6 pages of settings, which as demonstrated above, many of which they'll never use. By removing ones no one uses we reduce complexity for users as well as highlight the settings that actually need to be changed for users.

While I wish we could touch media or discussion settings, to look at reducing the number of those, we do not have enough data to do it for 4.3. However, we will look at removing the media options page again in 4.4 as well as reducing the number of discussion option page settings.

[netweb]

bbPress shares/inherits a handful of the discussion settings, rather than adding our own screen we piggyback onto WordPress' settings, primarily around moderation for bad words, backlist, number of allowed links.

[ryan]

I'm glad to see this happening. Awesome. If there was a plugin that implemented these recommendations, I'd use it right now. This seems a perfect candidate for a feature plugin. The plugin could do direct menu global hackery. There's no need to be proper. An exercisable proof of concept that can be rapidly iterated will help this land faster, I think. I also think we should make a habit of using feature plugins to work out big ux changes like this. Feature plugins are easier to test, and much, much easier to punt. They are also easier to put on wordpress.com for exposure to its huge scale, no small thing.

[chriscct7]

@netweb: Noted! We aren't planning on looking at those till 4.4 anyways, but ill make sure we take a look at them

@ryan It's to my knowledge not possible actually. There's nowhere near the filters to do this properly. However, that being said we already have a working patch that I'll be finishing up as soon as we get more feedback on the remove from existing or not to remove from existing decision.

[ryan]

@ryan It's to my knowledge not possible actually. There's nowhere near the filters to do this properly. However, that being said we already have a working patch that I'll be finishing up as soon as we get more feedback on the remove from existing or not to remove from existing decision.

Core can add temporary filters to accommodate feature plugins.

[chriscct7]

Replying to ryan:

@ryan It's to my knowledge not possible actually. There's nowhere near the filters to do this properly. However, that being said we already have a working patch that I'll be finishing up as soon as we get more feedback on the remove from existing or not to remove from existing decision.

Core can add temporary filters to accommodate feature plugins.

The number of filters needed and the amount of effort to make the necessary items filterable would be significantly larger code wise, time wise, and effort wise than just making the patch itself though (and then we'd need to write a plugin as well). I mean I get what you're saying on why it would be nice to do, but its just not worth it in my opinion.

Entire swaths of the option page files would need to be significantly refactored. It's much much easier to do this as a patch that people can just apply. I already have like 90% of the patch done for this assuming we keep the settings for existing installs, something we still need a decision on. If we're just going to remove the ui for the settings for all installs, a new patch based on the old one could be made in a few hours.

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

[chriscct7]

Replying to 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.

[chriscct7]

In an ideal world too, although this should probably be discussed further in another ticket, it would be cool when WordPress called .org for update checking if it could report core WordPress settings data. We don't even need the value they have it set at, just like a 1 or 0 if a setting is on a default or not. That would provide us with a massive amount of data that could easily be quantified to provide usage data (similar to how WordPress makes the graphs that show what % of people are on a specific WordPress version) and would allow the project to easily figure out what other settings aren't getting used very quickly.

[ryan]

Other feature plugins have removed existing screens and replaced them entirely when faced with insufficient hooks. We need not step in the API rabbit hole.

That said, I'll relent. I think I'm the only one wanting to explore feature plugin waters with settings reduction. Ideally, I have this running as a plugin on my blogs for at least a month before it is considered for merge. I'd like to get to that point some day with future ux cleanups. Meanwhile, I look forward to testing a patch. Cheers. :-)

[chriscct7]

I think at some point there should definitely be an API, but I'll see what I can do about a plugin that completely replaces the whole pages.

[DrewAPicture]

Replying to ryan:

That said, I'll relent. I think I'm the only one wanting to explore feature plugin waters with settings reduction. Ideally, I have this running as a plugin on my blogs for at least a month before it is considered for merge. I'd like to get to that point some day with future ux cleanups. Meanwhile, I look forward to testing a patch. Cheers. :-)

Not the only one. I might be able to take a couple of hours this week and give it a go.

[jeremyfelt]

Only because I've done horrible things elsewhere. :)

add_action( 'load-options-reading.php', 'feature_plugin_options_reading' );
function feature_plugin_options_reading() {
	// copy/paste current options-reading.php from core and iterate

	die(); // but kill the page before the real options-reading.php can continue
}

A featured plugin would be pretty quick to setup using this method (I think).

[chriscct7]

Yeah after talking to drew, I think we're going to make the patch as well as a plugin.

That being said, before we can do either we need a decision on the remove settings for existing installs or not.

[chriscct7]

Settings Reduction is getting punted to next release. Couple reasons:

1. I don't have enough time to finish this before the feature window closes. However,
2. I want to work on reworking the code for those option panels. The way we add settings is really bad (its hardcoded), so there's no way to filter them, which could be easily fixed by having them use the api. If we get a patch that lets us use the api then
3. That could be made into a plugin, which would also let us make settings reduction a feature plugin, which would be cool, and would make future settings reductions really easy to do (code wise and feature plugin wise)

Additionally, the removal of email to post (#22942 related to this ticket) is getting punted along with it. Same reasoning.

We'll tackle all the pages along with the rewrite for next release. I'll start working on that while we still have this release (4.3) going on, that way we can look at an early release of the feature plugin in the 4.4 window.

[chriscct7]

Going to start refreshing the patch for this, and make a featured plugin using @jeremyfelt's proposed method found in comment:35

[peterwilsoncc]

I realise I am late to the ticket so feel free to discard.

Changing siteurl requires file level changes, does this make it a worthy candidate to remove from the UI?

[chriscct7]

Replying to peterwilsoncc:

I realise I am late to the ticket so feel free to discard.

Changing siteurl requires file level changes, does this make it a worthy candidate to remove from the UI?

I'm confused a bit by your question, but siteurl isn't proposed for removal

[peterwilsoncc]

Replying to chriscct7:

I'm confused a bit by your question, but siteurl isn't proposed for removal

That was my - poorly phrased - question. Thanks.

[chriscct7]

Plugin of patch 1

[chriscct7]

Round 1 at this

[chriscct7]

Uploaded the first round at a core patch for this. There is also a plugin that can be downloaded and installed to emulate the same changes.

Note: if applying a patch or using the plugin, you will need to do it on a new copy of WordPress/trunk, as the settings are conditionally removed based on inital db version. For those who want to test the patch, you must be on a pretty up to date copy of trunk, as there's been some churn in those settings files right before the patch was made (so it won't apply much earlier than current trunk).

Note: the plugin doesn't handle the backfilling of plugins that register into actions, as that can't be done from a plugin. For the full experience, you'll need to use the patch file.

[chriscct7]

Plugin of patch 1 (submitted to wp.org plugins repository)

[johnbillion]

Replying to peterwilsoncc:

Changing siteurl requires file level changes, does this make it a worthy candidate to remove from the UI?

#10970

[obenland]

The check for removed option groups could be simplified to

<?php
if ( in_array( $page, array( 'writing', '...' ) ) { 
         _deprecated_argument( __FUNCTION__, '4.4', sprintf( __( 'The "%s" options group has been removed. Use another settings group.' ), $page ) ); 
        $page = 'general'; 
}

We should probably also take advantage of the opportunity and properly format the code that we move over.

[ryan]

Settings > General with the plugin active, Macnchrome

[ryan]

Setting general, scrolled down

[ryan]

For comparison, here is how dotcom handles settings reduction. Macnchrome.

[ryan]

dotcom settings scrolled down, macnchrome

[chriscct7]

Replying to obenland:

The check for removed option groups could be simplified to

<?php
if ( in_array( $page, array( 'writing', '...' ) ) { 
         _deprecated_argument( __FUNCTION__, '4.4', sprintf( __( 'The "%s" options group has been removed. Use another settings group.' ), $page ) ); 
        $page = 'general'; 
}

We should probably also take advantage of the opportunity and properly format the code that we move over.

I concur. I'll do that on the next pass

[ryan]

dotcom settings on an iPhone 6+. There are no submenus, making for a better touch experience.

[ryan]

dotcom settings showing selector, iPhone 6+

[ryan]

Attached are some shots of dotcom's settings simplification. Some things to like:

• Writing remains so that plugins like Press This Extended don't turn general settings into a long scroll.
• There are no Settings submenus in the admin menu. Submenu elimination brings us closer to touch usability. ​https://make.wordpress.org/flow/2015/06/13/the-top-5-impediments-to-flow-on-touch-devices/#submenus

An Import settings tab is in the works.

[chriscct7]

Replying to ryan:

Attached are some shots of dotcom's settings simplification. Some things to like:

• Writing remains so that plugins like Press This Extended don't turn general settings into a long scroll.
• There are no Settings submenus in the admin menu. Submenu elimination brings us closer to touch usability. ​https://make.wordpress.org/flow/2015/06/13/the-top-5-impediments-to-flow-on-touch-devices/#submenus

An Import settings tab is in the works.

I like no-submenus thing, but I'm not going to have the time to shepard a UX change like that through 4.4. In an ideal world, the settings pages would also have some sort of API even if that just means putting all the settings's HTML into a PHP array that can be passed through a filter so people can add and remove settings more easily (same would go for the user settings pages). If someone is wanting to work on either of those I'll be happy to help with it.

[obenland]

Replying to chriscct7:

In an ideal world, the settings pages would also have some sort of API […] so people can add and remove settings more easily.

Like the Settings API?

[chriscct7]

Replying to obenland:

Replying to chriscct7:

In an ideal world, the settings pages would also have some sort of API […] so people can add and remove settings more easily.

Like the Settings API?

It could be the settings API. Ideally it would be.

Also related: #15865

[chriscct7]

For those wanting to test the plugin and want updates on it through the normal WordPress update routine, its available via ​https://wordpress.org/plugins/wp-core-settings-reduction-project/.

[chriscct7]

Should mention in case there's a conflict in the future, the patch is based on r34202

[chriscct7]

From the related #15865, this is what moving to the Settings API could look like: https://core.trac.wordpress.org/attachment/ticket/15865/example_settings.diff

However, doing so removes the possibility of future compatibility (in otherwards, making the pages more extendable eliminate future options to redo the pages, since it could break backwards compat to do so).

[chriscct7]

Per discussion with Helen on Slack, Post by Emails removal is getting split out of this and will be merged first

[claytoncollie]

@chriscct7 This is a very good idea and I am curious why it was never included. Do you think there is any appetite to start the discussion again?

[desrosj]

While this may still be a worthy effort, a fresh analysis needs to be performed as 7+ years have passed and the previous data is likely to have changed (for better or worse).

Without someone willing to lead this effort, I'm going to close this one out as a maybelater. Discussion can always continue on closed tickets and it can be reopened in the future should conditions change.