Matt

We were so pleased with that site at the time. Seems such a long time ago, now!

I would also suggest you try out our demo. It's free for 8 hours and we can extend it if you need more time: http://www.invisionpower.com/products/demo.php Please keep in mind that it's a hosted demo with many demo accounts on a single server. If it's busy, it may appear to be a little slower but that doesn't reflect the speed you can expect on your own server or on our hosting network. Also, file uploads are disabled in PHP so you may get the odd PHP warning when attempting to upload. That aside, it's a fully loaded IP.Board including Blog, Gallery, Downloads and IP.Content.

Hello, It's worth quickly noting that this forum is a pre-sales forum so only staff can approve posts in it and make direct replies. If you would like, I can move this into our feedback area which will receive more attention from the community. In a nutshell, IP.Board is PHP 5 OOP utilizing a front controller system with an underlying registry to service database connections, incoming variables, viewing member data and caches. The controller files are responsible for collecting content and then pushing it to the display later where HTML logic and special tags format the data. The display controller is abstracted so you can write your own handler for different formats. IP.Board ships with a handler for HTML and XML but you can just as easily write a layer that handles WAP or anything else you need. As for coding advantages, well, that's a very good question. IP.Board 3 is a brand new framework written from the ground up. And it is important to note that it is a framework that you can use. The forums are effectively just an application inside the framework. As is the Blog, Gallery and Calendar, etc. What this means is that you can utilize this power when writing your own applications. There is almost no need to make hacks or edit code. There are integration points in almost every area; searching, sessions, member sync, etc. it's all there for your use. We have good and solid database abstraction, good real re-useable classes for common tasks (managing XML, importing skins, etc). We have several static classes for text wrangling and member management. I could go on. There is also a hook system that allows you to insert code in almost every IF and FOREACH block within the default templates. You can also override the basic controller classes very easily. Put short, IP.Board is not a procedural mess of code that requires open heart surgery to apply basic modifications. $newMember = IPSMember::create( $data ); IPSMember::load( $memberID, 'all' ); $member = IPSMember::buildDisplayData( $member ); $photo = IPSMember::buildProfilePhoto( $member ); IPSMember::save( $memberId, $memberData );

Yeah. As always, feel free to report bugs and feedback but we really are tied to MySQL full text searching. I would presume that MySQL would see "lo-fi" as "lo" and "fi" and each word is less than 4 characters and therefore not stored in the index.

I did a fair amount of optimizing in 3.0.4. A lot was SQL side. I removed a lot of temporary tables / filesort operations in fairly common areas (profile, stats, etc). It's the kind of thing a board running well inside its resource footprint would never notice, but a board with a lot of traffic would. For busy boards, the additional I/O and delay caused by MySQL writing temporary files could lock up MySQL which will knock on to all subsequent requests for access. With regards to third party mods and hooks; as mentioned previously we have been compiling a list and I will email the authors at some point. In most cases, the problem is a slow MySQL query. I can think of one hook off the top of my head that adds a large GROUP by query on the post table on the board index (highly trafficked area). This query is complex and slow causing 1 temporary table and 1 file sort. There are additional tools in 3.0.4 to help capture slow and 'bad' queries which I'll detail in a resources article.

Indeed. Skins you create for 3.0.0 will work in 3.0.4 but you may have to tweak them with the very latest bug fixes. This is why we publish a skin diff so you know exactly what we changed and you can see if it impacts you or not. Of course, in an ideal world, IP.Board would be able to automatically detect what has changed and fix it manually but no such tool could be written due to all the different possible combinations of HTML code. As a trivial example, if an original template as: <strong><a href='http://google.com'>Google</a></strong> And you changed that to: <div style='font-weight:bold'><a href='http://google.com'>Google</a></div> Then it would be impossible to automatically apply changes based on: <em><a href='http://google.com'>Google</a></em> Even SVN (code versioning system) can't do that. The best it can do is tell you that the changes cannot be applied and it will have to be resolved manually.

We are at the mercy of MySQL, there's very little we can do. MySQL set up the boolean syntax so really you're better off asking them for improvements. Unless we were to create a 'really advanced' form that had a list of text input boxes with a drop down next to each one that said "As well as" "not including this", etc.

