WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 3 months ago

#10970 new enhancement

Remove 'siteurl' setting from options-general.php

Reported by: 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 (5)

10970.diff (2.1 KB) - added by scribu 8 years ago.
Remove siteurl field from options-general.php
10970.2.diff (2.7 KB) - added by scribu 8 years ago.
Make www preference consistent
10970.3.diff (2.4 KB) - added by scribu 8 years ago.
instead of removing the siteurl field, just disable it
siteurl.php (2.2 KB) - added by nacin 8 years ago.
From dd32.
prevent_url_mod.diff (992 bytes) - added by desmith 3 months ago.
Patch copied from #41595

Download all attachments as: .zip

Change History (42)

#1 @k_nitin_r
8 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
8 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
8 years ago

Remove siteurl field from options-general.php

#3 @scribu
8 years ago

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

@scribu
8 years ago

Make www preference consistent

#4 @scribu
8 years ago

The second patch also addresses #9873

#5 @scribu
8 years ago

  • Cc scribu@… added

#6 follow-up: @azaozz
8 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
8 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
8 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
8 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
8 years ago

Marked #11934 as dup of this.

@scribu
8 years ago

instead of removing the siteurl field, just disable it

#11 @scribu
8 years ago

  • Keywords commit added

10970.3.diff keeps the siteurl field for reference.

@nacin
8 years ago

From dd32.

#12 @scribu
8 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
8 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
8 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
8 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
8 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
8 years ago

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

Guess this isn't ready for 3.0.

#18 @scribu
7 years ago

Similar: #10970

#19 @mrmist
7 years ago

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

#20 @nacin
7 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 @mikeschroder
5 years ago

  • Cc mike.schroder@… added

#22 @Ipstenu
5 years ago

  • Cc ipstenu@… added

#23 @nacin
5 years ago

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

#24 @MikeHansenMe
5 years ago

  • Cc mdhansen@… added

#25 @nacin
5 years ago

  • Milestone changed from 3.5 to Future Release

#26 @MikeHansenMe
5 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
5 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
4 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.


4 years ago

#30 @nacin
4 years ago

  • Component changed from Administration to Permalinks
  • Focuses administration added

#32 @ericlewis
2 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
2 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
22 months ago

#35634 was marked as a duplicate.

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


20 months ago

#36 @SergeyBiryukov
3 months ago

#41595 was marked as a duplicate.

@desmith
3 months ago

Patch copied from #41595

#37 @desmith
3 months 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 3 months ago by desmith (previous) (diff)
Note: See TracTickets for help on using tickets.