Renumbering will be forced, not an option, and will start with 1.

Bada bing!

Time for me to swallow a big pill and get ready to upgrade all my external programs that rely on U_Number, heh. No big deal, if you guys are scripting it where it forces the change, I can do the same.

There will be a nice handy map in the database with all the old numbers. Photopost users will have a bigger problem to worry about than just user numbers changing, though - the database is very, very different, so the connector will need to be rewritten anyway.

Any chance for those cool menus (dhtml?) that Open Topic had?

I won't comment on the UI.

There will be DHTML involved, though never for critical functions.

flint unhappy.

I'm still waiting for UBBT 6.5.1 to fix bugs like the "random all read issue", I think it was cookie related, and the only perspective I have right now is a totally new software, which will render lots of extensions we wrote useless. sigh ...

Flint - do what I intend to do.

Back everything up TWICE - and install a 'dev' copy of the new software so you can tweak it to your needs.

I have various other programs implemented alongside my Threads database.

XML pulling in from various websites and sync'ing with U_Number

Photopost (which will be borked by this new system) which links by U_Number

A Member management system I developed that also syncs via U_Number

etc. etc...

So this new system will TOTALLY screw me. But knowing that, and knowing it is just a matter of rewriting the way everything maps, I will keep 6.5 running as my main, while using my 'dev' install to re-hack and re-sync everything using duplicate copies of my DB and files.

Flint, you can expect 6.5.1 shortly - it's in the final phases of internal beta testing. Work on 6.5.1 has actually contributed to delays on our internal goals for development on the new product, not the other way around, so please don't feel like we're ignoring the bugs or anything. Don't worry though, we're still on schedule overall...

Medar, out of personal curiosity, how does your member management system work? Do you let Threads be the master of the database, or does your system act as the master and synch against w3t_Users?