rct2·com

I have been perusing thru the forums here and feel that the site organization is a bit frustrating.

There are several boards for the same product but in a different category:

IPS Company Feedback -> IP.Board
Peer-To-Peer Technical Support -> IP.Board
Product Modifications -> IP.Board
Tracker -> IP.Board

Although I appreciate that it is grouped by General area topic then by specific product when researching or reviewing the product it would be most helpful to
have all forums for that product in one section.

It would be great if there were a way to create an Alias of forums and categories so that you could group existing content and not have to
have disparate conversations that span different categories.

Example

Product Forums ( A category )
-- IP.Board ( A Category )
---Feedback
---Peer-To-Peer Technical Support
---Product Modifications
---Tracker

The above "alias" forums would appear in the forums lists.
they would serve to organize existing forums.

Just a few ideas ;)

S

Guaranteed is the mimimum memory that you will always have. Then there is a 'pool' of burstable memory for all the VPS customers on the same server. You get as much of the burstable memory that is available if your VPS could use it. How much of the burstable memory is available depends on all the sites on the server and what they are doing. So it's important for you to be confident that the sites will run in the minimum memory.

If you have a private IP address you can be onfident that only the sites on your VPS use that address. Otherwise you will be sharing an address with other VPS customers. So there will be more delay before the request from a visitor gets through to your sites. It will depend on how many others are all trying to reach other sites on the same IP.

It's also a good idea to have your own IP in case other people have sites on the same IP that are:

attacked by DDOS scripts
are vulnerable (weak security) and start spamming. Anti-spam software tends to work on IP addresses, so you may find your mail is being rejected because somebody else on the same address has 'triggered' the IP address to be added to the worldwide anti-spam databases.

Assuming this is Linux, if you really, really tweak with the MySQL and Apache memory settings you can just about get away with running a 500 simultaneous user IP.Board in 512MB memory. Programs are always being swapped in and out of memory, so you don't necessarily need <minimum>*<the number of boards>.

If it's automated, and a near zero effort activity, and at least one customer is requesting it, then .... ?

Preface: This is not a rant or flame, but the hope of appealing to the IPB powers that be for a mutual beneficial opportunity. If there was ever a time to significantly increase your forum owner customer base and also do right by what is probably many thousands of people, you have an extraordinary opportunity - especially during this lasting recession depression.

As you know, the creation and success of a forum is hard work and also an investment in the platform you own. This past week a confusing and misleading email was sent to existing vBulletin forum owners about an amazing upgrade offer to the new vBulletin product and a discontinuence of its old support policy. When the smoke cleared, it became apparent that Jelsoft, now known as Internet Brands, a NASDAQ company, is now demanding that owners of vBulletin forums pay practically the same price to "upgrade" their vBulletin forums as new customers. If customers don't "upgrade" now to an entirely new product which has no demo or release date, their ownly choice is to practically pay for an entirely new forum since the existing customer "discount" is a mere $20 of the cost of the vBulletin 4 forum which is $195. Forcing your customers to pay 89.7% of the price of the new software is an outrageous, disgraceful customer disservice, especially when the new software isn't even out of alpha testing.

Many of the long time vBulletin users who helped create "vBulletin.org", the large vBulletin modification site, are now regretting that decision greatly. In addition to the digust towards the evil empire of forum software, the practicality of upgrading vBulletin software quite simply is not there.

This is where Invision Power Services can increase its user base signficantly by offering some discount pricing to current vBulletin owners or by crossgrading. Many vBulletin forum owners would sooner crossgrade to Invision Power Board and wipe their hands clean of the entire Internet Brands vBulletin pricing fiasco and avoid what could be even more punishing practices in the future with annual or semi-annual vBulletin upgrades regarding more payments. Please consider this opportunity.

Michael is correct, it is certainly possible, although it's a bit of a long shot.

I don't think it's really appropriate to speculate on what has happened to a particular site - if the owner has concerns they will contact us and we will investigate what happened. At the moment there are no known vulnerabilities in IP.Board's latest supported versions (3.0.3 or 2.3.6).

Probably security hole in custom skin. I am not sure.

Multi-moderation can just about achieve all you want, based on your description.

But that's the point, what can you include by default that is suitable for any board, in any language? Other than some faces and basic ?, ! type icons, I can't think of much else that can be included by default. We have to appeal to a very wide range of boards out of the box.

But don't you have to hack to add more than the standard 14? So isn't that option still open to you? To have a mod that puts them back, lets you define them, supports right-click etc?

No real reason. I've made them public.

So there are 2 versions of 3.0.4 then? ;)

Seriously though, thank you.

Just added that back in for 3.0.4 (locally). You're welcome.

I thought when you right-clicked on the post icons that you were showing a feature that I didn't know existed. But it would appear that you have a hack installed on your board.

Personally I don't agree. Sure your nice large icons help people find posts within a forum that may interest them, but a more efficient way (IMO) of organising the topics would for them to have their own forums. e.g Apple forum, Linux forum, ... Organising like that helps visitors focus much more quickly on what they may be interested in, rather than having to find the correct post icon.

I do use post icons a lot, and will miss them. But I guess I'm not so bothered about their deprecation that I bother to make a YouTube video. :)

My 'must have' feature I want back is the link to go to the 'first unread' post in the search results screens. I don't want the last post if I cannot see the unread posts before the last one. That's their biggest mistake.

I'll add to that the PLESK Control Panel

http(s)://chosen-prefix.myhostingcompany.com:8443

It seems to me that heated/contentious topics can often cause flaming/trolling and excessive use of positive and negative reputation. A single topic could skew reputation values for certain members.

