Luke

As far as I know it's still in the templates, just commented out. You could easily add it back. If not, I know there is a how-to article in the resources section somewhere.

There's also the security issue with AJAX as well. You cannot perform an AJAX request from one domain to another on most browsers. As mentioned in the wiki article, the best method would be script tag long polling. The server end may be better served by a server side application designed for the task (something other than PHP - although a persistent connection to MySQL might help).

The issue with polling I believe is not only server related but client related as well. You only get the message of the other participants on the next poll whereas with the persistent method you get messages in a more natural rate. Also not only are you opening/closing new http requests, but you're doing the same with MySQL. I'm not entirely sure exactly how a comet would work with PHP (or if PHP is even appropriate) but you could, in theory, have one session controller per chat room with a single database connection sending messages to all the persistent client connections. If this could be accomplished, I would say it's a lot better to do this than have thousands of users opening and closing http and database connections running a query per request.

That's why I suggested making two configurable options in the UserCP: #1) Toggle the behavior of the orange icon to "first un-read post" or "last post I made" - default being "first un-read post" #2) Toggle the behavior of the topic title to be first post or "last post I made" - default being first post On my user account I would set both to "last post I made". In the case where I haven't made any posts in a particular topic the default configurations would apply ("first un-read post" for #1 and first post for #2) You wouldn't have to change anything on the interface itself. And also (as suggested) when you click the "# Replies" you can click the number to see the last post made by that user (or better yet, the first post they made that's after your last post - so you can jump to what they said after you).

This is something that's been bugging me for a while. Essentially the three options you have is: 1) View first post (clicking on topic title) 2) Get last post (clicking the date in last post) 3) Get first un-read post (if you click the orange icon that only shows up if a topic is un-read) To me this isn't very intuitive... Not only that, but the third doesn't seem to always work.. What I would like to see is a fourth configurable option: 4) Get last post I made More often than not I've read everything before posting and I want to see everything else after I've posted. 9/10 even after I've clicked the topic and it got marked as "read" I still want to start on my last post. But in order to do this I have to wade through posts until I find the one I made (I think my last post was on page 3?)... So for this I would see two useful options: 1) Change "first un-read post" to "last post I made" 2) Whether or not the action is "first un-read post" or "last post I made" make the topic title that action as well. (Bonus points: If someone bumped a 3 year old topic that I posted in and forgot, it'll take me to my last post and I'll instantly remember that topic, thus saving time and making me less frustrated that a 3 year old topic was bumped!) Another neat feature is when you click on "# Replies" make the number of posts next to each name clickable and let you see their last post as well.

I'm I correct in assuming you can tell IPB to use sphinx or not to? If this is the case could you have a configurable define for a search profiling mode? As in when you go to the search page it uses FULLTEXT normally, but there's an additional check box to use sphinx? If the reason why this forum uses FULLTEXT is to match the base line, there has to be a way for people to have their cake and eat it too. I would agree that searching on this forum is immensly frustrating.

I'm suprised the chat isn't in flash. Are you guys using ajax or a comet form of communication? The reason why I ask is because ajax is highly ineficient for a chat service. It requires you to poll constantly with the server to get replies. Multiply that by all the users connected, and you have a bunch of connections opening and closing. The "comet" method, which I'm not entirely sure how to implement, keeps a persistent connection between the browser and the server. It's like downloading a file forever in a stream, but reading the data as it comes in. When you want to send a message, you just use ajax. In this situation there are only two connections made at one time rather than polling ever second or so. Meeboo does this method quite well.

It's also worth noting that you can change the FURL style with some changes. You may be able to match exactly the same URL style as before. The only issue is topic/post/user id's. The converter should keep these the same, but then again it might not. I've never had to convert from a competing product before.

