Trashed items interfere with page/post slug generation

[Denis-de-Bernardy]

Create a static page called test. Trash it. Create a new static page called test. It'll want to use the slug "test-2" instead of the expected "test".

This is extremely confusing for non-technically oriented users.

Seems like the right behavior to me.

What if the new post would now get "test" and the user untrashs the other page. Then that will get "test-2" and thus would have a different permalink as before (which will be even more confusing).

If the user wants to retain the "test" slug, he should simply not trash the old page, but overwrite/edit its contents.
By doing that, there will never be a "test-2" slug.
And if he later decides that he wants the old content back, it's still in a revision.

Replying to TobiasBg:

Seems like the right behavior to me.

I'd have thought so too, until I heard my father cursing about how WP was full of bugs.

What if the new post would now get "test" and the user untrashs the other page. Then that will get "test-2" and thus would have a different permalink as before (which will be even more confusing).

But if you trashed it, the odds are slim that you'll change your mind after recreating the very same page. (His particular issue was, WP created two pages in one go for a reason I've yet to identify.)

Replying to Denis-de-Bernardy:

I'd have thought so too, until I heard my father cursing about how WP was full of bugs.

I don't think we should free up the slug when an item is trashed, but the current behavior isn't good for UX, as you can attest to. Perhaps when we check a permalink slug, if there is a collision with a trashed item, we should in some way present that to the user and offer a solution?

Replying to TobiasBg:

What if the new post would now get "test" and the user untrashs the other page. Then that will get "test-2" and thus would have a different permalink as before

Makes perfect sense to me.

Imagine if Windows refused to create a file called test.txt because there was already a file with that same name in the Recycle Bin. How pissed would you be?

+1 to Denis.

Denis, let's explicitly add to this ticket that the trash should allow multiple trashed posts that have the same slug.

Replying to miqrogroove:

Imagine if Windows refused to create a file called test.txt because there was already a file with that same name in the Recycle Bin. How pissed would you be?

Ok, that's a good example :-) (Although I don't use the Windows Recycle Bin :-) )

But I don't know, if we can compare filenames with permalinks as those generally have a larger impact on others (i.e. search results, dead links, ...)
If I rename a file on my hard drive, nobody will notice or be bothered...

And as we have a manual way to change slugs, I believe that should be enough. I don't know if too many people would ever be noticing this behavior.

I think it would be even more confusing if you then went and un-trashed the first post and it ended up as test-2 then its permalink would have changed and that isn't meant to happen.

I wonder if the correct solution to this is to provide better feedback and make it more Poka-yoke so we would provide feedback as to why the best possible permalink wasn't being used (in all cases).

Something small and visual next to the displayed permalink whenever it triggers the duplicate check we a message about the thing that triggered it in a pop-out or somesuch.

I think just a message telling the user the permalink is attached to something in the trash is the best approach. Let the user decide what to do at that point. If they really want the permalink they will know to permanently delete the item from trash.

The simplest concept for users to understand would be that once a post is trashed, it is trashed and doesn't affect what they do from there on. And there is a restore from trash option. This matches the commonly understood 'Trash' concept on the Windows and Mac desktop.

If this concept is applied to WP posts and trashed posts, there is no need to check the trash permalinks before creating the new permalink - once posts are trashed, they don't have any influence anymore.

In the much less common situation where a user wants to restore a post from the trash, then WP could check if there is a permalink conflict with active psots. If there is a conflict, only then as per Nacin's suggestion, "we should in some way present that to the user and offer a solution" e.g "The permalink page-2 used by this page is already in use, please correct before restoring". Then the the user could adjust the permalink to allow the restoration of the page.

This way the Trash concept in WP will match the Trash concept elsewhere, and users only need to find out about permalink conflicts if they want to restore a page that conflicts, rather than in the far more common situation where they might be working on a draft, trash it and start again.

completely agree with glenn-om4.

Added patch that ignores existing permalinks if they are at a trash status. When restoring a post from trash the permalink is updated if a duplicate exists.

This doesn't improve things in a user-friendly way at all.

Now when I rescue a post from the trash I am going to get no warning that the slug change has occurred - this breaks the perma part of permalink.

I would much prefer to see an implementation which provides the feedback to the user when they un-trash a post to show that they is a clash and giving them a way of resolving the clash.

I should have noted I'm working on a message patch now to alert the user when this happens. Will post it when completed

Does it make sense to put some type of flag in the wp_unique_post_slug() function to determine if a permalink was changed because of a conflict? Or should this check exist in wp_untrash_post() function after wp_insert_post is called?

I'm just not sure the best place to put the check to trigger a message that there was a permalink conflict.

I think it makes more sense to put the check in wp_untrash_post().

I was thinking the same. I made some mods to that function you can see here:
​http://pastewp.org/5900

