19 Comments


  1. I think it should be up to the theme / plugin author to make allowances for users of their code to be able to find the necessary information. Either add code into their theme or plugin, for example in the options page to identify posts or pages as the case may be; or, give easily understood instructions on how to find the information, i.e.: how to and where to hover over the post.


  2. Jeff, your use case sounds to me like a perfect candidate for a plugin (or, as JB said above, functionality that the author of a plugin that uses such information can add to that plugin itself).

    It definitely doesn’t need to be the default behavior to expose such information in the back-end.

    A screen option? Perhaps… again, sounds like something for which it ought to be easy enough to write a plugin (for those who know how to write plugins; I’m not one of them.) :)


  3. But there is a plugin for this case

    The argument against this idea is that a large majority of the WordPress userbase does not need to know this information.

    This isn’t IMHO really an argument – WP has a few other features (e.g. posting via mail) that are useful only for a minority… Not speaking about that simple solution to hide IDs defaultly and make it possible to turn them on in Screen options (or ev. in global settings).

    I agree this was one of the not-so-much-thoughtful touches on 2.5.


  4. It’s not that most people don’t need the post/page/category ID, or even that it can be found by hovering over the name. It’s that nobody will ever need it in a bare installation of WordPress.
    The only time anyone will ever need the ID number of a post/page/category is when a theme/plugin asks for it, or if you’re creating/editing a theme/plugin. Just because you go and get some StudioPress or iTheme theme that asks for a category ID or a page ID, that doesn’t mean that WordPress should have it in there.
    If you know enough to create a theme or plugin, you should know enough to be able to figure out the ID of what you need. If a plugin or theme needs it, it is the responsibility developer of the plugin or theme to supply this information.
    What if I write a plugin or theme that needs a post meta or user ID number, should WordPress supply those in an additional column as well?
    There are 9834589 different types of unique ID numbers for the various types of data in WordPress. NONE of it will ever be needed by a user unless they’re making or editing a plugin or theme, or the plugin or theme asks for it.
    .-= ´s last blog ..Twitter Updates for 2009-06-12 =-.


  5. I generally opt for simplicity and just check the URL to get the ID when I need it rather than adding yet another plugin ;)

    But there is at least one plugin that does this, Reveal IDs for WP Admin, that I have used when working with other designers who want an easier way to get these IDs.

    It seems like they added a lot of flexibility in the backend for the end user with 2.8, it seems like the option of IDs would be a reasonable option to add as well.


  6. The question is why do they need it?

    I don’t really think they do. It is very easy to write functions in plugins and themes that take named arguments, or provide an options screen that gives a named drop down, so I don’t think there is much of an excuse for simply expecting an integer, unless the functions are only for developers to use.


  7. Andrew,

    That’s just what I meant. You have it exactly right. Since a WP user will never need them unless a plugin or theme requires it, it’s the job of the developer to supply what they need via dropdown or whatever method. Several themes list categories, pages, etc in a dropdown for you to select instead of asking you to enter the id.
    .-= ´s last blog ..Twitter Updates for 2009-06-12 =-.


  8. I know many users that need this information, and it’s not because a plugin/theme asks for it. If I had one major gripe with WordPress, it is the removal of this info from the admin pages. While it doesn’t have to be a default, I don’t see why there shouldn’t just be screen option to display it.

    I get questions about how to find the ID (usually for categories, pages, and posts) often more than once a week. It’s a rarity that it’s because one of my plugins/themes need it.

    Several WordPress functions (template tags) ask for it. I suppose I could list them all here, but it’s easy enough to find these functions in the Codex.


  9. @Justin

    Sure, various functions require an ID, but this isn’t out of the box usage of WordPress. If someone has the skills to customize a template/theme using the WordPress API, then they should have the ability to locate the ID they need.


  10. Valid arguments presented for both sides of the issue, but I wonder why earlier versions of WordPress provided this information upfront and in later versions, this information was taken away. I’m going to find out.

    But I like Andrews stance and I’ve also seen this accomplished in themes. Where you check mark the actual names of things instead of providing UID as parameters.


  11. It seems this is becoming more a question of who needs the ID and for what purposes.

    I am in full agreement that developers should by all rights be able to find an ID relatively easily, but perhaps the average user or non-technically inclined blogger may need something a bit more obvious. Which IMHO still falls to the developer to provide a method if their theme or plugin needs the details for the end-user to make use of it.
    .-= ´s last blog ..Desk Mess Version 1.0.6 =-.


  12. Hovering over a link to find an ID does not seem particularly intuitive to me.

    The first thing I did when I installed WordPress was to start hacking up the default theme. I knew nothing of PHP, ‘template tags’ or any of that stuff. However I did quickly learn that I needed to know page ID’s to make use of wp_list_pages(). WordPress is designed with theming in mind, so not providing the necessary information for new users to do this easily seems a little silly to me. I started using ID’s back when they were readily available in the admin panel, but I assume it would have had me baffled for a few minutes if I’d started with 2.5+.


  13. The numerical identification of posts and pages is key information that should be displayed in a column next to the title, number of comments, and so on.

    As Justin points out, this information is essential for many WordPress template tags, as well as many plugins and themes. Removing it was a mistake, and leaving it out is just laziness.

    The argument that users who need this information should know how to get it is absurd. Perhaps WordPress should stop showing post dates, page titles, and the number of comments for each post, because, after all, anyone who needs that info should know how to get it.


  14. “The argument that users who need this information should know how to get it is absurd. Perhaps WordPress should stop showing post dates, page titles, and the number of comments for each post, because, after all, anyone who needs that info should know how to get it.”

    Post dates, page titles, number of comments, etc is all information that your average blogger will use regularly. Again, post,page,category ID numbers are never needed unless developing a theme/plugin or if a theme/plugin needs it and didn’t supply the title/name dynamically for you.

    This issue has been brought up over and over in trac for a very long time as well as recently, and has consistently been shot down by the core committers.

    Removing it was a mistake, and leaving it out is just laziness.
    It’s not laziness, as the patch for it has been submitted numerous times. All a core committer had to do was commit it.
    .-= ´s last blog ..Twitter Updates for 2009-06-12 =-.


  15. ID numbers are never needed unless developing a theme/plugin or if a theme/plugin needs it and didn’t supply the title/name dynamically for you.

    Exactly how do you know that IDs are never needed otherwise? There are millions of WordPress users out there using WordPress for just about everything imaginable. Did you take a poll? How many actual WP users have you spoken with about this? How accurate are your statistics? Seems unreasonable to presume to know when IDs are (or aren’t) needed, and then base your argument against ID-inclusion on that presumption.
    .-= ´s last blog ..Block Multiple IP Addresses with PHP =-.


  16. @Jeffro – You say: “I wonder why earlier versions of WordPress provided this information upfront and in later versions, this information was taken away.”

    I say, after testing the usability of the product, that the main devs have decided that “almost nobody,” as Michael Torbert said, needed the IDs. I develop my own themes and pass specific IDs to certain tags. It’s tedious and it takes a minute out of my time, but improving WordPress the product means it has to be improved to the user.

    For every theme and plugin dev out there, there are thousands upon thousands who would find this random sprinkling of numbers to be confusing. Maybe that’s why they took it out. This is the product, growing up and expanding from being a developer-intensive app to one that cares most for its most basic of users.

    That said, yes, this is the kind of thing for a plugin, in fact it would be nice if different plugin devs teamed up to produce a suite of “essential plugins” for devs and/or users. The better for-hire theme devs and admins drop in a package of essential plugins for their clients, why don’t we all come together and do the same for ourselves?
    .-= ´s last blog ..Site redesign: Richmond =-.


  17. Well, looks like I’ve lost this argument. I don’t think this is plugin territory at all. I’d agree that a plugin would need to be made if the ID information wasn’t available at all but since you can hover over the link, it defeats the purpose of a plugin but I still think both worlds are met if it’s merely just a screen option.


  18. @Jeffro – I wouldn’t call this a win or lose discussion. We are trying to divine how the devs came into this decision. If I had the PHP-fu (and watch out, I’m planning to) I’d write the plugin myself.

    But yeah dude I’m glad to have swung my here, I’m not the acrimonious/argumentative type.
    .-= ´s last blog ..Site redesign: Richmond =-.


  19. I think that the actual *need* for the ID’s needs to be removed. Any code that needs an ID but doesn’t have some other equivalent that can be used (like, say, slug) needs to be examined and perhaps a new function should be written to use that information instead.
    .-= ´s last blog ..Cameron’s house is up for sale =-.

Comments are closed.