You can change the autoincrement value for a field in phpMyAdmin. If you’re modifying the ID you will be using something like phpMyAdmin. I think there is a top menu item “Operations” then on the next page find the “table options” section and find the auto-increment value and just change it to whatever you want your next one to be.
For changing the existing topic_ids, I think there is also a reference to topic_id in the _posts table (if not, how would bbPress know what topic a post belonged to?) I think it also might be referenced for tags too. I didn’t check, but I think tags are attached to topics, so the tag would have to reference the topic id somehow as well.
This is all just thinking out loud. You should probably back up the database first then make your changes and see what does not work. Might want to recount afterward.
Should be safe to do. I can’t think why it would be a problem.
Thanks guys.
The reason I’m doing this: I updated to v1.x and it was too soon. A lot of ck’s plugins aren’t working and was causing a lot of trouble. I started a new forum with 0.9.0.6 and all I imported from the old forum was the users data. Now I would like to have all the new topic numbers start where the old forum left off. My goal is to eventually import the topics from the old forum into the new database next year, when ck is supporting 1.x and most other plugins will play nice with 1.x.
Sound reasonable?
It all sounds good, but just out of curiosity – are you using pretty permalinks? Trying to figure out where the topic IDs might be visible to users… 
Note that many plugins use their own tables to keep track of information based on topic_id and post_id because of the poor performance of bbpress meta (non-unique index and large string storage).
Currently there is nothing in the bbPress API that allows a plugin to hook to be notified when there is a topic_id or post_id change to an object. So all plugins in existence (and bbpress itself) assume this will never happen. The only thing bbPress accounts for is a forum_id change on a topic/post and I am not even certain there’s an API hook for that.
This means if you manually change a topic or post id, and you have plugins which store meta for those items, you’ve just broken your data in a way that cannot be rebuilt later. All the recounts in the world won’t fix the problem.
So keep that in mind. Things like attachments, polls, etc. are all affected by what you are talking about if those topics have such meta.
(this is also specifically why I tell people not to use the Move It plugin)
Thanks for the explanation, ck. It’s a shame that a forum can be screwed up by certain plugins. Today was the first time I had heard that you were not recommending the Move It plugin anymore (I happened to see your post in the My Views topic). I wish there was a better way for users to know about insecure/broken plugins. At this point, we pretty much have to check all the topics on a regular basis.
Is there an easy way for a coding novice to see if a plugin keeps track of topic_id?
From one coding novice to another, I can try to answer that question.
Plugins that need to keep track of topic_id include topics that tend to “attach” something to a topic, or track data tied to a particular topic. _ck_’s examples above mentioned file attachments and polls… I’m guessing that at some of the following might work similarly:
* Best Answer (since a post within a particular topic is selected as the Best Answer)
* Unread Topics (which tracks if a topic has been read by a particularuser)
* bb Topic Views -(which tracks views for each topic)
Just a guess though…