Ok so perhaps this isn't necessarily a bug, but I do see it as a usability issue (which I have reported usability issues in the tracker before, and they were actually sorted). Basically the reason why you have to login to the AdminCP panel separately is because the session id has to be in the URL to prevent a hijacker from redirecting you to an ACP option with your active session (cookies was explored, but it was too risky). I believe, however, usability for the administrator can be improved by pre-filling the email address into the login box and putting focus on the password box. That way all the admin has to do is put their password in. Or better yet add the session id into the url so they don't have to login again (although I'm not sure if there are any risks in doing this). My issue is that I keep myself logged in to the forum, but I forget what email address I'm using. This happens especially when I am administrating different forums where I'm using a different email address.

I do like that I now have a single user name between the forum and the resource site. That was a huge pain. However, this new resource section seems rather dull compared to the previous resource site. That may be because it's new and you guys are still working on it though.

File Name: Moderator Center 2.0 File Submitter: Luke File Submitted: 06 Feb 2006 File Category: Components The Moderator Center has been discontinued. The 'Report Center', a new product, has taken it's place. The 'Report Center' is 2.2 compatible only and is currently under public beta. You can download the beta at http://www.custombb.net/. Please report any bugs here: http://www.custombb.net/forum/index.php?showforum=4 You can also test the mod side at http://www.custombb.net/forum/ -------------------------------------------- "Moderator Center" is an Invision Power Board modification that replaces the default Private Message/Email report system that many message boards use today. Traditionally when a report is received, it is sent to moderators responsiblefor that area, or the super moderators and/or administrators. The biggest problem with this method is communication between moderators, and efficiency. For example: Let�s say Bob, Phil, Jane, and John were moderators of a specific forum. When a report is sent, each of them would get the same report "This message should be <fill in here>". Bob takes care of the problem, but Phil, Jane and John still have the report in their inbox with no notice the problem has been solved. As a result each of them click on the link provided to find it either solved, or confused about what the problem because it no longer exists. With this addition you can store reports in a central location for your moderators collectively where they can mark the status and make comments for fellow moderators to see and review. Also, starting with version two, reports are organized by Topic and condensed by post for you to keep track of previous incidents, and keep track of what your moderators are doing for you community. NOTE: The main file /sources/components_public/mreport.php is Zend Encoded. If you would like the unencoded version, without the copy-right notice, you may obtain by donating $10 here. (Please note that since im doing this myself, it may take up to 24 hours for me to email you the non-encoded version. I hope to have some sort of system up in the next few months. In the mean time I will be keeping all PayPal emails for the Moderator Center) Make sure to upload sources/components_public/mreport.php in BINARY mode. Click here to download this file

I'm all for stronger passwords... just as long as the feature is suggestive, like a color coded meter showing how strong the password is. I HATE sites that force you to have at least 8 characters, contain 1 number and letter, and/or change your password every X amount of time.

I know I'm lazy, but I don't think anyone would bother to register on a forum and go through email validation just to say "Great idea. Thanks for sharing" and then make no further posts on the board. Regardless, it would be nice to display some kind of message that requires a box to be checked if last post date is older than a year (or range specified). That way they know that they're bumping a topic that old. And having an auto-report would be cool too :). I'm not saying "do it now", but it would be nice for 3.1.

If the topic is two years old, chances are your record of reading it doesn't exist anymore. The date is so small, I don't even really look at it. Most of the time I assume a topic is current enough to look at it. The only big clue I have is the badly converted quotes (which may have happened because this forum was the gunie pig for conversions, no going back sort of thing). If someone has something to add to the topic, I don't mind that they bump it. But I want them to know that they are bumping an old post, so at least they've been warned. If they've added something to the topic, by all means let them add it. But when you have someone bumping a topic that is three years old with their one and only post like this one, there is just no reason for them to do this. They can make the excuse that "I didn't know it was old" just as I make the same excuse that I didn't realize the topic wasn't current before reading it. But a little warning to them before they do it would prevent accidental bumps. Many forum softwares at least provide a warning where they have to tick a box before posting so they fully understand what they are doing. There are a lot of features that "would be nice" but "is better left to a mod". This is not one of them. I'm smart enough to see what is or isn't an important core feature. No one, especially on this forum, likes a topic bumped that is 2-3+ years old. Many of them get locked. Very few topics that old are helpful enough to get continually bumped. One topic that comes to mind that is helpful and very frequently bumped is Deby's topic about that motor company. Anything else... there just isn't very much that is worth bumping. And if someone is going to bump something, I want them to know full well that they're doing it.

FYI, you need way more than 16MB in memory, and most computers that are years old at least have 1 GB of RAM. Your memory should be set to the standard 128MB, or at the very least 64MB (which should get you more millage than 16MB!). If you don't have much RAM, it's not that expensive. Also the FURL feature is going to take a bit more resources on both the Apache and PHP end. If you can't raise the memory limit, I would recommend going back to the previous standard URL scheme. Also, if your memory limit of PHP is 16MB I would take a look at the memory allotment in MySQL as well. This should at least be at the standard level. I would look at Apache's settings as well.

Why? Because if a topic that is 2 years old gets bumped and I've already read it but forgot, and read through most of the topic and realize that the topic is 2 years old, I get irritated.

Honestly? Most every other board has this. At the very least "This topic is over a year old, are you sure you want to bump it?" would be better than nothing. Just because a feature isn't in at present doesn't make every feature suggested better suited for a mod.

I know this has been suggested before, but it's already in several other forums, and it really helps people, especially newcomers, to not bump old topics. What many other forums do is put a banner in the post window that say something like "This is an old topic. Are you sure you want to bump it?" with a check box. I would like to take it a step further: 1) The fast reply should have the banner with a check box. 2) The regular reply takes you to a screen with the message and the checkbox with a submit button (and thats it) and checking the box and pressing the button takes you to the posting window. See, you want to make it super in your face obvious that you're bumping an old topic. 3) If someone does bump a topic that is considered old, automatically generate a report in the report center so a moderator can see it. Most people who see the message will realize it's old, and not bump it. People who don't care (spammers) will get reported instantly. And in the rare case someone actually has something meaningful to contribute, but the moderator can check it out anyway. What is considered "old" should be configured. Usually anything older than a year, but this would vary from community to community Also.... I'm not sure if deleting the post "un-bumps" it, but it would be nice if a moderator could lock and "un-bump" it. No one wants to read a 2-3 year old topic that he/she read a long time ago, but forgot about.

