Part of my daily routine is reading our company forums, my Twitter timeline and other forum-centric forums. There is a growing buzz of interest from vBulletin customers unhappy with the direction Internet Brands is taking the product. It seems that with each incremental ‘maintenance’ release we get an influx of new switchers and topics enquiring about switching.

This blog entry will attempt to consolidate some experiences from recent switchers. Those considering the move may find this information useful. It’s one thing for us (IPS) to tell you how good we think our product is, but it’s another to hear directly from those who have done what you are contemplating.

Bob Schwarz writes how he’s seen an increase in traffic since switching from vBulletin + vBSEO
http://bobschwarz.com/forum-seo-vbulletinvbseo-vs-ipb-with-seo-urls

Bob also writes his “Goodbye” to vBulletin
http://forum.ipbsetup.com/blog/2/entry-13-aws-blog/

Cheyne Wallace writes about his experience with vBulletin and IP.Board
http://gazeek.com/articles/vbulletin-to-ip-board-a-short-journey/

Jamie writes about his experience moving from vBulletin to IP.Board
http://community.invisionpower.com/blog/3003/entry-4821-the-move-from-vbulletin-to-ipb/

Mike switched from vBulletin a few months ago and writes about his experience:
http://www.ipb-webmaster.com/blog/2/entry-29-i-can-finally-say-it/

SonicEffect, Shuvo and Glorify switched recently and write about their experience:
http://community.invisionpower.com/topic/308554-from-internet-brands-to-invision-power-services/

Genesis writes about his experience with both vBulletin and IP.Board:
http://zack.cncfps.com/post/146-ip-board-vs-vbulletin/

Zocker-Foren writes about his experience switching:
http://community.invisionpower.com/topic/308731-my-5-cents-for-switching-to-ips-from-jelsoft-or-internet-brands/

Bob Schwarz also writes up a converting guide:
http://bobschwarz.com/howto-converting-from-vbulletin-to-ip-board

A topic containing links to recently switched sites:
http://community.invisionpower.com/topic/308385-latest-vb-to-ipb-converts-list/

A topic containing many different viewpoints of switching:
http://community.invisionpower.com/topic/304977-ex-vb-users-how-you-finding-ipb/

A list of “FAQs” written to help vBulletin users adjust:
http://community.invisionpower.com/topic/296787-vbulletin-owners-handy-faqs/

Please let me know if you find any more resources or topics and I’ll update the list. Thank you to everyone who has left feedback recently. We truly appreciate it.

(Updated 16th April with new links)

I see a lot of questions centred around social networking sites like Twitter and Facebook and how it will affect forums. I also see a lot of people saying that we should focus on social networking for IP.Board to stay competitive. This crops up every few days. It’s regular enough for me to try and encapsulate my thoughts in a single easy-to-link-to blog entry.

Before I get into the real meat of the debate, let’s first take a look at social networking sites like Twitter and Facebook.

You’d be a fool to ignore the speed at which these sites have grown in popularity. I joined Facebook several years ago before the boom. Back then it was very US-centric and was literally a profile page with a few tools to communicate to other Facebook users. Twitter started life many years ago as “Twittr”; a simple service to allow remotely scattered developers working for a single company to keep up-to-date. Both of these sites have grown rapidly and evolved into hugely influential websites boasting trillions of page views and millions of users.

So, it’s natural to point to these sites and ask “Why can’t I have that?”.

The reason you can’t replicate Facebook on your own site is that forums are little islands of content. Your site is in a great and vast sea with many other islands all competing for the same tourism. Facebook and Twitter is a giant metropolis of users generating user-focused content. These users are well connected with new friends just a short click away.

The humble forum hasn’t changed much over the past decade. Sure, they look a bit cooler. They have a few more widgets and offer more interactivity but essentially they are the same as when I started hacking up BoardMaster ten long years ago. Back in the dark days of the internet forums were ‘bulletin boards’. Very simple programs in which you “logged on” and left a message. This evolved along with “listserv” another simple program to consolidate email conversations into a threaded discussion. The only real revolution came when Infopop (now amusingly named ‘Groupee’) created the flat view board that we’re all familiar with now.

