Opened 15 years ago
Last modified 22 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 (6)
Change History (45)
#2
@
15 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.
#3
@
15 years ago
- Keywords has-patch added; needs-patch removed
- Milestone changed from Future Release to 3.0
#6
follow-up:
↓ 8
@
15 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
@
15 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
@
15 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 inhome
? Or perhaps can test any new value forhome
with JS and try to match it tositeurl
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
@
15 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.
#12
@
15 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
@
15 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
@
15 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
@
15 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
@
15 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
@
15 years ago
- Keywords commit removed
- Milestone changed from 3.0 to Future Release
Guess this isn't ready for 3.0.
#20
@
14 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.
#26
@
12 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
@
12 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
@
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.
11 years ago
#32
@
9 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
@
9 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.
This ticket was mentioned in Slack in #core by johnbillion. View the logs.
9 years ago
#37
@
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.
This ticket was mentioned in Slack in #core by sergey. View the logs.
5 years ago
#39
@
22 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 todisabled
. - 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 atrue
value, either inwp-config.php
or in a plugin. - The constant also could honor a
false
value and force the fields to remain editable.
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.