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)

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.

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.

Remove siteurl field from options-general.php

Make www preference consistent

The second patch also addresses #9873

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.

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.

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.

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.

Marked #11934 as dup of this.

instead of removing the siteurl field, just disable it

10970.3.diff keeps the siteurl field for reference.

From dd32.

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?

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

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?

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.

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.

Guess this isn't ready for 3.0.

Similar: #10970

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

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.

See comment:2:ticket:21735.

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.

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.