The first question we should ask is why hasn’t the core functionality changed?

The answer is quite simple. The way we interact with forums hasn’t changed. Forums are content-centric by nature. This is a very important point to make. Very early bulletin boards cared little for the user apart from their email address or name so that one knew who authored the content. Think about the forums you regularly visit. Do you visit them to catch up with your buddies or do you visit them to join in a themed conversation? To get support on a product you own maybe? Or perhaps to catch up with the gossip after last nights X Factor? Whatever your reason, it’s almost certainly because of the content, not the members.

Forums haven’t changed because we still need strongly organised and categorised discussion. Facebook may have “discussion boards” on its group pages but it is a weak system. There have been a few stabs at changing forum software, but in most cases they are not successful because they miss the point.

I don’t wish to single out a single application, but Vanilla springs to mind. At first glance, it’s a nice clean board with minimal clutter that will surely appeal to many. But could you run a support community with that software? Can you imagine if you had five software products, how would you categorise the conversations? With Vanilla you couldn’t. And it’s the same with the Facebook discussion plug-in.

Successful forums have a purpose. I’ve seen hundreds of “My Chat Site” forums appear and vanish as quickly because they offer nothing unique. There are thousands of active forums that focus on a single interest, such as fitness, movies or cars. If these forums continue to market themselves correctly and generate a good deal of unique content each day they will be under no threat from Facebook or Twitter.

So, nothing’s changed in ten years?

Not quite. We, at IPS, have made a subtle change in our verbiage. We sell community building software, not forums. This is not just marketing mumbo-jumbo. It underlines that our software has features and tools to build a community. IP.Board is still content-centric but it has greatly expanded the amount of user-centric functionality. We have extended profiles, such as the user-photos, the about-me box, as well as blogs and gallery. These tools add value to your members and give them a secondary reason to come back to your island regularly.

So, why can’t I have a slice of Facebook for my Twilight fan site?

Facebook works because it’s a single site. If Facebook was downloadable software that you had to install then it wouldn’t work. You would need to create different log ins for each site and update each status update individually. Quite clearly that’s not going to set the world on fire.
Twitter works because you make a status update and it’s immediately available to millions of people who can click a button and follow me, or reply to me, or RT my tweet. If you had to copy the tweet to your own Twitter site and paste it, or you had to sign up to my Twitter site to reply, it wouldn’t work.
You can distill this into a simple statement: Facebook and Twitter is centred squarely on its members talking about themselves. A bewildering and expansive array of random subjects.

We, at IP.Board, could easily replicate Facebook’s tools and indeed we have started to see a few creep in, like status updates. But no matter how many “social networking” tools we add, I’m not going to join a Twilight Fan site just to update my status so I can tell its users about my day. Why would I? A Twilight Fan site is full of Twilight fans talking about Twilight. I have no interest in that, and they surely have no interest in me.

I’m sure many Twilight fans are interested in PHP coding, but you wouldn’t add a PHP coding forum to a Twilight fan site and expect it to generate hundreds of new members.

But Facebook is killing me and stealing all my users!

I don’t wish to be obtuse, but if Facebook really is stealing your users, then you need to take a good hard look at your forum and its place in the world. If you don’t have a strong theme or compelling content then your users won’t have a reason to come back and the few friendships that your users develop on your forum will be moved onto Facebook because Facebook is a much better at developing online friendships.

Take a look at any popular site. How about Idol Forums; a forum for American Idol fans. Could you run that 21,000,000 post community from Facebook or Twitter and have it continue to thrive? Of course not.

So you’re saying that IP.Board will eschew social networking as if its some kind of pariah?

Not at all. This is the problem with stating your point of view, it’s instantly assumed that you oppose the other. This is not true. I see value in adding secondary reasons to get your members to come back. Whether that’s to check their personal conversations, or to write up their blogs, or to add their holiday snaps to their gallery. This is what makes your forum a community.

IP.Board 3 already uses Facebook Connect to allow you to syphon off a good slice of Facebook traffic into your community. Don’t expect people to join up just to chat. But if you have a unique reason to visit, people will. Especially as you can effectively log right into the board with your Facebook account.