Please keep in mind that we have to rely solely on MySQL's fulltext searching and indexing. We can't really improve the result set further as we don't have access to their algorithms. Also, we have to deliver a functional search tool that can potentially search millions of posts in a very short time and without taking too many resources. Having said that, boolean searching is fairly accurate "this -that", "this +that". And there is an option in the 'advanced' search form to not display posts from a topic.

BBcode is actually just a fancy text replacement so you couldn't perform moderation actions by adding BBcode without a lot of dynamic code. Ironcially, anyone who remembers early Ikonboard may remember #moderation tags....

Ok, hopefully I won't regret this. ;) Brandon (Bfarber) is correct in that the today's posters feature did join on a permission index table to generate an appropriate list of forums as this is generally better than a long list of forum IDs in an IN() clause. However... Over the past few releases, we have been removing this join in favour of an IN clause as the join onto the permission index table causes a filesort with a temporary table which, for a very very busy site, is much like flicking on and off the power switch. I did actually originally flip it around and use NOT IN() in a QA build of 3.0.1 but Brandon removed it rightly because the forum IDs that are accessible via $classForums->forum_by_id are only ones that you have viewing permission on before additional checks are peformed (passwords, can you read topics, other users topics, etc, etc) so flipping it around to a NOT IN can actually expose you to more forums you never had access to anyway (staff forums, etc). Anyway, the end result is this: I did to the today's poster feature what I did to search / view new content and removed the table join in favour of IN(). While I was there, I removed forums that do not allow post incrimination thus restoring IP.Board 2.x's functionality and hopefully pleasing more people that the change annoys.

Often requested, not currently possible, may make a future release.

Upgrade to IP.Board 3.0 and it's automatically hidden. It's a free upgrade for active license holders. For non-license holders, we'll upgrade you as part of the license price $149.99. If you're on a free hosted IPB, you're probably on InvisionFree. If you are and you want to upgrade, then ask InvisionFree for a copy of your database (they charge an nominal fee) and we can use that to upgrade you from.

Very few boards concentrate solely on tech. Having a bunch of Apple, MS, Facebook, etc logos on a board about a musician, or product serves little purpose which is the thrust of Rikki's reasoning for giving them less attention. In any case, post icons are still there, you can still change them and it only takes a small edit to put them back into the forum view.

I only did this because you like Radiohead, by the way. If your favourite band was the "cheeky girls", I would not have done it and furthermore, I would have changed all method functions to private just to be spiteful.

As per Brandon. I could probably write a short note of what each field is for for most of the common tables, but it's a huge ask to go into deep detail on every field and table and to note exactly where it's used. By the time we've finished it it'll probably be out of date. In most cases, I'd venture that you can probably figure it out from the table name and field name. Granted, we do have some odd esoteric fields that are mostly legacy issues but on the whole it's fairly verbose as is.

We really need to move most of that into a class. I'll go through and make the relevant functions public.

I did do this for the member's table. It's under the Log in category in the dev docs.

Ok, that's done. From 3.0.4 you can use: $postClass->setBypassPermissionCheck( true ); And it will not bother you with user based permission errors. It still ensures you sent across a proper user and that the forum is capable of receiving a topic/reply/edit.

Yeah, I like it. Just changed it now for 3.0.4

A reasonable request. I'll add it in for 3.0.4.

This is precisely why we created alternate contacts. Most of our business customers have a licensed purchased by someone deep in accounts and they add their tech staff as alternate contacts. They can issue tickets and view downloads and resources directly related to the products you assign to them. If you need a hand setting them up, fire off an email to customer service and we'll set them up for you.

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

Seriously, this has come up many times before and it all boils down to what kind of forum you run. What use would we have for large obtrusive topic icons here? I can't think of many to be honest that would contribute something useful to the display. If you have a forum on tech, then I guess it makes some small sense but clear writing and an appropriate topic title should negate the need for imagery to reinforce the topic's point. For example: Apple releases updated iMac line New features spotted at Facebook Seems a little pointless to me.

Our biggest mistake was leaving the oven on when we went out shopping.