WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 5 years ago

#23270 closed enhancement (duplicate)

Links are not updated when changing a multisite path

Reported by: Clorith Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Permalinks Keywords:
Focuses: Cc:

Description

When changing the path of a site under a network install, URIs are not updated in post_content.

I know this can be achieved with search and replace plugins (and that this is how regular WP installs work), but the wording on the edit site page makes it appear as if WP should be updating this for you with; "Update siteurl and home as well.", where the "as well" makes it sound as if other elements on your site will be updated regardless.

I'm not sure if the best approach would just be a re-wording of this area, or if implementing a function to update post_content when this is modified is the way to go.

Attachments (1)

23270.diff (1.2 KB) - added by Ipstenu 7 years ago.
Change language to be more clear.

Download all attachments as: .zip

Change History (13)

#1 @SergeyBiryukov
8 years ago

Updating the links in content doesn't seem feasible, due to scalability reasons. We don't do that in single site when changing home or siteurl, so I don't think we should do it in Multisite. Rewording is probably the only option here.

"Update siteurl and home as well.", where the "as well" makes it sound as if other elements on your site will be updated regardless.

FWIW, it doesn't sound that way for me.

#2 @jeremyfelt
7 years ago

  • Keywords ux-feedback close added

Agreed that replacing links in post_content is not feasible.

Checkbox to update siteurl and home is located here: http://core.trac.wordpress.org/browser/trunk/src/wp-admin/network/site-info.php#L143

Not sure if the messaging can change much to be explicit about post_content.

Guessing wontfix, but adding ux-feedback as well.

#3 @Ipstenu
7 years ago

I'd just wontfix, given that if you change your siteurl and home in single site, your post content doesn't magically get updated either. BUT.

I think "Update both siteurl and home values." would be more clear. Attaching patch.

@Ipstenu
7 years ago

Change language to be more clear.

#4 @SergeyBiryukov
7 years ago

  • Milestone changed from Awaiting Review to 3.7

#5 @Ipstenu
7 years ago

  • Keywords has-patch added; close removed

#6 @nacin
7 years ago

I've never understood this checkbox. When do you *not* want to check it?

Also, we should try to slowly improve the friendliness of multisite's UI. That may mean dropping option key names. :)

#7 @Ipstenu
7 years ago

If it's in a subfolder, I can see that being iffy, but I'd have to test that with WP Multisite in a subfolder to see if it really matters. I don't think it would and I'd always want to check it.

#8 @nacin
7 years ago

I don't find Update both <code>siteurl</code> and <code>home</code> values. to be very friendly. But I also don't really know what we could do here to make it more friendly while not opening the door to breaking domain mapping plugins. Suggestions welcome. All I know is this whole process sucks.

#9 @Ipstenu
7 years ago

Hide them?

The plugins, IIRC, don't need to SEE them, and you don't actually change them, you filter them.

Really the only time I ever want to change 'em is when I move a site from foo.domain.com to bar.domain.com, but even then, a serialization search/replace would be saner.

#10 @jeremyfelt
7 years ago

  • Keywords ui-feedback added; has-patch removed
  • Milestone changed from 3.7 to Future Release

Punting this to a future release. There's probably something we can do here with the Update both <code>siteurl</code> and <code>home</code> values as part of general multisite UI improvement.

#11 @jeremyfelt
7 years ago

  • Component changed from Multisite to Permalinks
  • Focuses ui multisite added

#12 @chriscct7
5 years ago

  • Focuses ui multisite removed
  • Keywords ux-feedback ui-feedback removed
  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Severity changed from minor to normal
  • Status changed from new to closed

Removed in #32503

Note: See TracTickets for help on using tickets.