Problem is add_query_arg doesn't work in this case. Trying to figure out how to set the proper message ID in the query string.

Patch now includes a warning message to the user that there was a permalink conflict and the untrashed post's permalink was updated. Still not sure if this is the best way to trigger the error message, but wanted to give it a shot!

Updated the patch to display the updated post's permalink so there is no confusion on what was changed.

Translation functions can only accept a straight string, you'll need to use printf() w/ %s in the translated string.

Patch working as expected.

use sprintf() for translating string

In conflict.4.patch: use sprintf() for translating string.

Looks good.

While we now have a patch which looks good I am nervous of changing this without get some UX feedback on the change.

I'm still in the camp which would prefer the restored post to have the permalink and the new post to get the warning as to why it gets the less pretty one.

If a post is sent to the trash and then restored it should win in the permalink war.

To that end I would rather not change this this close to the release of 3.0 without wider discussion.

Better keyword name (props nacin)

Replying to miqrogroove:

Imagine if Windows refused to create a file called test.txt because there was already a file with that same name in the Recycle Bin. How pissed would you be?

Or worse, what if any computer wouldn't allow you to create a test.txt in one directory because there's already a test.txt in another directory?

Oh wait, that's the way WordPress currently works with slugs across path branches and across content types. But I digress... Related: #12935

Replying to glenn-om4:

The simplest concept for users to understand would be that once a post is trashed, it is trashed and doesn't affect what they do from there on. And there is a restore from trash option. This matches the commonly understood 'Trash' concept on the Windows and Mac desktop.

+1

During this weeks dev chat the general consensus was that as permalinks are meant to be permanent trashed items should win in the slug battle until fully purged from the db.

We think that is would be good to improve the ux with a suitable message as to why about-1234 was being used and to make it easy to empty the post from the trash to get the prettier permalink.

Just added my first stab at the reworked patch. Notice is now displayed on the post edit screen when the temp permalink is generated with a link to the trash.

(In [14446]) add warning on slug conflict with trash, props williamsba1, see #11863

I've just tried out [14446], and I think it still needs more work.

If you do the following:

1. Create a post with a permalink of test. Publish it.

2. Create another post with a title of test. Let the autosave trigger so that the permalink will try and default to "test".

Result: The permalink is set to "test-2" (as expected), but the display/layout of the warning doesn't look right (see screenshot.png).

4. Edit the permalink, and change it to a slug that doesn't exist. Click OK.

Result: The permalink change is accepted, but the conflict warning message is still displayed. I think it needs to disappear if the permalink is manually changed.

5. Click Save Draft.

Result: Post is saved, and conflicting warning message is removed (as expected).

6. Edit the permalink again, and change it to the original "test" slug.

Result: The permalink is changed to test-2 (as expected), but the conflict warning message isn't displayed. I think the message should be displayed here as well.

I used Firefox 3.6 on Mac.

This string needs to have the variable bit put in by sprintf otherwise it is impossible to translate.

After playing a while to get this to work better based on the feedback above I am going to back this patch out for now.

We need to cope correctly with different post_types and be congnicent of the rules regarding hierarchical / non hierarchical post types.

I guess we are going to need to leverage the code in wp_unique_post_slug more.

Maybe we need to extend it to let us know when it detects a collision.

(In [14462]) Remove the trash warning on permalinks for now as the current implementation doesn't work very well. See #11863

UX: Agree that the original permalink should win, this absolutely makes the most sense. The expected result when you click something that says "restore" is that it is indeed restored to exactly how it was before.

The expected result when you click something that says "restore" is that it is indeed restored to exactly how it was before.

... the exact opposite of what Windows does. This wont confuse anyone, guaranteed.

Replying to miqrogroove:

The expected result when you click something that says "restore" is that it is indeed restored to exactly how it was before.

... the exact opposite of what Windows does. This wont confuse anyone, guaranteed.

I'm having trouble figuring out whether your sarcasm is meant to be humour, or whether you're just being unhelpful? We can't have a discussion about the issue if you don't explain your views, I wasn't trying to step on anyone's toes :)

I read back over your earlier comments to try and figure out your standpoint, and I actually agree with you that restricting a new slug based on something that's in the trash (or recycle bin) is totally counter intuitive and a less-than-ideal user experience.
Now I'm no developer, so maybe from a technical point of view this isn't feasible - but I would say that once something is in the trash then the slug frees up, but if when restoring a trashed post a duplicate is detected, then the original post takes priority and the newer post gets changed to the "-2" with an appropriate warning dialog.

There is no definite right or wrong here, and it may well get changed based on real user feedback later on.

My apologies if I was unclear or offended you in any way miqrogroove

I think it's the "newer post gets changed" bit that will confuse everyone. In Windows you have to make that change manually or it wont let you restore the item. The only option it provides is to delete the "newer" item. In WordPress lingo, that means trashing the "newer post" while restoring the old one. Then there is no conflict.

