Opened 13 years ago
Closed 13 years ago
#19799 closed defect (bug) (wontfix)
define('RELOCATE', true) update the "siteurl" option, but not the "home" option
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.3 |
Component: | Upgrade/Install | Keywords: | has-patch |
Focuses: | Cc: |
Description
define('RELOCATE', true) will update the "siteurl" option, but not the "home" option.
Things like the_permalink() use home_url(), which uses the "home" option, so URLs break after using RELOCATE. Post permalinks, "Visit Site" in the admin, etc, all point to the old domain.
Steps to reproduce: set up a blog at one domain, say "http://example.com" and then use RELOCATE to relocate the blog to "http://example.local". Links in the admin will work, but "Visit Site" in the admin bar will point to the old domain. Likewise, permalinks and other links on the frontend of the site will also still point to the old domain.
Is this by design?
I'm attaching a patch that also updates the "home" option when using RELOCATE.
Attachments (1)
Change History (10)
#2
in reply to:
↑ 1
;
follow-up:
↓ 4
@
13 years ago
Replying to SergeyBiryukov:
As I see it (according to Codex), the single purpose of
RELOCATE
is to be able to log in to the admin section and fix thehome
option manually.
Hmm, I didn't come to the same conclusion from the documentation. The first sentence talking about RELOCATE
:
WordPress supports an automatic relocation method that will figure out and update those values for you automatically.
Emphasis added. "Those values" appear to refer to the siteurl and home options that the previous section had instructed you to update.
It could be by design, but then it doesn't make sense that the documentation would instruct you in detail how to update both "siteurl" and "home", then point you to a preferred method that only updates "siteurl", still leaving you with the extra step to update "home" yourself. Using RELOCATE
to update "home" in addition to "siteurl" doesn't appear to cause any problems, and in my case, is quite helpful.
But, that said, my question still remains -- if this is by design (e.g., there's a specific reason *not* to update "home" here), or an oversight?
#3
@
13 years ago
In cases where the WordPress files are stored within a subdomain (home URL != Site URL), RELOCATE would have 2 courses of action for updating the value. Simply alter the domain name part, or update the path as well - which might not be as straight forward as expected.
But you're right, the documentation in the codex isn't clear, and can often be wrong, It's designed to allow you to gain access to the admin area again (remembering, that without it, you can't login to a site that's changed it's location). It shouldn't be used as a magic migration path IMO. (Can we just add a admin notice for when relocate is defined as to what to fix, and to remove the constant asap?)
#4
in reply to:
↑ 2
@
13 years ago
Replying to mintindeed:
"Those values" appear to refer to the siteurl and home options that the previous section had instructed you to update.
Yeah, but it also specifically says that home
will not be updated automatically:
When the RELOCATE flag is set to true, the Site URL (NOT the home setting) will be automatically updated to whatever path you are using to access the login screen. This will get the admin section up and running on the new URL, but it will not correct any other part of the setup. Those you will still need to alter manually.
Perhaps the confusing part about "those values" should just be reworded or removed.
#5
@
13 years ago
So the short answer is the documentation needs to be clarified. If that's all, then I guess this ticket can be closed.
I'm probably not the right person to update the codex documentation, because I still find the difference between siteurl
and home
confusing. To see if I understand it correctly: siteurl
is an HTTP path where the site files are located and home
is the "frontend" url? So on a subdomain install with domain mapping enabled, siteurl
might be http://myblog.example.com
and home
would be http://myblog.com
, but on subdirectory installs they would both be http://example.com/myblog
?
Adding to the confusion is how the codex documentation gives instructions and examples that include updating both these options at the same time (and with the same values), but apparently that's not how the RELOCATE
method should work.
As I see it (according to Codex), the single purpose of
RELOCATE
is to be able to log in to the admin section and fix thehome
option manually.