You have to empty the trash.
Thread Starter
ldwp
(@ldwp)
You have to empty the trash.
what for?
the point is that if you DON’T empty the trash, and instead untrash an article that has the same name as one you’ve made since trashing the first, you will get a name collision.
I don’t need to know how to avoid this, I’m suggesting that this behaviour be changed in a later version.
Nope. Not gonna happen. You have to empty the trash, because until then, there remains a possibility you want the page back (otherwise you would have, y’know, emptied the trash). If we don’t do that, then if you make pagename, trash it, make another, and realize you wanted the FIRST one back, there would be all sorts of issues.
Not a bug, a documented feature.
(BTW – appending the number to the post name is what WP has always done for name collisions, so it’s basically doing what you describe here:
or maybe include the slugs of trshed posts and pages when checking for duplicates at the post creation stage.
You can’t have a dupe as long as the page exists. TRash is soft-delete.)
Thread Starter
ldwp
(@ldwp)
I think we might be getting our wires crossed here – I already know WP will append a number to a slug if you make a duplicate (under most circumstances), I’m not suggesting that changes.
However if you change the permalinks *after* creating the first trashed post, make a new one with the same name, then untrash the first post, you WILL get a slug name collision, hard cheese.
I think there should be a check for this, in order to avoid them. Yes a workaround might be to empty the trash, great – but a better solution would be to programatically check slugs for collisions when permalinks are changed, which would avoid the need for a workaround.
If you are in any doubt about this please see the first post, follow instructions to re-create and post results – even if you get different results I’d be interested to know.
If this is documented, can you point me to it?
You’re right, I read that backwards. The trashed post shouldn’t let that happen, though. It’s supposed to say “You can’t use that name slug, it’s already in-use.” And in fact, I can’t recreate the problem.
* URLs are /YYYY/postname
* Make a post named blogsite
* save and trash blogsite
* change URLs to /postname
* make a post named blogsite, slug is correctly blogsite-2
I repeated it TWICE to be sure. Works exactly the way it’s supposed to.
Mind then I did this:
* Make a post named ‘foobar’
* Trash foobar.
* Make another post named foobar. Slug is foobar-2
* Change permalinks to postname
* Make a third post named foobar… Slug is foobar-2
So something happened there. And I can repeat that every single time.
I can confirm that. You simply cannot manually remove the -2 from the second post whilst the first is still in the Trash. It’s something I’ve had to explain to users time after time.
Thread Starter
ldwp
(@ldwp)
So something happened there. And I can repeat that every single time.
Yeah, that’s what I see too.
It seems to be when you change permalinks that things can slip through – in my case I changed from the default (?postId=postId) to postname, and doing the trashing / untrashing as above, got the same result.
Although I think you found a different way than me, I could recreate it with the first method. I’ll try this again today & post results.
Thanks
Thread Starter
ldwp
(@ldwp)
OK I missed something the first time around – it’s actually much simpler than I thought.
Change permalinks to %postname%
Create a post called ‘thepost’.
Create a page called ‘thepost’.
This page and the post will both have the same slug.
Can anyone confirm this, and if it is intended or buggy?
It’s not a bug, per se but yes, that can happen.
Permalink collisions are post-type specific. Which is to say all POSTS are checked for ‘thepost’ when you make that post, but NOT pages or any custom post-types.
I’ve also seen it happen with attachments.
Thread Starter
ldwp
(@ldwp)
Thanks for the replies guys.
Permalink collisions are post-type specific.
That’s interesting, why is it that WP only checks the current post-type for slug collisions? Does it only become a problem if the slug collision happens for posts with the same post-type?
I’ve also seen it happen with attachments.
Well spotted – I haven’t seen this yet but I’ll keep prodding it to see if I can get a better test case written up.
I’m still not clear on whether or not this actually causes an issue, in the first instance what happened was that I would get the page content rather than the post content associated with a collided slug. Not an error as such but certainly undesired behaviour.
It could be a pain to spot and sort out if you didn’t know what to look for.
Think I should post a bug report?
I haven’t seen this yet but I’ll keep prodding it to see if I can get a better test case written up.
It tends to occur when an attachment has been inserted with a link to a Post Url (attachment page) as opposed to a File Url. If the attachment’s name/slug happens to replicate (for example) an existing Page slug, you get a collision – and a pretty confused site owner.
Think I should post a bug report?
You could try but then there has been talk of completely overhauling permalink handling. It could be that these scenarios are already (a) known about and (b) being considered as part of the overhaul.
As someone who very occasionally gets into the nuts & bolts of WP, I know I’d find it handy to have a link show up with the error (slug already in use) that would take me to where the preexisting slug is, so I can decide whether to change the preexisting one, or select something different.
Frex: my trash is empty, but I get the error when trying to create a new tag, & can’t find where the original slug is.
Or maybe there’s a way I don’t yet know…?
