Opened 15 years ago
Closed 13 years ago
#18242 closed defect (bug) (fixed)
Changing domain for a network blog make faulty changes in database
| Reported by: | darkwhispering | Owned by: | nacin |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.7 |
| Component: | Multisite | Version: | 3.0 |
| Severity: | major | Keywords: | has-patch dev-feedback |
| Cc: | Focuses: |
Description
When changing the domain for a network blog, if the network is set up on a subdomain and using sub-folder options for blogs, the save to the database is faulty, saving wrong urls.
The network main site uses eg http://my.blog.com and the blogs has http://my.blog.com/blog1
When changing the domain for blog1 in "Network admin -> All Sites -> Edit blog1" and choose to also update "home and siteurl" the new url for home and site become http://blog.com/blog1/my
Happens in both Firefox 5 and Safari 5.1
Attachments (3)
Change History (25)
#2
@
15 years ago
All plugins is deactivated and the installation is fresh, but it is local, forgot to mention that is the above description.
I and a co-worker of mine have this bug/problem with fresh localhost WP install on Mac OS X Snow Leopard and Lion using the built-in apache and mysql.
#3
@
15 years ago
I've created the exact same structure on a local installation of 3.3-trunk, but whatever I enter into Domain and Path fields for blog1 and whether I check “Update siteurl and home as well” or not, it just saves what I entered.
I may be missing some step. What are the domain and path you set there?
#4
@
15 years ago
- Installing WP in a subdomain like http://my.blog.com
- Turn it into a Network with the subfolder option so the future blogs will have http://my.blog.com/blog1
- For the "blog1" in network admin I change domain to http://my.blog.org and leave the path as it is (blog1)
- Check the "update siteurl and home as well" checkbox
- Update
- Taking a look in the database, and the siteurl and home url now looks "http://blog.org/blog1/my
I have not yet done a new install myself, will do that soon, and then try this again to see what happens.
#5
@
15 years ago
- Keywords needs-patch added
Ah, I didn't look in the database, because Edit Site screen still displayed valid data. Now I see it.
#7
@
15 years ago
- Keywords has-patch added; needs-patch removed
Introduced in [12978] as a fix #12119:
$blog_address = get_blogaddress_by_domain($_POST['blog']['domain'], $_POST['blog']['path']);
This is the only place in core where get_blogaddress_by_domain() is used.
Related WPMU changeset:
r266. If I had to guess, it has something to do with WPMU working in a subfolder.
Not sure if it's a good idea to change get_blogaddress_by_domain() due to backward compatibility reasons, so I've attached patches with two different attempts to fix the issue.
#8
@
15 years ago
- Cc added
- Keywords dev-feedback added
- Severity normal → major
- Version 3.2.1 → 3.3
In my opinion opinion this should be fix soon. This will break WordPress functionality since the url can't be access.
#10
@
15 years ago
- Milestone Awaiting Review → 3.4
- Version 3.3 → 3.0
Version number indicates when the bug was initially introduced.
#13
@
13 years ago
- Milestone Future Release → 3.7
Moving to 3.7 for discussion, this seems a little ugly to be hanging out there.
#14
@
13 years ago
I've run into this as well. get_blogaddress_by_domain() seems pretty lame and should probably just get axed once it is no longer used here.
Not sure why one patch checks HTTP_HOST. The other patch seems sufficient — but I'll note that should be esc_url_raw().
It seems like the changes in [12978] shouldn't have happened. Maybe ryan has some ideas. A straight update_option() makes the most sense — the original check occurring before [12978] was unnecessary anyway as update_option() would have handled the equals comparison.
#17
@
13 years ago
18242.3.diff is @SergeyBiryukov's first patch with esc_url_raw()
#19
@
13 years ago
- Resolution fixed
- Status closed → reopened
Maybe this should handle things like trimming/adding forward slashes to ensure that the domain and path come together well? Also, these values could probably benefit from stripping backslashes, as they come directly from $_POST.
#20
@
13 years ago
See #18117 for related ugliness on slashes for that screen. There could be several areas where that should be tightened up.
#21
@
13 years ago
18117.diff on #18117 should address remaining concerns here as well.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Cannot reproduce. Have you tried with all plugins deactivated?