You can use Facebook and Twitter to generate traffic to your site. We have an official twitter account and an official Facebook page. We use both of these mediums to drive traffic back to our site.

Keep marketing yourself well, compliment your site with social networking, keep your members happy and generating good content and you will continue to thrive.

I’ll leave you with this final thought, Jerry Springer style: If social networking is an unstoppable juggernaut that will devour the forum format then why have forward thinking companies such as Vodafone and O’Reilly just commissioned new communities built with IP.Board?

My apologies for the overly verbose title of this blog entry. But it’s true. Embracing PHP 5 will make you a better programmer. At least, it has for me.

This minor epiphany revealed itself during yesterday’s Captcha Crisis over at IPS HeadQuarters. In a nut shell, some naughty spammer defeated our CAPTCHA and registered thousands of member accounts across hundreds of IP.Boards.

We had to react fast and release an update that not only fixes our CAPTCHA but also integrated reCAPTCHA which Brandon had already done for IP.Board 3.0.0.

Now, I’ve had my head stuck in IP.Board 3.0.0 since February. We made the decision to use PHP 5 so that we can take advantage of all the new “stuff” such as improved XML handling, public/private/protected methods and properties and magic methods to name a few. I started from scratch and wrote a brand new framework from the ground up using several PHP 5 tricks along the way. In short, it’s the classic MCV pattern using static utility classes and a singleton registery. I’ve blogged about it here although that’s a touch out-of-date but still fairly representative of the new framework.

So. With many customers asking us for a fix, the pressure was on. Josh, Brandon and I down-tooled and went to work on IP.Board 2.3.6. And what a minor shock that was! After nearly 8 months of using the new framework, it seemed backward to use $this->ipsclass for everything. Worse, I was limited to using PHP 4. Worse still was that all the captcha calls were de-centralized. Ouch.

Captcha code was copied through many files. This is a natural progression for stable code that gets developed over time. You start off with the captcha in one place. You then want to add it elsewhere, so you copy the code and paste it in place. Rinse and repeat. You do this because there is a real fear of changing too much code for minor releases. Even though you know it’s bad.

I decided to write a micro-framework to handle all captcha challenges; to centralize it into one public facing class which calls on little plug-in classes which provide the functionality. Performing this routine task is when it I discovered just how much better PHP 5 is.

Without the ability to set methods and properties to private, the code seemed harder to departmentalize. Without magic methods to offload method requests, I had to make do with pointless functions to do the same. Without the ability to chain functions together, I had to fudge something that does the same job. Any desire to write nice and tight code goes out of the window with PHP 4. It doesn’t try very hard to do things properly, so you don’t.

Once the mini-framework was complete, I set about updating IP.Board 3.0.0 to use the same methods. Thankfully, we had already decentralized CAPTCHA creation to a single class. The ability to drop in new plugins and have new CAPTCHA methods seemed useful, so I re-wrote the framework for PHP 5 and it was much more pleasurable experience!

To compare, here’s the mini-framework in PHP 4:

/**
	* Constructor bah to PHP 4
	*
	* @param	object		IPSClass object
	* @param	string		Captcha plug-in to use
	*/
	function class_captcha( $ipsclass, $plugin )
	{
		$this->ipsclass =& $ipsclass;
		$plugin         = $this->ipsclass->txt_alphanumerical_clean( $plugin );
		
		if ( ! file_exists( KERNEL_PATH . 'class_captcha_plugin/' . $plugin . '.php' ) )
		{
			$plugin = 'default';
		}
		
		require_once( KERNEL_PATH . 'class_captcha_plugin/' . $plugin . '.php' );
		$this->_plugInClass = new captchaPlugIn( $ipsclass );
	}
	
	/**
	* Returns template bit
	*
	* @return string	HTML Template bit
	*/
	function getTemplate()
	{
		return $this->_plugInClass->getTemplate();
	}

	/**
	* Validate challenge
	*
	* @return	boolean
	* @since	1.0
	*/

	function validate()
	{
		return $this->_plugInClass->validate();
	}

	/**
	* Fetch Plug In Class Handle
	*
	* If you need it...
	*/
	function fetchPlugInClassHandle()
	{
		return $this->_plugInClass;
	}

