[wp-trac] [WordPress Trac] #21112: Add pre_wp_unique_post_slug to override post slug handling
WordPress Trac
noreply at wordpress.org
Mon Nov 17 20:31:30 UTC 2014
#21112: Add pre_wp_unique_post_slug to override post slug handling
-------------------------+------------------------------
Reporter: coffee2code | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Permalinks | Version: 3.4
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
-------------------------+------------------------------
Changes (by coffee2code):
* keywords: has-patch reporter-feedback => has-patch
Comment:
Well, likely most uses for the existing `wp_unique_post_slug` filter would
be better served using the proposed `pre_wp_unique_post_slug` filter for
the simple reason that if you are mucking around with unique slug
detection (and regeneration due to a conflict), you're abandoning the
built-in work being performed by `wp_unique_post_slug()`.
Being early-firing (`pre_wp_unique_post_slug`) versus late-firing
(`wp_unique_post_slug`) means you can skip the queries, filters firing,
and code execution that you '''''know''''' will always be disregarded.
Some examples (geared towards custom-crafting the slugs the site uses)
include:
* changing of certain terms when appearing in slugs:[[br]]e.g. "wp-is-fun"
=> "wordpress-is-fun", "wp-cant-be-shuttered" => "wp-cannot-be-shuttered"
* removal of certain terms/phrases from appearing in slugs:[[br]]e.g.
"the-one-where-i-go-camping" => "where-i-go-camping"
* force prepending of word(s) to all, or contextually to some,
slugs:[[br]]e.g. "wp-is-fun" => "mysite-wp-is-fun"
* custom slug truncation length[[br]](Core has a 200 char limit, and while
the internally used `_truncate_post_slug()` supports customizing that
length via an argument, it is not otherwise filterable or customizable)
* custom duplicate slug suffix[[br]](core attempts "-N" where N is a
number tried until a unique slug is found)[[br]]e.g. "the-weekly-
report-15" => "the-weekly-report-fifteen"
* custom slug rules per post type
In the end, yes, all this can be achieved with the existing
`wp_unique_post_slug` filter, but it's a waste to run the 1(+n) queries
and code execution in situations where custom handling will negate it all.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/21112#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list