WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#6315 closed enhancement (wontfix)

ID's missing from all admin screens

Reported by: Otto42 Owned by: westi
Milestone: 2.8 Priority: low
Severity: trivial Version: 2.5
Component: Administration Keywords: has-patch needs-testing
Focuses: Cc:

Description

In trunk, the Manage Posts/Pages/Categories/etc screens have all had their ID numbers removed. This information is necessary for users to know when editing their themes. How can somebody create a "category-X.php" file if they don't know what "X" is supposed to be? Same for post and page ID's, when used with various functions that require ID numbers.

These all need to be added back, large sections of theme editing are now much more difficult to do, sometimes requiring manually looking at the database because of this missing information. Users on the support forums are already starting to complain, and it's not even released yet (first time I've ever seen that).

http://wordpress.org/support/topic/162533

Attachments (1)

6315.patch (2.7 KB) - added by zeronex 5 years ago.
patch for tag/category/page/post

Download all attachments as: .zip

Change History (32)

comment:1 Otto426 years ago

  • Severity changed from blocker to major

comment:2 ryan6 years ago

ID could be worked into the title attribute for the edit links.

comment:4 westi6 years ago

  • Cc westi added

comment:5 ryan6 years ago

You can get the ID from the edit link URLs. We can do something friendlier, but this little used information need not be prominent.

comment:6 westi6 years ago

Cross posted from wp-testers ;-)

thinking about this some more maybe the correct approach is to encourage theme authors to not use template tag calls based on ID's but to write them using slugs instead.

We may need to improve all of the usual template tag calls that people call with ID's to accept slugs but this would lead to more portable themes.

I've lost count of the number of themes that have an about page link that by default links to # as the theme author didn't know which ID to use for the about page. If they could have put in a link to the page with the slug about then the theme would be just that little bit better!

comment:7 in reply to: ↑ description jsherk6 years ago

Would like to see the Post ID displayed as it was (or similar) to wp2.3, where it shows up on the Manage screen. Is use these all the time!

comment:8 jhodgdon6 years ago

+1 on getting the ID numbers back -- hovering to find them on the Manage screens is a pain.

Anyway, apparently someone has written a plugin to do this:

http://wordpress.org/extend/plugins/reveal-ids-for-wp-admin-25/

The plugin even has options to turn on/off display of the IDs, so while you are in plugin/theme dev mode you can turn it on, then turn it back off again for clean screens.

How about incorporating in core?

comment:9 ryan6 years ago

I think this is best as a plugin. Most people don't give a hoot about IDs. The people who need IDs are savvy enough to find them or install a plugin to expose them. Giving non-presentational data such as IDs prominent display in their own column is a waste of precious real estate.

comment:10 jhodgdon6 years ago

If you don't want to put this into Core, then in my opinion, someone needs to do a lot of Codex editing. There are a ton of functions and procedures that involve knowing the ID numbers for posts, pages, etc. Particularly for theme development. We'll need to link to this plugin, and hope the author continues to maintain it.

I'd prefer to be able to say something like "Go to the Advanced tab of the Settings pages, and check the Show IDs checkbox", rather than relying on this particular plugin to be available. I understand that most people don't need to see IDs, but I think there are enough reasons for needing IDs that it merits having the ability to turn them on in core, without searching for this plugin and relying on its continued existence. Hovering over links to try to find the ID number in the URL is REALLY ANNOYING.

comment:11 Otto426 years ago

While the plugin is extremely handy, this really, really needs to be a built in. If not displayed all the time (seriously? one thin extra column is cluttered to you), then it needs to be an option. It can be off by default, but it must be there.

Too much of the core code and theme functions require IDs of things as input. Users edit themes. This is a fact. And if they're going to be doing that, then they very often need this sort of information to do it. Pointing them to a plugin for functionality that they *require* is silly.

I have no problem with information hiding and simplifying the interface, but simplifying it to the point where they need third party software to make it give them what they need for normal usage is just plain stupid.

comment:12 gambit376 years ago

I concur with Otto42 and jhodgdon. The Codex discusses many of WPs hooks and parameters and often shows how to exclude things from actions using IDs (for example wp_list_pages). Why would you suddenly make the this functionality useless by obfuscating the essential piece of information required to make it work?

comment:13 thee176 years ago

What is we added a per user setting to enable this and apend them to the Title link?