And here’s the same functionality, but in PHP 5:

/**
	* Constructor
	*/
	function __construct( ipsRegistry $registry )
	{
		$this->registry = $registry;
		$this->DB       = $this->registry->DB();
		$this->settings = $this->registry->settings();
		$this->request  = $this->registry->request();
		$this->lang     = $this->registry->getClass('class_localization');
		$this->member   = $this->registry->member();
		
		$plugin = $this->settings['bot_antispam_type'];
		
		if ( ! file_exists( IPS_KERNEL_PATH . 'classCaptchaPlugin/' . $plugin . '.php' ) )
		{
			$plugin = 'default';
		}
	
		require_once( IPS_KERNEL_PATH . 'classCaptchaPlugin/' . $plugin . '.php' );
		$this->_plugInClass = new captchaPlugIn( $registry );
	}
	
	/**
	* Magic Call method
	*
	* @param	string	Method Name
	* @param	mixed	Method arguments
	* @return   mixed
	*/
	public function __call( $method, $arguments )
	{
		if ( method_exists( $this->_plugInClass, $method ) )
		{
			return $this->_plugInClass->$method( $arguments );
		}
		else
		{
			trigger_error( $method . " does not exist", E_USER_ERROR );
		}
	}
	
	/**
	* Magic __get method
	*
	* @access	public
	* @param	mixed
	* @return	mixed
	*/
	public function __get( $name )
	{
		if ( property_exists( $this->_plugInClass, $name ) )
		{
			return $this->_plugInClass->$name;
		}
		else
		{
			trigger_error( $name . " does not exist", E_USER_ERROR );
		}
	}

Now, isn’t that much nicer!

Take advantage of all PHP 5 offers and your code will improve. Just looking at the difference between IP.Board 2.3′s and IP.Board 3.0.0 proves that PHP 5 has helped me become a much better programmer.

Originally posted at IPS:
One of the biggest discussions we had during Invision Power Board 3.0′s planning was whether or not to drop support for PHP 4 and require a minimum of PHP 5. The advantages of using only PHP 5 were numerous and we really felt like we could increase security and efficiency by taking advantage of the new PHP 5 features. This decision became much easier when we learned that PHP 4 was no longer being developed.

To really see the benefit of using PHP 5, one must first consider how Invision Power Board’s new framework is made possible by PHP 5.

Although Invision Power Board 1 and 2 were loosely based on the ‘front controller’ design pattern, it had no real framework to hang the code on. The closest it had to one was the ‘ipsclass’ super-class.

‘ipsclass’ was a convenient method of transporting various classes and functions around Invision Power Board. Convenient, but not ideal. One had to pass this ‘super-class’ from class to class forcing PHP 4 to use a reference (and being severely punished when forgetting!). This super-class contained almost all the ‘core’ functionality of Invision Power Board. Member, input and database objects were attached along with numerous other classes and functions. None of which was ordered in any logical format.

We have recoded Invision Power Board 3.0′s framework from the ground up. We have done away with the ‘ipsclass’ super-class and employed the ‘Controller -> Command -> View’ pattern. This allows us to quickly add new code and to allow fast refactoring of our existing code. This pattern is built upon the ‘IPS Registry’. This is a singleton class which maintains interfaces to several other registry objects (database, request, settings and member). Each of these objects maintains a clear place within the registry. This allows us to pass core data through the different levels of our pattern. Other functions from ‘ipsclass’ are moved into singtons: “IPSLib”; disparate functions that do not belong elsewhere, “IPSText”; functions for parsing and cleaning text, “IPSCookie”; functions to handle cookie management and “IPSMember”; functions that deal with loading, saving and parsing members. This offers a clear structure with clear boundries for each singleton class. Being singletons, you do not need to pass or reference the class in other files.

Here’s an example:

IPB 2.3 Code
print $this->ipsclass->input['name'];
$value = $this->ipsclass->settings['board_name']
$id = $this->ipsclass->member['id'];
$this->ipsclass->input['f'] = 2;

