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.
If I may add more one request, or rather a suggestion to include a current feature in UBB.fusion ... it's the display IP function. As an Admin I find it extremely useful to see the IP number next to each corresponding post.
Back in the day (when using Classic) I had to click on a certain link in every post just to bring up the IP... so annoying and time-consuming.
The normal forums aren't the big problem, people were heavily annoyed but I could live with that, although I shouldn't take it that easy, since they're my basis for anything I do. Anyway, the real problem is, we've also been using internal forums like a fake intranet, to discuss and plan things. This "mark all read" bug made some team members, including me, miss some crucial information at the wrong time, several times.
In my opinion this bug alone was worth a hotfix. I don't know about individual cookies size limits, but with firefox it's just a pain when you have over 10 internal forums for different topics, plus over 20 publicly available forums, and everything gets a reset once a hour or so.
It has never been a problem before, but now we had to shift sensitive topics to email based groups. With that in mind, I consider 6.5 itself a public beta.
In the past I have been very fast with switching to newer versions, and I have never been disappointed, bugs were fixed soon, but these are known since late september, and I don't have access to additional beta versions. I'm sorry if this contributes to delay in development of your new product, and I do understand why strict roadmaps are an important thing, but maybe the old product should be stable first.
Two new small requests, one from the UBBC side (v 6.3.2 as I last remember it before jumping ship) and one from UBBT:
1. A checkbox to close topic when making a reply (as Admin). Soooo useful in UBBC, and surprisingly not present in UBBT. A lot of the time when closing a topic the Admin wants to add a final comment in the thread. Would be great to see this small but convenient feature appear in the new software.
2. Private forums. I don't know how the current version of Classic deals with this, but I really like how in Threads people who don't have access to a particular forum don't even see that is exists (on the main forum index). In Classic I had to come up with funny titles (such as test forum #1, bug testing area, etc. ) as the forum names (and even total posts counts) were visible to all.
Tentative name? Well, Ted laughed when I accidently called it UBB.x, so that's out. <img src="https://www.ubbcentral.com/boards/images/graemlins/ooo.gif" alt="" />
Beta will be in the spring. <img src="https://www.ubbcentral.com/boards/images/graemlins/laugh.gif" alt="" />
If there's one thing which works like Russian tank in Threads, it has to be the censor feature. Please tell me that this has been reworked and refurbished to look like the Taj Mahal. It's a bit crazy that I can censor stuff out and yet people can still include those lines in URLs, something which UBBC has prevented for numerous months now, if not years.
Also, (not sure if this works in UBBT -either way- it definitely doesn't work in URLs...), but I definitely agree with the way in which UBBC also used the censor feature in Private Messages.
The main reason is that people usually spam others using PMs and include affiliate links in the process. Classic has the great approach of using the same filter in PMs as well as regular posts, so spammers can also say goodbye to using PMs to spread their filth.
Would definitely like to see this option implemented, otherwise spammers can do what they want on our boards and there's nothing we can do about it...
Another great feature would be to limit the ability to use the PM feature until a user has A) sent X number of messages -AND/OR- B) been registered for an X amount of time).
PMs are censored. There's currently a bug using a slash - since the new censor feature has the matching etc.... I think you just have to comment out the slash to make it work. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" /> HOpefully they fix that in 6.5.1.
Would be nice to see a few added elements, even if they have to be bought as additions to the new product. A proper chat feature would be great for instance if Infopop could provide it ("made by Infopop" = it's gonna work fine!).
What would also be nice is a feature to control forums which people have to pay to access, including the ability to limit only part of the board to paying customers (I believe Eve takes care of payments or something of the sort - would be great to see this feature in a downloadable product).
That's true, but don't most hosts specify IRC as the usual persona non grata? Could an added chat module take up even more server resources than the bulletin board itself?
Another feature which I thought was quite useful was the Multiple Identity Detector addon from Threadsdev. Sometimes an admin can spend a lot of time & effort in matching up people's IPs to see if they're one and the same person, and often the IP won't even give a definite answer (dial-up, proxy, etc.). This feature seems very useful in such circumstances.
Also (I'm not sure if this is a bug or not...), would be great if the new product took its character encoding techniques from Classic. I don't ever recall having any problems there, whereas in Threads I can't even use the Euro symbol for instance when posting (also cut&pastes often contain similar errors). Don't ever recall having a problem with this in UBBC...
Also, it would be very useful to be able to customize several tiny details in the CP that have been previously unavailable (for which only hacking the board was the answer).
The first one that comes to mind: the dimensions of the different icons, such as new topics, no new topics, attachments, closed topic, etc. Would be nice to be able to set these via the CP as opposed to editing one of the files. Would be even better if the system set the sizes automatically.
While we're on the topic of graphics it would be useful to be able to make changes to the order in which graemlins are displayed.
Another small thing that would be useful to set not only in the CP (as a default) but also INDIVIDUALLY is the way that UBBCode URLs and graemlins are added to messages. URLs are added with a space before and after the URL. Graemlins are added with only a space before the graemlin itself. Would be extremely helpful to be able to customize this according to users' preferences.
There are two problems with IRC applets. The first is that the IRC applet code has to live on the same server that it's connecting to, so we can't just ship an IRC Java applet. The second is that every applet I've seen lets you just change your name, and as there's no real authorization going on IRC-side, I can just log in with any old client and be who I want to be regardless. Not to mention the problem with different naming rules...
The chat ban goes way back to the mid '90s, when the most popular chat scripts of the day were Perl/CGI based, and completely dynamic. They were based around either streaming data to the client, or refreshing a page using a meta tag. In either case, that's a heck of a lot of scripts being called relatively frequently.
I've written my fair share of chat scripts. They're all based around a static HTML page that refreshes every 8 seconds or so... very light on the server. If not for the general global ban, something like that could easily be integrated in our downloadables.
(It's interesting that hosts permit shoutboxes, which basically ARE chat scripts...)
The multiple login detector is pretty cool. I wrote something like that for TrekBBS. Unfortunately, it's also really rather special-case, so it's not likely to be a stock feature.
The character encoding issues occur because Threads kills all HTML entities when HTML posting is disabled, regardless of if they're "safe" or not, using the htmlspecialchars() function.
Classic doesn't have such a builtin function to use, so when HTML is disabled, we only kill certain things. We'll probably end up taking this approach in the new product as well.
Image dimensions will not be hard-coded in the templates, if they're even included at all.
Graemlin ordering is in the database, but there isn't a UI planned to allow for the order to be edited, at least in the 1.0 release.
Could you explain the space problem, please? I don't understand.
I'm not really an IRC fan... to the point that I don't even enter my site's chat section... not even once per annum. Have seen a lot of hosts explicitly ban IRC on their servers though, so that was the first thing that came to mind. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />
Funnily enough I thought about the 'shout box' feature before making my previous post but then sort of figured it was like an "extra forum" type of feature, though very chat-style if I may say so. Maybe adding one of your server-efficient chat modules would be a great addition to the shout box?
I guess it all comes down to scale - when people's sites grow they tend to not only want better hardware (often dedicated servers because that's the only way they can continue to function), but also more functions. The chat feature seems like the next best thing, especially since the login/password data really needs to be matched up in order for both to work side-by-side. Can't see any way around it...
The multiple-login detector would be nice, but understandably it won't be useful for those who aren't bothered with ghost/clone posters (a real problem when it comes to contests...). Still a very useful security feature to completent IP identification for those who need it, and although I don't think it's necessary at all in 1.0, it would be nice to see it included several months down the road from the first release...
The character encoding issue has been a bit annoying, especially when you have people who are used to Classic. Suddenly this throws a whole new problem at them because all of a sudden they can't cut&paste comfortably or post special (in some cases rather usual) characters with ease. Just seems like one of these things that Classic had worked out to perfection... but only became a problem after moving to Threads...
Graemlin ordering is a nuisance because it's not fun to set them up "the hard way" due to their different sizes and shapes. At least please allow for post icons to be set up in a certain order, as those are interestingly enough set to a certain pattern/order on most boards.
To clear up the "space problem", what I mean is that when posting a reply if you use the URL function (in UBBCode) then in your message a _space_ appears both before and after the URL itself. This is just a formatting issue and some people like it while others don't. A similar situation appears with graemlins - when including them by clicking on the appropriate icon you get a space before the icon but not after it in the message box (I believe UBBC included a space BOTH before and after the gif). It's just a question of personal preference, but I've noticed that some people get annoyed with the differences between different bulletin boards as well as their personal preferences when typing up posts.
Any spaces added before or after the code, by the instant buttons, will remain there, as that's done on purpose. Certain tags may not parse correctly without having a space before or after. Some may, however, in which case the user should stop using the instant buttons and type the codes instead, which, at least for me, is always faster. <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />
Graemlins, for example, need to have spaces in certain places to be parsed. For exa:)mple.
Any spaces injected when interpreting the code for display will remain, as those also would be there on purpose.
The way the new parser works would preclude any sort of global user preferences from being considered during the parsing.
So I believe the emails have been sent out and there are probably Beta testers out there hammering on the new product...somewhere!
Any chance of us getting a link to a Beta of the new forums? I was one of those that would have loved to Beta the new product, but would not have had the time to really hammer away and learn the new product until Summer.
But still curious to see it in action and/or interact as a user - just to see where we are to date.
From the monthly newsletter - not sure if it answers your questions, but it might help. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
[]The beta testing group for our new downloadable product has been assembled and testing will begin next week. We're getting increasingly nearer to our target date to release a beta version.
Just as a reminder here are a few notable points on the new product:
It's entirely new. This is not an upgrade, update or patch to UBB.threads™ or UBB.classic™. We will have import scripts released to make the conversion from your existing UBB.threads™ or UBB.classic™ possible, but this will not be simply an updated version.
The user interface will have a flavor similar to both UBB.threads™ and UBB.classic™, making it familiar and immediately easy to use. There will be no large learning curves - simpler is better.
Your existing license(s) will apply, as will your Member Area access. Next month we'll have more news and perhaps some sneak peek screen shots as we get closer to the public beta release.
Yap, saw that a day or two ago, thanks Ian. Looking forward to getting 6.5.1 installed by this weekend on a few sites, and really looking forward to seeing at least screenshots, if not a beta "functioning" board of the new product.
i) if this is the last (or nearly the last) release of UBBT, will anyone handle the remainder of the bugs still in place?
ii) I know we haven't even seen a beta of the new product (what will it be called anyway?), but when can we expect the first, proper non-beta release?
Keep up the good work, fellas! Looking forward to getting 6.5.1 installed by the weekend. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
1) We may choose to do another release in the future to mainly fix any importer issues. We may choose to also fix other bugs in that release. (UBB.classic 6.7.3, for example, will be released in the coming weeks. It's mainly importer fixes, but does include a handful of bugfixes as well.)
2) I can't speculate on dates right now. There are no public dates set beyond the planned development snapshot release in late March. We do want to make sure to hit the "Spring, 2005" date that we've kept saying over and over...
Here's an idea that strangely enough hasn't been implemented yet, especially since it's such a simple one which I don't believe would require much code work:
What's the best way to keep the forum data safe? Answer: back up the tables regularly.
What's the easiest way to do this for the average user? Answer: use the 'backup tables' function in the CP.
Now this is something that we should all be doing, in my case I do this every fortnight. Some of you might even be doing this on a weekly basis, or even more regularly (damn, this sounds like I'm writing about something else... <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" /> ).
Obviously the best time to do this is when the forums are the LEAST busy, which is probably when you users are fast asleep. There's only one problem - having to manually switch the board off and on again.
When I hit 'Submit' and start my table backup at around midnight... I have to wait until 2:30-3:00 AM so that I can switch the board back on before crashing out myself. Why isn't such a simple task automated? Why can't the table backup feature automatically close the board when it starts... and then reopen the board after it's finished with everything?
Fair enough if you use an external program, but why can't the built-in module simply turn off the board and then turn it back on again? <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" />
Ahh, there we go. How hard would it be to make the internal program close+open the board automatically?
Also, what's the benefit of using an external program? Speed?
Overall the whole point of a backup is to make it when the board is least busy, but having to stay up until like 4am just to switch the forums back on again is a joke. This stuff should be automated.
Just cannot believe that this hasn't been automated yet. Opening the board is probably what matters most, as closing it can be done when you're starting the backup.
Ideally you want to start the dump when you go to sleep and have the board reopen automatically once the backup is complete...
One more thing, the ability for the admin to PM all users would be greatly useful. I know there are ways to email all users, but why spam everyone's mailbox when you can use the internal PM system instead?
Here's one more: just like we have a trash can on the Windows desktop, it would be useful to have something similar on the forums for the Admin to use. Sometimes moderators erase good threads and people get angry, the Admin can't see WHY the thread has been erased, and worst of all there's no way to bring that post back if need be.
Why can't we have a "trash can" that collects deleted threads, and that only the admin can see (+moderators if the Admin allows so). This has to be a piece of cake in terms of coding because in effect you would be creating an invisible forum and erasing threads would simply equal moving them there.
> Sometimes moderators erase good threads and people get angry, the Admin can't see > WHY the thread has been erased, and worst of all there's no way to bring that post >back if need be.
Take the delete permission away from mods. Create a hidden forum where mods can move questionable threads.
[]Replies no longer have their own subject, so that problem has been solved. [/]
Can I ask why? Replies IN the subject is a major plus from the point of view of many of my threaded users -- if their reply is short and to the point, they can simply type it into the subject line and hit enter. Saves the poster's time because they don't have to bother to put anything in the message field, and saves the reader's (in threaded mode) time, because they don't even have to bother to open those posts where the entire post is contained in the subject.
Most of the board is closed to non-members, but you can see what I mean here:
When I, as a threaded user, see those (EOM)s I know I don't have to read that post. Saves me three pageloads and all the database queries that would go with that.
My users would miss their automatic EOMs terribly!
[]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="" /> [/]
Of course, I have no idea why it should or shouldn't work, but I know you can install a clean phpbb board on a fresh database and then "Restore Database" from within the Admin CP. It does its thing, whatever that is, LOL, and when you move back to the index page, you have to log in with your info from the database you just restored. I assume it just writes over the tables in the (mostly) empty database? And since you're not actively using it, but just sitting there waiting for the restore to finish, that makes it okay?
You can tell I'm a real genius about this stuff. <img src="https://www.ubbcentral.com/boards/images/graemlins/confused.gif" alt="" />
lilywhite, unfortunately we've changed the way that threaded mode replies are displayed in such a way that it makes nim/eom messages impractical. We did make this change knowing that this would inconvenience those users, however we believe the change will be for the better in terms of overall topic navigation.
![[Linked Image from navaho.infopop.cc]](http://navaho.infopop.cc/progress.gif)