How will it confuse everyone?

Warning: If you restore this post then post-xx will be moved to post-xx-2. Do you want to continue? [Yes/No]

The most relevant piece of information that we have is that the user wants to restore a post, everything else should revolve around the expectation of what will happen when a button labelled "restore" is clicked.

For the record: Windows really isn't a great benchmark when it comes to user experience - and just because it's most common, doesn't mean it's best. Take Internet Explorer for example.

Replying to miqrogroove:

I think it's the "newer post gets changed" bit that will confuse everyone. In Windows you have to make that change manually or it wont let you restore the item. The only option it provides is to delete the "newer" item. In WordPress lingo, that means trashing the "newer post" while restoring the old one. Then there is no conflict.

+1. This is the most straightforward UX. What's in trash has been trashed. What's not trashed is live and working on the website. If trash is being restored it makes sense that trash should have to adjust, not what has been live and minding it's own business.

Replying to johnonolan:

The most relevant piece of information that we have is that the user wants to restore a post, everything else should revolve around the expectation of what will happen when a button labelled "restore" is clicked.

Agreed.

For the record: Windows really isn't a great benchmark when it comes to user experience - and just because it's most common, doesn't mean it's best. Take Internet Explorer for example.

I'll say that while I know Windows has had a tremendous amount of professional UX people do usability studies on Windows, probably more than on any other software ever, whether it's the "best" or not isn't what's important. Take "Jacob's Law"[1]; what's important is what the most people are used to and expect, even if it were not the "best."

If "best" were most important then your laptop wouldn't have a qwerty keyboard.

[1] ​http://socialcomputingjournal.com/viewlisting.cfm?id=84

As I wrote above we discussed this at length in last weeks dev chat and the vonsensus based decision was that the permalink duplication has to be resolved by the user emptying the post from the trash.

While the post/page still exists in trashed form in the db it has the potential to be restored and must be restored with the same permalink it always had.

permalink duplication has to be resolved by the user emptying the post from the trash.

/facepalm

Replying to westi:

As I wrote above we discussed this at length in last weeks dev chat and the vonsensus based decision was that the permalink duplication has to be resolved by the user emptying the post from the trash.

While the post/page still exists in trashed form in the db it has the potential to be restored and must be restored with the same permalink it always had.

Sorry, but that's just wrong :) Trashed items should always have less significance than those that are published (or going to be published).

WordPress should warn the user if they decide to recover something from the trash that has a conflicting slug, not if they want to publish something new.

Agreed. Trashed items should get ignored altogether, if only for consistency with the filesystem trash.

Best I'm aware, if you create a test.txt file in a folder, trash it, and recreate a file with the exact same name, neither of Windows nor MacOS will bark. The WP trash should behave in the same way for posts and pages with the same slug.

I'm sorry but we had a long discussion on this and the Permalink of an existing post has to win all the time it is in the trash and has the potential to be restored.

Yes this is different from your OS Trash folder.

Intentionally so because of the significance of the Permalink!

This ticket should have been closed right after the meeting (6 months ago).

Replying to scribu:

This ticket should have been closed right after the meeting (6 months ago).

Well it would still be nice to have better UX here, even if we aren't going to give the new post permalink priority

Sorry to pile on, but both @aesque and @Denis-de-Bernardy are right and the previous decision is just wrong.

For example I have a client who I am building a product for which is a layer on top of WordPress (vs. just a website) and they are fanatically focused on user-experience and usability, even more so than Matt with his mom (if you can believe that.) This is one of the things that is causing them consternation with WordPress because the user is left with a frustrating situation that they can't get the slugs the way they want and there's no indication of why or how to change. And even if it did tell them how to fix it would be too many steps to follow for a less advanced user.

But, as you said, it have been decided and prior decisions are immutable.

I agree with westi.

We revisit decisions when we need to. We do not need to revisit this one and we will not. It was made as a user experience decision. A vocal minority on this ticket will not change that.

I'm also really sick of reading the same grandstanding and soapboxing coming from a few individuals on basically any ticket where their opinion is different.

If "about" is in trash, then /about/ redirects to /about-2/ - which as I understand it is the canonical component kicking in.

If this is fixed and the canoncial component doesn't kick in, then the old permalink of /about/ will simply 404.

If the former is true then the permalink preservation is meaningless because the user is served a new (wrong/unexpected) page. If the latter is true then the permalink preservation is meaningless because the user ends up with no page at all, and all search engine rankings + external links die.

Lose/Lose?

I'm not saying the previous decision is wrong (not getting involved) but, based on the above, I don't think the current system is right.

Replying to scribu:

This ticket should have been closed right after the meeting (6 months ago).

Agreeing with that. No change is needed if slugs are broken by design.

