Remove 'siteurl' setting from options-general.php

[scribu]

From #10957:

azaozz:

Better to fix the cause for this: "WordPress address" (siteurl) shouldn't be changeable from Settings->General at all as it cannot be set safely there. Most users would just break their blogs if they change it.

It is set at install and only needs changing when WordPress is moved to another domain or (sub)directory. This happens very rarely and there are other (better?) ways to set siteurl.

Denis-de-Bernardy:

in this case, we need to make sure the www. pref is passed on to the site_url. else we're bound to get massive bugs (e.g. #9873)

[k_nitin_r]

Shouldn't we add an option to prevent redirecting from WordPress entirely? Some people have a localhost installation and would prefer to share their new development with other developers over a network. Editing the wp-config or changing the configuration setting value is an added inconvenience.

[hakre]

Related: #10957 (Use the RELOCATE constant to fix blogs.)

@k_nitin_: There will be always need for configuration. Configuration means that you actually can control the application which is a very important aspect of using it.

It looks to me that the topic is to find how to deal best with known problems.

[scribu]

Remove siteurl field from options-general.php

[scribu]

Make www preference consistent

[scribu]

The second patch also addresses #9873

[azaozz]

The patch looks good but I'm thinking about the UI: do we show the siteurl (not changeable) and do we test for upper case characters in home? Or perhaps can test any new value for home with JS and try to match it to siteurl showing a warning if mismatched because of different case? Can possibly handle the www. matching from JS too.

[hakre]

Is there a way to setup this value in setup? Or is this done autmatically?

Related?!: #10447

If this commit comes in, supporters will be glad to have a tool at hand that changes a site's siteurl.

[scribu]

Replying to azaozz:

The patch looks good but I'm thinking about the UI: do we show the siteurl (not changeable) and do we test for upper case characters in home? Or perhaps can test any new value for home with JS and try to match it to siteurl showing a warning if mismatched because of different case? Can possibly handle the www. matching from JS too.

We could show it disabled, for reference.

I think the validation should first be done on the PHP level and then we can think about validation on the UI level.

Is there a way to setup this value in setup? Or is this done autmatically?

It's done automatically on setup.

If you really wanted to change it, I think you could do it with a custom install.php.

[scribu]

If this commit comes in, supporters will be glad to have a tool at hand that changes a site's siteurl.

You could still use options.php to change it.

[scribu]

Marked #11934 as dup of this.

[scribu]

instead of removing the siteurl field, just disable it

[scribu]

10970.3.diff keeps the siteurl field for reference.

[nacin]

From dd32.

[scribu]

Regarding siteurl.php:

That check is pretty sweet. The question is: are there any cases where you won't get an error?

If so, are they common enough to warrant the existence of the field?

[scribu]

In the IRC, wpmuguru pointed out that a user moving to a different domain could safely change the SITEURL from the admin.

That's fine, but that doesn't happen so often that it has to be part of Core. The same could be said for the 'home' option.

We could remove these two fields and write a plugin with the following options:

• www preference

• make homepage be different from the directory you installed WordPress

Also, as said before, advanced users can edit the options directly by going to wp-admin/options.php

[dd32]

IMO, The fields need to stay as part of Core, Its a core setting which the user may need to change, Whilst it doesnt happen that often to most users, its required often enough to be included.

Theres an ancient ticket somewhere that i wrote that code for, I cant find it now however (And havnt been able to for awhile, all i remember was Matt gave it a +1 i believe)

If anything, I think the fields should be replaced with a wizard, Else, Just some checking and preventing users from setting it to something invalid would suffice.

Also, I think the www. prefix is being forced the wrong way around in that patch, SiteURL should enforce its prefix upon homeurl, not the other way around?

[scribu]

Also, I think the www. prefix is being forced the wrong way around in that patch, SiteURL should enforce its prefix upon homeurl, not the other way around?

It's the other way around because in the patch, the homeurl is the only one that can be changed.

[Denis-de-Bernardy]

I use this, myself:

	function readonly_url() {
		$home_url = get_option('home');
		$site_url = get_option('siteurl');
		
		$home_www = strpos($home_url, '://www.') !== false;
		$site_www = strpos($site_url, '://www.') !== false;
		
		if ( $home_www != $site_www ) {
			if ( $home_www )
				$site_url = str_replace('://', '://www.', $site_url);
			else
				$site_url = str_replace('://www.', '://', $site_url);
			update_option('siteurl', $site_url);
		}
		
		if ( !defined('WP_HOME') )
			define('WP_HOME', $home_url);
		if ( !defined('WP_SITEURL') )
			define('WP_SITEURL', $site_url);
	} # readonly_url()

No-one has broken a site since.

[scribu]

Guess this isn't ready for 3.0.

[scribu]

Similar: #10970

[mrmist]

Related #14865, I'd like to see one or t'other, don't mind which :)

[nacin]

We like this for when we re-do the settings API.

This should probably be a wizard or something, and hidden where possible, and validated (see dd32's plugin) otherwise.

[nacin]

See comment:2:ticket:21735.

[MikeHansenMe]

I would really like to see this in 3.6. I cannot count how many times I have had clients try to adjust this and break it.

[Ipstenu]

Is there any possibility of getting this to work for Multisite as well?

I've been seeing a rash of people changing foo.domain.com to foo.com and wondering why it broke their site.

[xibe]

This really needs to happen. Too many are breaking their site thinking these settings are innocuous, and are not techy enough to fix it afterwards.

These two settings should at the very least have a clear warning text next to them (and be at the bottom of the page), or be hidden from view unless a a constant is set to true in wp-config.php.

[jeremyfelt]

Related #29794

[ericlewis]

This came up at the community summit, cc @johnbillion.

Anyone interested in leading a conversation around this for 4.5?

@dd32 said:

IMO, The fields need to stay as part of Core, Its a core setting which the user may need to change, Whilst it doesnt happen that often to most users, its required often enough to be included.

What's the flow of a user changing the siteurl via the admin interface?

[dd32]

What's the flow of a user changing the siteurl via the admin interface?

I guess there's several different things that the siteurl fields can be used for. In my case I was thinking about shifting from a subdirectory to a non-subdirectory install. (Which is easily doable using the admin interface)

There's another ticket which suggests adding validation to the siteurl fields instead to prevent it being changed when it would result in a broken site.

[SergeyBiryukov]

#35634 was marked as a duplicate.

[SergeyBiryukov]

#41595 was marked as a duplicate.

[desmith]

Patch copied from #41595

[desmith]

Re-uploading a patch I'd written for #41595. As a workaround, while TPTB discuss a "proper" longer-term solution, this simply checks for a define('WP_DISABLE_URLCHANGES') and, if so defined, hides those fields. Suitable for use in wp-config.php, probably would work in a site-specific plugin too (haven't tested that yet).

[sabernhardt]

use readonly for fields; add constant to override

[sabernhardt]

10970-readonly.diff​ is messy, but it roughly shows my idea for preventing unintended changes on single sites. I think other contributors could add the script to enable the fields and disable the buttons (without reloading the page) better than I can. I did not attempt any field validation either.

• The fields are readonly because I received validation errors when they were set to disabled.
• If someone deactivates JS, clicking one of the buttons would reload the page with active URL fields (and no buttons).
• A WP_DISABLE_URL_CHANGES constant could remove the URL settings entirely with a true value, either in wp-config.php or in a plugin.
• The constant also could honor a false value and force the fields to remain editable.