print $this->ipsclass->get_cookie('foo');
$text = $this->ipsclass->txt_alphanumerical_clean( $text );
print $this->ipsclass->class_forums->build_info();

IPB 3.0 Code
print $this->request->getField('name');
$value = $this->settings->getSetting('board_name');
$id = $this->member->getProperty('member_id');
$this->request->setField( 'f', 2 );

print IPSCookie::get('foo');
$text = IPSText::alphanumerical_clean( $text );
print $this->registry->getClass('class_forums')->build_info();

It’s worth noting that we have also applied the ArrayAccess interface to the registry, so you may access them like so:
print $this->request['name'];
$this->settings['board_name'];

Although the code examples use $this->request, $this->member, etc, these are set up in a constructor. You would pass the IPS Registry singleton into the class. Here’s a typical constructor:
function __construct( ipsRegistry $registry )
{
$this->registry = $registry;
$this->member = $registry->member();
$this->request = $registry->request();
$this->settings = $registry->settings();
$this->DB = $registry->DB();
}

You could also access the ipsRegistry class directly, although this is strongly discouraged:
[code]print ipsRegistry::instance()->request()->getField('name');[/code]
PHP 5 offers a much better OOP (object orientated programming) environment where references are assigned automatically. You can also chain along functions, which we make great use of. This allows us to do some neat trickery, like so:

IPB 2.3 Code
$this->ipsclass->load_template('skin_boards');
print $this->ipsclass->compiled_templates['skin_boards']->board_index( $data );

IPB 3.0 Code
print $this->registry->getClass('output')->getTemplate('boards')->board_index($data);

You’ll note that you no longer have to implicitly load the template anymore. This is handled within the ‘getTemplate’ function if it’s not already loaded. This object is then returned for use to chain onto ‘board_index()’. This simple adjustment of code makes for less manual code and less room for error.

We are also making great use of PHP 5 abstract classes and interfaces to define extensible classes. This will make it much easier and clearer for others writing their own additions to Invision Power Board. Having a clear interface to work with will reduce errors in development and formalize how you may access Invision Power Boards class structures.

The ‘controller -> command’ structure is built so that you may add new modules and sections dynamically without the need to change a single line of code elsewhere in the script. Modification authors can just drop in new folders and Invision Power Board will run them when called correctly via a URL. The controller makes use of variables in a URL and safely loads a command file if a matching command file is located. For example: “appcomponent=core&module=global&section=login” is mapped to “applications/core/modules_public/global/login.php”. We make use of the Reflection class functions to ensure that any potential command file is a sub-class of the controller to prevent the risk of tampering.

We’ve barely scratched the surface, but it’s clear that Invision Power Board 3′s framework is very powerful and code-efficient. This is only made possible by the advancements in PHP 5 that we’ve taken full advantage of.

I got this via Josh and I think it’s pretty cool.

One of our customers, TelevisionWithoutPity.com was recently mentioned in a My Name is Earl episode.

Television Without Pity has been lucky enough to have its fair share of “shout-outs” and references from TV shows but the one on this week’s My Name is Earl really takes the cake.

The writing staff really planned ahead on this one. The TWoP user “whojackie” — who has been a member on the TWoP forums since 2005 — appeared as a character on the show and made a reference to the posters on the TWoP forums. That alone would be cool enough but that’s not the whole story here.

Read the full story here.

Well, what a month.

It seems that just about every hacking group under the sun has been having a pop at Invision Power Board over the last few months.

I remember back in the good old days an email was sent to you informing of any potential vulnerability before it was made public allowing you to fix the problem and send out patches to your customers and users. Now that’s extremely rare and more often than not the exploit is automated via a perl or PHP script which is then distributed to all the underground hacking groups which is posted on their forums for any moronic script kiddie to download and take down soccor mom boards for their own amusement.

With the risk of sounding like a whiny computer nerd, it’s tough being a web programmer these days. The dangerous balance of features versus security is very tough to maintain. A small mistake in your regex can potentially allow shell access to your server and a badly formed SQL query can allow your admin sessions to be taken. We’re seeing stuff that simply wasn’t possible a few years back thanks to the changes and developments in PHP and MySQL. “UNION SELECT” allows queries to be joined making a missing INTVAL() another notch on a hackers mouse cord.