I'd like to ask that this issue be revisited. Granted, it's not a major issue, but it's a frustrating one for users when it happens.

As Westi pointed out, this was discussed at length by the core devs, however this discussion now took place two years ago. WordPress is in a much stronger position to test UX issues than it was two years ago and maybe in the intervening two years some core devs have noticed this issue and how counter-intuitive it is.

The reason I'd like to revisit the issue is this.

Scenario A: A user trashes a page with slug xyz, attempts to create a new page with slug xyz, ends up with xyz-2 and gets confused. "Damnit, I just deleted the page called xyz, why can't I create it again?"

The reason this happens is because we are reserving the trashed post's slug solely in case the post is subsequently restored from the trash. Due to the "perma"-ness of a permalink, it is considered that a restored post should not have its slug changed under any circumstance.

Reality check: How likely is the following scenario compared to Scenario A?

Scenario B: A user trashes a page with slug xyz, creates a new page with slug xyz, then subsequently un-trashes the original page with slug xyz (and expects it to still be available at its original permalink).

Yes of course it can happen, but in reality the frequency with which that happens is vastly smaller than Scenario A.

The current situation is addressing a situation where trashed posts should have preference over newly-created posts with the same slug just in case it's ever subsequently restored, rather than the far more common situation where a post is trashed and then someone attempts to create a new post with the same slug.

My opinion is that the current behaviour chooses to addresses an edge case rather than addressing a more common scenario, and this should be changed in order to improve UX. Trashed post slugs should not be taken into consideration when creating new posts. In the uncommon scenario where a user attempts to restore a post which shares the same slug as a subsequently created post, they should be notified. In addition, there could be a notice displayed below such posts when viewing the Trashed posts screen.

Replying to johnbillion:

In the uncommon scenario where a user attempts to restore a post which shares the same slug as a subsequently created post, they should be notified. In addition, there could be a notice displayed below such posts when viewing the Trashed posts screen.

You make some good and I think valid points. Why not just reverse the consideration order when it comes to restoring trashed posts, e.g:

• post(A) created, slug xyz, gets trashed
• post(B) created, slug of xyz (trashed items not considered)
• post(A) is later restored, but with a modified slug of xyz-2 (published items ARE considered)

Replying to DrewAPicture:

You make some good and I think valid points. Why not just reverse the consideration order when it comes to restoring trashed posts, e.g:

• post(A) created, slug xyz, gets trashed
• post(B) created, slug of xyz (trashed items not considered)
• post(A) is later restored, but with a modified slug of xyz-2 (published items ARE considered)

As per the previous discussion and this ​IRC dev chat (find: trash) which is referred to in this ticket, consensus was that trashed and restored posts should "win the permalink war."

Here's a crazy idea: why don't we ask some USERS instead of referring to a bunch of ancient conversations between developers?

I know, I know - MADNESS.

Replying to ericlewis:

As per the previous discussion and this ​IRC dev chat (find: trash) which is referred to in this ticket, consensus was that trashed and restored posts should "win the permalink war."

We have already established this. Please see my comment above about why, two years later, I think this small but frustrating issue should be revisited.

Replying to johnbillion:

Replying to ericlewis:

As per the previous discussion and this ​IRC dev chat (find: trash) which is referred to in this ticket, consensus was that trashed and restored posts should "win the permalink war."

We have already established this. Please see my comment above about why, two years later, I think this small but frustrating issue should be revisited.

Yeah, I agree with your sentiments about the likelihood of cases you described. I think a step in the right direction for this issue would be to issue some error text as has been attempted before.

The last patch williamsba1 attached does not apply cleanly to trunk, I'll attach an updated version. It would need some designer approval, as it removes the CSS 'height' declaration for #edit-slug-box to allow for error messages to increase the height of the div.

Updated version of conflict5.patch to apply cleanly to trunk. Added link to current post if the conflicting post is published, leave link to trash if that's where it is.

Provide a screenshot and I'd be happy to take a look

11863.patch screenshot

11863.patch screenshot 2

Note: 11863.patch will only show errors when user manually edits the permalink and a conflict is found. Displaying an error on publishing the post would be a bit more involved since the post_name is appended with '-n' on publish.

Replying to johnbillion:

Trashed post slugs should not be taken into consideration when creating new posts. In the uncommon scenario where a user attempts to restore a post which shares the same slug as a subsequently created post, they should be notified.

Seems that comment:10, comment:37 and comment:46 suggest the same. Makes the most sense to me.

Styling looks fine. Copy needs work.

Add error messages when posts are restored from trash; give live post permalink precedence

In 11863-1.patch, an error message for each permalink collision is output when restoring posts. Copy is just filler, we could give more specific directions to the user for dealing with the collision.

Related: #21970 - 404 error when a post has the same slug as with a deleted (trash) page.