Post/Page ID Count skips one number when a new page or post created in WordPress 2.8.2

[misty9]

The post or page ID count skips one number whenever a new page or post is created.

This behavior doesn't occur in WP 2.2.2 where post AND page IDs are sequential. In short, one can easily identify the total number of pages and posts for a given website by looking at the ID numbers.

I've notices that after creating a page with ID 25, the next post I had created was given an ID 27, this pattern repeats itself whenever more pages and post are created. In other words, one number is kind of wasted.

Here are my question:

1. Isn't there a better way in SQL to wisely handle the skipped post ID's?

2. Why doesn't this cumbersome issue found in WP 2.2.2?

---

SELECT id, post_title, post_status, post_parent
FROM wp_posts;

ID Post_title Post_status Post_parent

25 Aug 19 test page publish 0
26 Aug 19 test page inherit 25
27 post test publish 0
28 post test inherit 27
29 test2 publish 0
30 test2 inherit 29
31 post Aug 19, 2009 publish 0
32 post Aug 19, 2009 inherit 31

---

I have both WP 2.2.2 and 2.8.2 databases ready for your research if needed.

[diegocaro]

This behaviour is normal in WordPress 2.8, because the latests version have a new feature called Post Revision. You can disable this feature with ​http://wordpress.org/extend/plugins/revision-control/ .

[ryan]

Post IDs are used internally for a number of things. They are not guaranteed to be consecutive.

[misty9]

Neither of you have addressed the issue in the bug.

1. I use the post/page IDs to easily track which page I am updating. Disabling Post Revision is NOT applicable here.

2. "Post IDs are used internally for a number of things. They are not guaranteed to be consecutive."

Because "Post IDs are used internally for a number of things", it does NOT mean an efficient SQL programming practice is not necessary for this basic WP functionality to work correctly.

If SQL code works correctly, the post/past IDs indicate the actual total number of posts/pages in a given site. Currently, the post IDs are twice as many as the total number of the posts or pages.

This is a bug whether the Post IDs are used for internally or otherwise.

[strider72]

Neither of you have addressed the issue in the bug.

1. I use the post/page IDs to easily track which page I am updating. Disabling Post Revision is NOT applicable here.

You are using the IDs for something they aren't meant for. That isn't a bug, even if it inconveniences you.

Beyond that, disabling post revisions *does* apply, because it restores the behavior you want -- one post/page == one ID number. The reason the ID numbers are jumping on you is that each revision gets a new ID number.

I agree with you to an extent -- I'm not a fan of how the revision system affects IDs. But disabling revisions does fix that.

2. "Post IDs are used internally for a number of things. They are not guaranteed to be consecutive."

Because "Post IDs are used internally for a number of things", it does NOT mean an efficient SQL programming practice is not necessary for this basic WP functionality to work correctly.

How is it inefficient? Your main complaint in the bug report is simply that the ID number does not show an accurate tally of how many active posts there are. This is true, but again it isn't meant for that. Putting revisions in the same table as actual posts is fairly efficient to my mind, considering the alternative would be to have a duplicate table for holding revisions separate from posts.

If SQL code works correctly, the post/past IDs indicate the actual total number of posts/pages in a given site. Currently, the post IDs are twice as many as the total number of the posts or pages. This is a bug whether the Post IDs are used for internally or otherwise.

A false assertion. You are claiming, as a matter of definition, that ID == post. This is not how the system works. It's note a bug, merely a difference in methodology.

[misty9]

Hi Strider72,

Thanks for your detailed explanations.

I use the post/page IDs to easily track which page I am updating. Disabling Post Revision is NOT applicable here.
You are using the IDs for something they aren't meant for. That isn't a bug, even if it inconveniences you.

Beyond that, disabling post revisions *does* apply, because it restores the behavior you want -- one post/page == one ID number. The reason the ID numbers are jumping on you is that each revision gets a new ID number.

I agree with you to an extent -- I'm not a fan of how the revision system affects IDs. But disabling revisions does fix that.

As you guys suggested, I've installed the Revision Control plug in in WP 2.8.2 and it is Deactivated, the post and page numbers continue to skip ONE number whenever there is a new post or page is created. Please note that I have enabled the "Reveal IDs for WP Admin" plug in, which I need. Any idea what I am missing? Thanks.

[ryan]

Autosaves will also use up an ID, as will attachments. This is all by design. There is nothing to fix here. Sorry.

[misty9]

Already know that is by design by now.

Repeat my previous inquiry, which is to find out why disabling the Revision Control doesn't seem to do what is supposed to do. i.e. It should not skip an ID number once when the Revision Control plugin is deactivated.

As you guys suggested, I've installed the Revision Control plug in in WP 2.8.2 and it is Deactivated, the post and page numbers continue to skip ONE number whenever there is a new post or page is created. Please note that I have enabled the "Reveal IDs for WP Admin" plug in, which I need.

Can you please get Strider72 to help me figuring this out? Thanks.

[ryan]

Autosaves will always use up an extra ID. You might be able to turn off autosaves by defining AUTOSAVE_INTERVAL to 0. Regardless, there is no bug here so this ticket should remain closed.

