[wp-trac] [WordPress Trac] #17134: Add support for the_slug() in template tags

[WordPress Trac]

#17134: Add support for the_slug() in template tags
-----------------------------+------------------------------
 Reporter:  tomauger         |       Owner:
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Template         |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |
-----------------------------+------------------------------
Changes (by iandunn):

 * cc: ian_dunn@… (added)


Comment:

 I've had a desire for get_the_slug() several times over the years. Just
 last week I wanted to use it to ID links that were being tracked in Google
 Analytics via gaq.push(), so that the report would easily show what page
 the click occurred on.

 I could have used get_the_ID() instead, but then I'd have to manually
 lookup the IDs and map them to the pages. I could use get_the_title(), but
 that's not guaranteed to be unique and it could have characters that I'd
 have to strip out. It'd be much easier and simpler to just use
 get_the_slug(). The slug is basically a human-friendly ID.

 Even if it was originally intended to be used when building URLs, I don't
 see why that should be considered the only valid use case. That places an
 artificial restriction on developers. There are millions of people using
 WP, and we can't possibly imagine all the different scenarios they might
 have.

 Unless a change would cause harm or encourage bad practices, why deny
 people something that they're asking for? If you do a Google search for
 "the_slug" you'll find plenty of people looking for it, and most are
 surprised that it isn't included in core. e.g.,
 [http://www.tcbarrett.com/2011/09/wordpress-the_slug-get-post-slug-
 function/ 1] and
 [http://www.wprecipes.com/wordpress-function-to-get-postpage-slug 2].

 I'm working on a patch for this, in case others think that it should be
 included in a future version. Many of the homegrown versions out there
 don't prefix their functions names, so one potential problem will be
 collisions. Here are a couple ideas for addressing that:

 1. Choose different names to avoid collisions. The downside here is that
 the new function names wouldn't be consistent with similar functions like
 the_title(), the_guid(), etc.
 2. Make the new functions pluggable, so they'd only be declared if others
 didn't already exist.
 3. Just let collisions happen. The error PHP spits out is fairly
 descriptive, so it shouldn't be too hard for people to realize what's
 going on.

 I'm leaning towards !#3, but would like to hear other opinions.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17134#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software