Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#37935 closed feature request (wontfix)

Add post ID among post's post type posts

Reported by: mifr45's profile mifr45 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: Posts, Post Types Keywords: reporter-feedback
Focuses: Cc:


Add to database a field containing post ID among post's post type posts.
It can be useful for users when they're using custom post types.

Change History (5)

#1 @dd32
7 years ago

  • Keywords reporter-feedback added

Hi @mifr45 and welcome back to Trac,

If I'm understanding correctly, you're proposing adding an additional incremental ID per post type?
For example, post_id = 5 might be custom_post_type_id = 1 if it's the first of that post type?

I personally don't see a valid reason for needing that, and can think of many reasons why using such a field would be a bad idea in practice.

Can you perhaps explain more of what you'd hope to achieve here to aid in determining if it's something we should add to Core?

#2 follow-up: @mifr45
7 years ago

@dd32, yes, you're understanding me correctly and I see why you don't think that adding this field is a good idea. But I think this functionality can help site's readers and users: they don't have to remember post's slug or post's ID to access post's url. With this feature, permalinks will be like this: ('ticket' is a rewrite slug of a custom post type)

instead of this:

or this:

#3 in reply to: ↑ 2 @SergeyBiryukov
7 years ago

Replying to mifr45:

But I think this functionality can help site's readers and users: they don't have to remember post's slug or post's ID to access post's url.

How is 25 different from 555 in that context?

#4 @mifr45
7 years ago

@SergeyBiryukov да, я привел плохой пример, извиняюсь. Но если, например, на WordPress сделан образовательный сайт, где ученики решают задачи, отправляя ответы на сервер. Ответ сохраняется как пост с типом "Ответ" и ID, например 555. Но это ID среди всех постов, а для того чтобы вывести ID, например, в заголовке этого типа ("Ответ №25") например, проще использовать именно ID среди ответов. Или в заголовке задачи (все тот же образовательный сайт) вывести "Задача №100" вместо "Задача про трех кроликов, поедающих морковку". Так пользователям будет проще ориентироваться.
Или другой пример. Сайт какой-нибудь компании (например, по продаже книг). Там есть заказы, которые также могут иметь этот ID среди заказов, чтобы отдавать его, например, на печать квитанции клиенту, и не возникало затруднений, например, на складе.(Будут искать заказ с айди 45, а у записи с айди 45 тип - страница, например).

Google Translate Translation: Yes, I gave a bad example, I'm sorry. But if, for example, made WordPress educational site where students solve problems by sending answers to the server. A position is stored as a type "A" and the ID, such as ID 555. But among all stations, and to derive ID, for example, the title of this type ( "A №25") for example, it is easy to use among the responses ID . Or the title of (all the same educational website) print "The problem №100" instead of "The problem about the three rabbits eating a carrot." So users will be easier to navigate.
Or another example. The site of some companies (for example, the sale of books). There are orders, which also may have the ID among the orders, to give it, for example, to print a receipt to the customer, and it is difficult, for example, in a warehouse (Will search order with Haydee 45, while recording with Haydee 45 type. - page, for example).

Last edited 7 years ago by dd32 (previous) (diff)

#5 @dd32
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I can't see this as something we want to add. ID's are almost impossible to keep consecutive with how WordPress generates posts. We specifically downplay using IDs within WordPress, so to add an extra one designed to be used like this isn't something we're likely to support.

If you wanted to implement this for a site, it shouldn't be too difficult to achieve, simply hook into the post publishing routine and add it as a post meta item (or slug perhaps, but numeric slugs are fraught with danger) and setup a query based off of that.

Note: See TracTickets for help on using tickets.