Make WordPress Core

Opened 14 years ago

Last modified 13 months ago

#10970 new enhancement

Remove 'siteurl' setting from options-general.php

Reported by: scribu's profile scribu Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Permalinks Keywords: has-patch
Focuses: administration Cc:

Description

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)

Attachments (6)

10970.diff (2.1 KB) - added by scribu 14 years ago.
Remove siteurl field from options-general.php
10970.2.diff (2.7 KB) - added by scribu 14 years ago.
Make www preference consistent
10970.3.diff (2.4 KB) - added by scribu 14 years ago.
instead of removing the siteurl field, just disable it
siteurl.php (2.2 KB) - added by nacin 14 years ago.
From dd32.
prevent_url_mod.diff (992 bytes) - added by desmith 7 years ago.
Patch copied from #41595
10970-readonly.diff (3.9 KB) - added by sabernhardt 13 months ago.
use readonly for fields; add constant to override

Download all attachments as: .zip

Change History (45)

#1 @k_nitin_r
14 years ago

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.

#2 @hakre
14 years ago

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
14 years ago

Remove siteurl field from options-general.php

#3 @scribu
14 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 3.0

@scribu
14 years ago

Make www preference consistent

#4 @scribu
14 years ago

The second patch also addresses #9873

#5 @scribu
14 years ago

  • Cc scribu@… added

#6 follow-up: @azaozz
14 years ago

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.

#7 @hakre
14 years ago

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.

#8 in reply to: ↑ 6 @scribu
14 years ago

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.

#9 @scribu
14 years ago

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.

#10 @scribu
14 years ago

Marked #11934 as dup of this.

@scribu
14 years ago

instead of removing the siteurl field, just disable it

#11 @scribu
14 years ago

  • Keywords commit added

10970.3.diff keeps the siteurl field for reference.

@nacin
14 years ago

From dd32.

#12 @scribu
14 years ago

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?

#13 @scribu
14 years ago

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

#14 @dd32
14 years ago

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?

#15 @scribu
14 years ago

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.

#16 @Denis-de-Bernardy
14 years ago

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.

#17 @scribu
14 years ago

  • Keywords commit removed
  • Milestone changed from 3.0 to Future Release

Guess this isn't ready for 3.0.

#18 @scribu
14 years ago

Similar: #10970

#19 @mrmist
14 years ago

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

#20 @nacin
13 years ago

  • Keywords 3.2-early added

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.

#21 @kirasong
12 years ago

  • Cc mike.schroder@… added

#22 @Ipstenu
12 years ago

  • Cc ipstenu@… added

#23 @nacin
12 years ago

  • Keywords 3.2-early removed
  • Milestone changed from Future Release to 3.5

#24 @MikeHansenMe
11 years ago

  • Cc mdhansen@… added

#25 @nacin
11 years ago

  • Milestone changed from 3.5 to Future Release

#26 @MikeHansenMe
11 years ago

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.

#27 @Ipstenu
11 years ago

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.

#28 @xibe
11 years ago

  • Cc xavier@… added

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.

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


10 years ago

#30 @nacin
10 years ago

  • Component changed from Administration to Permalinks
  • Focuses administration added

#32 @ericlewis
8 years ago

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?

#33 @dd32
8 years ago

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.

#34 @SergeyBiryukov
8 years ago

#35634 was marked as a duplicate.

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


8 years ago

#36 @SergeyBiryukov
7 years ago

#41595 was marked as a duplicate.

@desmith
7 years ago

Patch copied from #41595

#37 @desmith
7 years ago

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

I suspect my use case isn't uncommon -- we host a few hundred separate WP installs (long story), and they're all managed centrally by a single IT team. There's no way for our users to change their own URLs and have it work; they don't have access to DNS, for instance. Every so often, one of our content creators sees this box and gets ideas, and then we have to rush about to clean up their broken production site (it's always production). My patch simply hides those fields from the user, in a fairly clean way.

A friend on Twitter asked why I went with a define instead of a filter -- I simply chose that because the two settings I'm hiding also can be disabled with their own defines (the ever-popular WP_HOME and WP_SITEURL defines). Seemed more internally consistent to implement it this way.

Last edited 7 years ago by desmith (previous) (diff)

This ticket was mentioned in Slack in #core by sergey. View the logs.


4 years ago

@sabernhardt
13 months ago

use readonly for fields; add constant to override

#39 @sabernhardt
13 months ago

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.
Note: See TracTickets for help on using tickets.