Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#19799 closed defect (bug) (wontfix)

define('RELOCATE', true) update the "siteurl" option, but not the "home" option

Reported by: mintindeed's profile mintindeed 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)

wp-login-relocate-home.patch (673 bytes) - added by mintindeed 12 years ago.

Download all attachments as: .zip

Change History (10)

#1 follow-up: @SergeyBiryukov
12 years ago

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 the home option manually.

#2 in reply to: ↑ 1 ; follow-up: @mintindeed
12 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 the home 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 @dd32
12 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 @SergeyBiryukov
12 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 @mintindeed
12 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.

#7 @SergeyBiryukov
12 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

#8 @SergeyBiryukov
12 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

#9 @SergeyBiryukov
12 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.