I would check indexes to make sure they are all there, and do a quick repair on all tables to rebuild indexes. After that I would run an optimize. If it still seems slow in some areas, you could try turning the sql debugger on and identify queries that are running slow on the slower loading pages.

The first time I saw it is the way it is now. But after looking at http://www.ipbforumskins.com/forums/index.php, I'm going to have to say it's a lot better than what we have on this forum right now. The breadcrum got wrapped more on the other version? On the ipbforumskins website, the breadcrum actually looks smaller and seems to have more room that the version here currently does. Larger banner? Most folks have a larger resolution these days and there seems to be plenty of space for a banner. If worse comes to worse, maybe the banner could be displayed in a background image? I prefer the version on ipbforumsskins. And this is coming from someone who first looked at the way it is now, and is just now looking back at what it was. The extra black bar looks horrid. It looked a lot better before.

Not only is it against the Google TOS, but even if you were to generate the code automatically and just have the user put in the account id, that code could quickly become out of date. You could just add the code in the wrapper of the skin, but wouldn't you have to do that for every skin? A hook could insert a "block of code" where it needs to be on every skin, regardless of it's edited or not. A textarea hook is a good idea.

In terms of "everyone is paying the same", but not fair to the terms of the license. When I bought my lifetime license I assumed it would always be equal to future licenses. The only difference is the terms of what is paid... I know perpetual license holders would rather have the discount, and standard license holders would rather get it free... but as as a lifetime license holder, I would have much rather had everyone pay $50 per year for a single key that works on all active licenses. The way it currently is, lifetime license holders are not being treated equally because the $25 every 6 months is for upgrades and support. If that was extended for this service, it should be done the same to the other licenses. Either that, or everyone pays the same as an external service. But that's my opinion anyway. In the end I'm happy I have a way of using the service without converting my license to a standard one, and IPS has an extra incentive for people to renew their support contracts. I may not be completely happy about it, but at least I get to keep my license.

I am pleased there is a route to use the service without converting the license. At the very least it can be used without converting the license. I am, however, a bit unsettled that standard license holders get it included with their $25 every 6 months. It says that the legacy licenses are not considered equal to the standard licenses. I would have much rather had everyone be able to buy it as an external service outside their license. Moving forward, I guess it makes the most "business sense". Lifetime users have to pay full price, perpetual users get a discount, and standard users get it for free (well... "included"). In the end everyone is paying $50 per year, and standard license holders have to keep paying the $25 every 6 months to use the service. It gives those standard license holders a reason to keep paying $25 every 6 months rather than only paying when they need support/upgrades. In the end I want IPS to flourish, and I'll be happy with what we're given. I may not be completely happy about it (would have rather had everyone pay $50 per year, as a lifetime license holder), but I'll live.

Using FTP is just a way to use the hosting accounts user group whereas PHP itself would use the nobody group. Any files created by the FTP user cannot be edited/deleted by PHP, and vise versa, unless the files are CHMOD'd to allow "Everyone" to edit/delete. PHP does have FTP functions that would allow it to do this. Essentially it would download the zip file, uncompress it to a temporary location, and upload it to local host using the ftp function. You would, however, have to put your ftp details into the ACP. That can be a security risk though if someone hacks into IPB. Normally if someone got into IPB they could only effect files that PHP can write to... but if you have FTP credentials stored in IPB, you've given them a backdoor to all your files. The other issue is having the extension installed in PHP to have the ftp functions in the first place. Also on most cpanel installations, the primary FTP account credentials are also your cpanel credentials. For someone to get ahold of this is disaterous. The *best* solution would be to change the way IPB is installed. When you unzip IPB you have an expander and another archive. This expander would unzip the archive in the directory and all the files would belong to the "nobody" group. This way PHP has the ability to edit these files without chmoding them. It presents the same security risks as the ftp method because an attacker could change/delete any files, but at the very least they would not be able to touch your cpanel. Besides secruity, the only issue would be: does PHP have the extensions to extract the files? Either way you'd need to put your client center details into ACP. Someone could get ahold of this, and that may not be a good idea either. All around, the way it is works just fine. It's a bit tedius, but at least you're not comprimising your security.

I can stop paying for the service and still have lifetime support, upgrades, and access to the resource site (a "service" btw).