comment:14 jhodgdon5 years ago

  • Milestone changed from 2.9 to 2.8

In 2.7, we now have the ability, under "Screen Options", of hiding/adding columns. Why not add ID as an optional column, to the Posts, Pages, Tags, Categories, and Link Categories edit/list screens? Or should I say, why wasn't it added? Too late now for 2.7, but maybe 2.8?

comment:15 navjotjsingh5 years ago

I support this too. Please consider adding IDs back.

comment:17 misty95 years ago

What is the reason for removing the page ID and post ID' from Site Admin (which exists in WP 2.2)?

Having Page ID and Post ID present in Site Admin is very useful for someone who manages a website. It saves a lot trouble from navigating in and out of viewing the actual pages in order to get the page or post ID's.

Would you please revert the changes? Thanks.

P.S. I have found multiple issues in WP 2.7 since I have upgraded to 2.7 only a couple of days ago. I want to go back to 2.2 which gave me no trouble.

comment:18 zeronex5 years ago

  • Cc zeronex added

Plugin for this already exists check

http://wordpress.org/extend/plugins/reveal-ids-for-wp-admin-25/

Can be added to core with ID set to invisible by default.

Thanks

zeronex5 years ago

patch for tag/category/page/post

comment:19 hakre5 years ago

IDs is a very central and important information. Is there argument for hiding it?

comment:20 follow-up: Viper007Bond5 years ago

  • Component changed from Template to Administration
  • Keywords has-patch needs-testing added

Since you can control what columns you want to see, no reason whatsoever not to have the ability to show the ID column. It should be off by default though.

zeronex looks okay, but could use some formatting cleanup.

comment:21 Viper007Bond5 years ago

*zeronex's patch looks okay

comment:22 westi5 years ago

  • Owner changed from anonymous to westi
  • Status changed from new to assigned

If this patch does what I think it does - i.e. make it a screen option which defaults to off then I am definetly +1

Just need to find time to review+commit ;-)

comment:23 in reply to: ↑ 20 ; follow-up: hakre5 years ago

Replying to Viper007Bond:

It should be off by default though.

Why should it be off by default?

comment:24 hakre5 years ago

Another Patch that adds a Screen Option, in case you need something to compare. I tested that one: #9443

comment:25 in reply to: ↑ 23 ; follow-up: Viper007Bond5 years ago

Replying to hakre:

Why should it be off by default?

Because the vast majority of users don't care what the ID of their post is (they're for internal usage only or for those who want to edit their theme). It takes up screen real estate (which is lacking on low resolution monitors) and will just confuse the novice user.

It takes literally 1-2 seconds to enable it.

The better question is: Why should it be on by default?

comment:26 ryan5 years ago

  • Priority changed from high to low
  • Severity changed from major to trivial
  • Type changed from defect (bug) to enhancement

There is currently no way to hide new columns by default if the user already has some columns hidden. When I apply this patch I see ID columns everywhere -- big columns that come before the checkbox.

Let's put it in the bits that output the ID but leave ID out of the column headers. A plugin can then easily add the columns.

comment:27 Denis-de-Bernardy5 years ago

  • Milestone 2.8 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

plugin material

comment:28 jhodgdon5 years ago

  • Milestone set to 2.8
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Don't just say this is plugin material, unless there are hooks plugins can use to add the IDs to the screens. Are there hooks now that would allow a plugin to add IDs to the post, page, tag, category, link, and link category screens?

If not, please leave this bug open until they are supplied.

If they are, please explain and *then* re-close the bug.

comment:29 jhodgdon5 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Never mind. I see the plugin above. I still think this is a stupid decision, since nearly every instruction for customizing your theme for particular categories, tags, posts, etc. involves finding the ID number for said category, tag, etc. Having no method (without a plugin) beyond hovering over some link to find the ID is lame.

comment:30 filosofo5 years ago

It would be nice to have those ID numbers back. Sometimes on a small laptop screen with too much status bar junk, I can't even see enough of the link to figure out the ID.

How about putting it in the title attribute so that you can see it when hovering?

Ex:
Edit "Category Name" (ID: 123)

comment:31 in reply to: ↑ 25 hakre5 years ago

Replying to Viper007Bond:

Replying to hakre:

Why should it be off by default?

[some arguments why]
The better question is: Why should it be on by default?

Well, depends on the point of view and I agree with your argumentation. Default should be off then.

Note: See TracTickets for help on using tickets.