IPB has become a very high profile target. Our customers include some of the biggest brands in the world (AMD, Sony, EMI, Warner Bros, etc) so it’s an obvious target for hackers. Also, our code is sold as readable source and not compiled which allows everyone to see the inner workings and work out possible weaknesses.

Of course, the responsibility lays firmly at the feet of the developers
writing the code. It’s our job to make hacker’s lives as difficult as
possible and with that in mind, we’ve made some huge changes to the IPB
2.2.0 codebase. I don’t want to say too much other than every single
exploit type that IPB has suffered with recently will no longer be
possible. These changes have been made at the very core of the program so we’re not simply papering over the cracks.

Mac Format (UK) magazine reviewed Invision Power Board 2.1.5 for their June ’06 issue and awards it 4.5 stars (out of 5).

There are several features that really make Invision Power Board 2 stand out from other pre-built forums which you’ll appreciate if problems occur. People may start leaving unwanted or libellous posts, which can lead the discussion away from the original subject or get you, as the administrator, in trouble. This is where the protective administrative features of the Invision Power Board win out over the bare bones forums every time.

Scanned Article (400k JPEG)

So far this week I’ve managed a little bit of everything.

The biggest achievement being adding the IP.Converge installer. Rikki designed and Josh wrote a fairly generic IPS installer framework which I’ve tweaked for IP.Converge. It’s a really nice system that will be used for IPB and IPD to give a familiar look and feel to our products.

I’ve adjusted it so that most of the database population is done via XML files to reduce the amount of “raw” SQL commands in an insert.php file. Manual inserts can be tricky when database schematics change, etc. IP.Converge only has one such manual insert SQL command which makes things much easier to maintain.

IPB 2.2 continues nicely. IP.Converge integration is totally finished and the new ACP in place. IP.Dynamic rolls on well, too. I’ve added a few “system” type tools to make maintenance easier. IP.Dynamic has certain ‘system’ pages (log in form, registration form, etc) and these can now be updated from a single XML file.

Keep an eye out for some announcements next week.

IP.Converge Installer

Invision Power Board (IPB) 2.2 has been in spec form for a few months. We paused IPB 2.2 when we worked on IP.Converge. This wasn’t done for lack of manpower – quite contrary, we have four full time developers and two part time developers – it was done so that we could see how much needed to be changed to enabled IP.Converge.

Now that IP.Converge is due to go into beta testing stages this week, IPB 2.2 development has continued. Naturally, it’s already IP.Converge-ready and the log in modules framework has been extended to allow IP.Converve to be used without the need for special IPB-Converge hacks which makes the code nice and clean.

The first thing I wanted to do is update the IPB 2.2 ACP to use the new IPS style (Nexus, Dynamic, Converge). Although we don’t intended to radically change the front-end skin, we felt the ACP skin needed to be updated so that our products retain some continuity.

Here’s a screenshot of the IPB 2.2 ACP as it stands today.

Expect more IPB 2.2 news over the coming weeks.

So, the final piece of the IPB 2.1.0 puzzle has been dropped into place: the portal overhaul.

There are two major changes. One being that it’s now just another run-time module within the IPB framework. This means that there’s no separate index.php file for it and there’s no way for it to be run as a separate entity. This makes IPB -> IP.Dynamic integration much easier. For those who don’t wish to run IP.Dynamic but still want a front page in other folder other than their forum’s directory, then the supplied index.php file which contains a simple header redirect to the forum’s installation will suffice.

The other change is the removal of hard-coded features and the introduction of a simple plug-in system. Basically, you can now specifiy special tags which correspond with a particular portal plug in. A portal plug in is a run-time file and a configuration file. This means that blog owners will be able to show recently updated blogs on their portal and gallery owners random images and such – all without touching a line of code. It’s a simple case of “drop in and forget”. Mod authors can write their own modules to add functionality without needing to edit any IPB code.

Hurrah.

acp-portalplugins.jpg