[wp-trac] [WordPress Trac] #11863: Trashed items interfere with page/post slug generation
WordPress Trac
noreply at wordpress.org
Thu Feb 18 19:55:54 UTC 2016
#11863: Trashed items interfere with page/post slug generation
-------------------------------------------------+-------------------------
Reporter: Denis-de-Bernardy | Owner: ericlewis
Type: enhancement | Status: assigned
Priority: normal | Milestone: 4.5
Component: Posts, Post Types | Version: 2.9
Severity: normal | Resolution:
Keywords: make-flow has-patch has-unit-tests | Focuses:
needs-testing |
-------------------------------------------------+-------------------------
Comment (by DrewAPicture):
Replying to [comment:107 ericlewis]:
> Thinking about this more, I wonder if we should consider a combined
approach of what we were calling
[https://core.trac.wordpress.org/ticket/11863#comment:91 option 1 and
option 3].
>
> When a post is trashed, change post_name to `{{slug}}-%trashed%`, and
'''also''' store the value in post meta. This lets us re-apply the
original slug on untrashing from the post meta value (avoiding
[https://core.trac.wordpress.org/ticket/11863#comment:94 the character
limit]) and also avoid changing the slug at
[https://core.trac.wordpress.org/ticket/11863#comment:106 odd times as
@boone mentioned].
Had you considered not using post meta at all and simply
prefixing/suffixing the slug when trashed? Seems like introducing post
meta into the mix might needlessly overcomplicate what we're trying to
accommodate here.
I'd think we could rely on core's ability to find a unique post name to
revert back to a valid post name on restore. The same would go for a
similarly-post-named post slug coming in ... prefix/suffix it and check
for a unique slug when trashing.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/11863#comment:108>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list