WordPress.org

Make WordPress Core

Opened 9 years ago

Last modified 5 months ago

#16126 new defect (bug)

Multisite name conflict check doesn't check for pages.

Reported by: Ipstenu Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Permalinks Keywords: needs-patch
Focuses: multisite Cc:
PR Number:

Description

Running WP 3.1-RC2 I made a page off my main site called foobar.

Then I went in and made a sub-site (using SubFOLDERS) called foobar.

The subsite took precedence and there was NO check or warning.

I was able to reproduce this on 3.0.4

Then I went the otherway. I have a subsite called camels (don't ask). I went to make a PAGE called camels and it also let me. No conflict check.

Basically you have to add the main blog page names into the banned names list manually, which strikes me as a bit odd. I can see why checking that would be onerous if someone had 600 million pages (and we all know they do) but forcing people to do it manually seems like a gap.

Need love! :D

This is minor, since not a lot of people have bitched, so clearly we're not running into it YET.

Change History (6)

#1 @Ipstenu
9 years ago

And before someone says 'That's what the blog slug is for', remember that PAGES aren't behind the blog slug, just POSTS. Should that be changed? I would say no. The way it works now is perfect. There just needs some sanity checking going on in both places.

#2 @nacin
9 years ago

This is probably a duplicate of another ticket that was punted late in the 3.0 cycle.

The goal would be to enforce global slug checking -- that wp_unique_post_slug() also needs to check for the slugs of blogs when running a subdirectory.

#3 @nacin
9 years ago

  • Component changed from General to Multisite
  • Milestone changed from Awaiting Review to Future Release

Punting for now.

#4 @jeremyfelt
6 years ago

  • Component changed from Multisite to Permalinks
  • Focuses multisite added

#5 @jeremyfelt
4 years ago

  • Keywords needs-patch added
  • Version set to 3.0

We've actually found this strangely useful. We can setup a landing page at example.org/camels/ and then build out a full site at dev.example.org/camels/ until it's ready. Once switched, the site wins over the page and we can ignore it exists. :)

That's very specific, obviously. I think a conflict check would be useful, which isn't too difficult because there are a limited number of sites we'd need to check for conflict. I'd lean toward throwing a warning/confirmation instead of blocking it outright.

#6 @Ipstenu
4 years ago

Wait you're changing dev.example.com/camels/ into a subfolder site named example.com/camels/? That's an... Huh.

Warning would work. "There already exists a page on your main site called 'camels.' Creating this site will override the page."

Note: See TracTickets for help on using tickets.