[dd32]

Repeat my previous inquiry, which is to find out why disabling the Revision Control doesn't seem to do what is supposed to do. i.e. It should not skip an ID number once when the Revision Control plugin is deactivated.

Probably because you're expecting it to do something its not designed for.

I never intended the revision control plugin to prevent autosaves, Only to prevent buildup of revisions for those who are anal about it.

[misty9]

In fact that "diegocaro and Strider72 had claimed that Revision Control plug in would be a workaround for what I need, however it's in fact misleading.

Changed 7 days ago by diegocaro

"This behaviour is normal in WordPress 2.8, because the latests version have a new feature called Post Revision. You can disable this feature with ​http://wordpress.org/extend/plugins/revision-control/ ."

Changed 5 days ago by strider72

"Beyond that, disabling post revisions *does* apply, because it restores the behavior you want -- one post/page == one ID number. The reason the ID numbers are jumping on you is that each revision gets a new ID number."

I can understand that the simple feature request here is beyond the scope of WordPress. However, it would be useful to have programmers or testers who can accurately providing information on what WordPress can and can't do regarding the subject.

Reopened for you to read!

[ryan]

What you want to do is not supported and never will be.

[dd32]

However, it would be useful to have programmers or testers who can accurately providing information on what WordPress can and can't do regarding the subject.

Not every contributer knows about every tiny fact about every plugin. I only know it because I wrote it, I know Viper's quicktags plugin is useful for embeds, I dont know for example if it support some obscure function you want..

[misty9]

After being on WP 2.2.2 for five months, I am reopening this bug because it is really a code bug in your SQL statements rather than what dd32 claimed as "obscure function" that I want.

Your SQL statement(s) have resulted page or post IDs generated randomly instead of sequentially (which was working in WP 2.2.2). Further, customer can't easily get the total count of pages without going to the database issuing a SQL statement.

[Denis-de-Bernardy]

​http://core.trac.wordpress.org/ticket/10655#comment:12

[nacin]

Here are just some of the various things that might be a row in the "posts" table:

• posts and pages, including those in drafts and trash.
• revisions of posts and pages.
• autosaves of posts and pages.
• attachments (uploads) that are attached to posts, pages, or are orphaned.

I've probably missed a few, and I'm ignoring custom post types as well. One row in the "posts" table is not equal to one "post", period.

Finally, the main point of this comment: If you need to display the number of posts, then use the API. Specifically, I'd start with ​http://codex.wordpress.org/Function_Reference/wp_count_posts, which has existed since 2.5.

[misty9]

Denis, Comment 12 did not and does not address this bug.

Nacin, Thanks for your technical responses and bug fixing detail.
~

The key issue here is your SQL code is incorrect, yet you are not willing to even admit it let alone to fix it. It worked in WP 2.2.2 and it should work in any later versions.

[miqrogroove]

Please do not reopen this ticket. You are welcome to add comments in closed status.

[nacin]

misty9,

Comment 12 came from the lead developer of WordPress, so I'm going to go out on a limb here and say that carries a little weight.

Developers have been trying to explain the "bug" is not a bug. Now I'm noticing that you also apparently hinted more specifically at some kind of an issue with WP skipping IDs, so let me suggest what is going on. (No fewer than five developers, including me, have read that as a general misunderstanding of how the "posts" table is used, based on the overall "bug" report.)

WordPress uses IDs as they are assigned, incrementally by the database. If an ID no longer exists in your table, then a row with that ID was at one point present, then discarded of, such as a deleted post or a discarded autosave.

[misty9]

miqrogroove, if the bug status is closed, I wonder how and why a programmer would bother read its updates?

nacin,

"WordPress uses IDs as they are assigned, incrementally by the database. If an ID no longer exists in your table, then a row with that ID was at one point present, then discarded of, such as a deleted post or a discarded autosave."

This statement does not apply to my case. There are neither pages nor posts being deleted. The page/post IDs seem to be generated randomly (unlike in WP 2.2.2). I know how SQL statements work. Can you please show me your code that handles this? Thanks.

[misty9]

In addition, would you mind explaining why the code works in WP 2.2.2 and it stopped working in versions that are greater than WP 2.2.2?

[dd32]

Replies to tickets here end up in our inboxes regardless of the status of it, We're not a callcenter.

Autosaves were introduced in 2.1. So unless they were disabled in 2.2.2 for you, possibly due to a missing or old 2.0 file, then it *should've* happened to you then too.

The answer to this ticket is simple however, post ID's will NEVER be sequential, and they never have been (Ok, not in the last 4 years at least). Posts, Pages, Attachments have always been taking up the next number. In todays world, Posts, Pages, Attachments, Revisions, Autosaves, Custom Post types(Including what people use on the front end, and Plugin storage data), amongst other things WILL use the next available number. That is not going to change.

If there has been a change in the code, Thats expected of a later version.

If you really want to see the queries related to the post ID's, Enable SQL logging of queries, or hack wp-db.php up to email you every time a INSERT/UPDATE/DELETE query is created against the database.

Please leave this ticket closed.