Good moderators often close topics that are overly inhabited by flaming/trolling posts. Much better that than hide them completely. What I am thinking is that it would be good if, once a topic has been closed, that it should be no longer possible to add/subtract reputation from posts in that topic.

Similarly for topics with polls. Once closed, no more voting.

If I were a director of InVision, with the well documented turmoil going on at vbulletin, and a tranche of new versions of stuff here, plus some brand new products, some good strong user documentation would be right near the TOP of my list of things to do,to make it (as far as possible) a 'no brainer' decision to both buy the product if I didn't have a board, and to transfer over to it, if I didn't.

I say that even though I have been very public in my discontent about the lack of support in general (not just documentation) for developers. I think a user manual would be a priority.

Yes. The PHP memory limit is a "soft" limit in that PHP only checks when requesting more memory at runtime if it has reached the limit. It is the same as for the other limits like post max size, upload max size, or cpu limit. Setting these limits high have no effect on execution unless the script actually needs the extra memory. For a well written script like IPB, you are only going to be affected by a high limit if the script really needs the memory for some operation and then it only hurts if lots of people simultaneously use lots of memory.

If it was a real "hard" limit that upping it would really cripple a system, they wouldn't allow you to change it locally or in your PHP script. It takes no privileges to up a memory limit.

Almost GroundHog Day :)

I looked and cannot find if its a setting that can be turned on. So I am guessing that there is no way to print (with formatting..don't tell me ctrl+p its rubbish)the conversations?

The way the forum handles printing of topics would be great for conversations as well. I do not know why this was not provided from the start?

Can we please have this feature in the future.

alright, ill give up on it, filed a dispute on paypal, hopefully ill get my money back at least the money i paid for the license, just slightly frustrating when something like this happens. :(

The fact that such a script exists is not really the issue. Now if this topic included instructions on how to 'inject' that script onto a site through a vulnerability in IPS product, then I agree we should all be worried and screaming for the topic to be removed.

The fact that such a script exists is not really the issue. Now if this topic included instructions on how to 'inject' that script onto a site through a vulnerability in IPS product, then I agree we should all be worried and screaming for the topic to be removed.

Not sure it is a good idea to post the script, which could be used by others.

Hey guys,
So I'm not an expert (in anything), but I've been running a few pretty active forums for almost 8 years now (most of these years were IP.Board!). I've had to endure several server moves. I wanted to write a brief outline of my experience, since moving an active forum to a new server isn't the easiest thing in the world.

The dilemma with moving an active forum is that:
a) because it's active, you don't want your many users to tolerate any downtime.
b) because it's active, chances are your DB is huge and so this increases the time required to move over, and the potential downtime.

Moving a forum entails a few things:
1) Getting the code up and running on your new server
2) Getting the database moved over to your new server
3) Pointing your users at the new server. I'll assume you're sticking with the same domain so this will be just a DNS flick.

Solution #1: You could blindly do these three steps, but you'll be faced with a bunch of issues. The main one is that you will have two servers running off of different DB's, and there's no way to guarantee that the DNS change propagates at the same time for all your users. You'll have people posting and browsing the old forum, and people posting and browsing the new forum. Any changes to the "old" forum will disappear once everyone has propagated over to the new forum. Unacceptable.
Downtime: None.
Discrepancy: Yes.

Solution #2: To prevent the discrepancy between having and old and new forums running, you could just turn your board "offline" during the propagation period. The procedure would be:
a) turn the board offline on the old server
b) move the code/DB over
c) wait for propagation period
d) turn the board online again on the new server.
This will prevent your users from wondering where their posts went, but you have to remain offline for the DNS propagation period (which is on the order of hours, and reportedly can be even more). Again, unacceptable, because you don't want to be down for hours.
Downtime: Several hours, but you can post a nice message.
Discrepancy: None

Solution #3: Point both servers at one DB (DB-copy). The procedure is:
a) Setup/copy all code to the new server
b) Turn your forum offline.
c) Copy your DB over to the new forum
d) Point both servers code to the DB on the new server
e) Turn your forum online.
f) Flip the DNS switch and wait for propagation.
By pointing both servers at one database, you guarantee no discrepancy. That way, whether users are accessing the old or new server when DNS propagates, they will see the same things. You only need turn your forum off for the duration of DB copy, which you can probably pull-off in less than an hour, depending on the size of the DB.
Downtime: Probably on the order of minutes, and you get to post a nice message.
Discrepancy: None

Solution #4: Point both servers at one DB (DB-replication). The procedure is:
a) Setup/copy all code to the new server
b) Setup master->slave replication between the old and new DB's
c) Point both servers' code to the DB on the new server (which is the slave)
d) Cancel the master/slave replication on both servers
e) Flip the DNS switch and wait for propagation.
Essentially, this is the same as solution #3 but instead of having to turn the board off, you rely on MySQL's replication functionality, which lets your new DB mirror your old one. The one issue is that replication requires a bit of technical know-how. There's a good guide here. Also, that you will have a bit of cross-server traffic (for the DB replication, and from the old server's code to the new server's DB during propagation).
I just tried this on a site with several GB's worth of MySQL DB (forum, etc) with zero downtime as far as my users are concerned. A completely transparent move.
Downtime: None
Discrepancy: None


The devil is always in the details, and I didn't go into any of the technical ones. There's some good guides around about how to carry-out any of these steps, and they'd probably do a better job than I can. I just wanted to point out that there is a process whereby you can move a large, active forum in a way that's transparent to your users.

Can you not manage this through you app's coreVariables.php?

At least, that's how I understood it based on the article. http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&article=7508