does it make any sense at all to post suggestions for the things to come? if yes, where to post them? can one assume that the major features will stay, or will we have to re-request things?
my first request: kill the three email fields and do it groupee-style: email address is the login name, display name can be chosen. change of email / login name requires 2nd verification. preference to display email or not, functionality to send email through the board, without reveiling the address.
experience showed that many users clear both admin and public address field, or enter bogus data, but still want to receive newsletters. above solution would be the least confusing.
Feature suggestions can go here or over on the Classic board. Do note, however, that the feature set for the initial release is pretty much set in stone, so please don't expect too many suggestions from here to make it in that first version. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />
There will be an option to log in using an email address. This is to allow for greater ability to integrate with Groupee, actually. How exactly this will impact the registration screen is yet to be determined. The Display Email field will still be present.
However, the login name / pdn / email / display email split will still be present by default.
Please guarantee that all the existing links will migrate into the new software. I moved form UBB.classic to ubb.threads and when the links didn't work anymore, it was a major PITA.
There will be a set of replacement scripts that will properly redirect people to the right posts, topics, and forums. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
[]There will be a set of replacement scripts that will properly redirect people to the right posts, topics, and forums. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" /> [/]
This is a major concern of mine and just to make sure we're talking about the same thing here is an example.
Correct - there will be a set of scripts that will replace your existing UBB.threads or UBB.classic installation that will read the old URL paramaters, look up the old data in the new database, then redirect the user to the new location of the requested page. These scripts will support spider-friendly mode.
HUGE favor to ask as a loyal Infopop customer and new Threads user who has moved up from Classic. As I was upgrading/moving and not starting from scratch, the member #'s in my new Threads forum start at #14193 (previous #2 account in Classic), and overall the member numbers are quite high and have large gaps in them as well. So although I have about 4000 active users, the last user # is over 50k.
When designing the import module for the upcominng software, could you please offer the option to renumerate all users (basically to reassign numbers on the fly with each imported member)?
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.
[]Renumbering will be forced, not an option, and will start with 1. [/]
That'll totally bork anyone using photopost.... as photopost stores images with the usernumber in the file name. <img src="https://www.ubbcentral.com/boards/images/graemlins/crazy.gif" alt="" />
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.
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 ...
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. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" /> 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?
1. I really like the old censor feature from Classic. Type in a word and it's get "starred out *****" regardless of whether someone adds any characters before or after it. Nice and simple, and does the job.
2. Forgotten passwords. Do the passwords have to change every time someone tries to retrieve them? What's the upside, security? The downside is that people sometimes type in other users' data just as a prank, so because of such jokers people end up having to access their email just to be able to log in again. Maybe allowing users to switch this off in the Member Profile would do the trick.
Conrad, the current censor should work exactly as you describe in your first point.
For your second point - the password emailed is a temporary password that is stored separately from the normal password. Sending a temporary password won't log a user out or anything.
[]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? [/]
Hi Charles, just saw this (I am a once or twice a week'er over here).
Our forums are the central communication hub for our entire website, so I have built everything around the w3t_Users and w3t_Groups tables. Basically I admin a gaming group that plays various online games under various names, and many need various accesses. I am a HUGE fan of using U_Number and U_Group in queries to integrate Private Messages on all of our web pages, control accesses to certain web pages, and control access to the entire admin area.
I have a number of extra tables in a separate MySQL database, the main being an "SSB_Members" table that has a Mem_ForumId record - you can guess what that is - it is the U_Number record from w3t_Users. Every access is built around what Mem_ForumId = U_Number and what U_Groups they belong in.
This allows me to control the following:
1. Different members control different "rosters" of members in games. 2. Certain members have control over all rosters and expanded functions 3. A few members have access to grant accesses (add people to groups external from UBB.Threads), which automatically gives them access to certain forums, and certain web adminsitration controls.
A quick example would be = http://www.bladekeep.com/admin/. That should look real familiar, heheh, and when logged in with proper access, it even feeds off the proper stylesheet by authenticating the U_StyleSheet.
Another example everyone that is a "member" can see http://www.bladekeep.com/teamspeak.php, as the members are part of group #8. If they are not logged in, or are not a part of that group, they get the not allowed message.
One last little cool thing I use is http://www.bladekeep.com/apply.php - this actually posts into a forum that the registered user cannot see, but it allows us to receive an application as a "new post" in a private forum, and we can discuss from there.
Why did I do all this silliness? I became tired of trying to get all the different game rosters (with members having multiple characters) correct, and it became too much for one or two people to handle. So by giving people access to Admin Roster and Application controls via UBB.Threads Group controls, it allows me to dynamically spit out various rosters and provide various controls to our members.
All the below feeds or is connected to the w3t_Users table via various other tables.
OKay, so all your integration is at the database level, not the code level? Or do you actually include the Threads libraries in the rest of your pages?
I have main.inc.php called on almost every web page, which is about the only thing I need to include for authentication. From there I can use any number of functions in the Threads libraries...good stuff. So you could say I do both.
One thing you helped me remember was that I always meant to code a bit of a referrer so that a use could log in to the "site" (ie Threads) from any page I have the login code, and then be returned to that page instead of My Home or Index.
Ah, okay... then I have some good news and some bad news for you. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />
Good news number one - the new login code can automagically redirect you back to where you came, as long as you're on the same domain name.
Good news number two - you can still just include main.inc.php to get the environment, as well as everything you need to authorize the user, etc.
Which is the bad news - the code is now much more intrusive, and will try to reconfigure some PHP settings on the fly, and do some other things that might not play well with your existing code. But that is sort of to be expected.
Not worried at all - looking forward to tinkering with the new code and functions to see what I can get it to do. A lot of my stuff is templated, so I should be able to reconfigure things fairly quickly.
But great to hear about the login code redirect and main.inc.php!
Would be nice if the CP would allow not only backing up the database but also restoring it. Seems like a small php file will do the job - I tried the first one mentioned in this thread and it worked perfectly. Would be great if something like this was already included in the CP, which currently only backs up the database but won't import it in case something goes wrong or if someone moves servers.
Well - though if you're restoring the database within threads - you wouldn't be able to be logged in, as the user's table would have to be dropped. So not sure how that would be possible. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />
Exactly. Doesn't work without extreme danger of really creating a disaster of your .threads board, which is why we removed it.
phpmyadmin and other backup programs can restore your threads database because they are not actually using the database while restoring it. Restoring the threads database from within threads means you are currently using the database that you are trying to restore. We could, perhaps, write a standalone to do it, but then we're moving away from the aim of UBB.threads and our area of expertise, and moving towards an area where other people are concentrated and do a much better job.
Ok, I get the drift. Just thought that the moving process was a bit complicated at first sight, and I personally lost mungo time figuring out how to get the job done. Maybe including a simple 32k php file with Threads or making it available from Infopop along with some short 'helpme file' would definitely make things easier for inexperienced users.
How will things look with regards to the Threaded-look in UBBT? Will this also be brought over? If so will there be an option to switch this off? I have users divided on the issue as some tend to like it but others simply prefer the old-style method of a single reply button, though personally I don't like the fact that I can't entirely delete certain posts because of this (all I get is an 'edited by' message) and a blanked-out post. Apart from that I like the option of having Threaded mode, albeit as an option.
On a side note, will there be any chance of seeing how progress is going and getting some sort of glimpse of the new design?
Good stuff, especially since toggling Threaded/Linear mode can have an effect on server load.
If I may add three more quick suggestions with regards to Threads and what could be changed then here goes:
1. Ability to switch of signatures in the CP. Option should then disappear from registration/profile screen as well as from post/reply screens.
2. 'Edited by' control. Would be useful (in my case vital) to have more control over this. I could really do with the ability to switch off users' power over whether their message should contain the "edited by" phrase or not. Once again a simple *click* in the CP would remove this option from edit pages, and mark all edited messages as edited. Or maybe the following setting:
a) edit post time limit (master setting) b) time limit without "edited by" message showing up
If you don't want the "edited by" message to show up, the two can be idential. If you always want it, the second option is set to 0. You could also allow a five minute window for example which would give users time to edit their newly-written post without having it marked.
3. Ability to switch off A) topic ratings. Useful feature, but should be an option to disable it via the CP. -and- B) publicly displayed email addresses (can be left out of the registration screen, but not out of the profile for some reason).
One more small one, I'm starting to like the censor feature in Threads which replaces words with others specifically chosen by the Admin. It would be great if the feature could switch phrases that contain the "=" sign. As it stands the equal sign is part of the syntax so it can't be used.
Little tiny one to add - please allow the Admin to switch off (globally) the ability to alter the thread title by those who reply. As it stands each new post has the ability to change the topic title, and this new title is the one that appears on the main forum index. It gets a bit confusing because of this.
![[Linked Image from navaho.infopop.cc]](http://navaho.infopop.cc/progress.gif)
