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?

If you haven’t already, check out our forthcoming Community Content System: an easy way to add pages to your website.

The core of the CCS application centers around allowing you to create pages for your website. The way you create pages and the types of pages you create will be specific to your site, however the process is the same. One administrator may want to build the full front of their website using CCS, while another administrator may want to add some pages within the forums that are not there by default. Both scenarios can be covered by CCS.

More information available here. Check out the video to your right. Those dulcet tones belong to Charles.

I could be forgiven for getting a sense of deja-vu at the forthcoming ‘final’ release of IP.Board 3.0.0. It’s a few months short of ten years since I released an alpha of Ikonboard and since then I’ve been in this position many times.

A ‘final’ release of a new major version is an oxymoron.
IP.Board 3.0.0 is no exception. The trouble is that this is not immediately obvious to many people. A fair number of people see a ‘final’ (sometimes called ‘gold’ in other circles) as a stamp of assuredness and completeness; a final product without any concessions such as bugs.

IP.Board 3 is a dramatic change change from the 2.3 codebase. This truly is a major upgrade. So much has changed, there’s virtually not a line of code left intact from 2.3.6. The core framework has changed for the better so much that is almost unrecognizable from IP.Board 2.

That gives us a lot of untested code in a lot of untested scenarios. We have undertaken a very long period of beta testing. Far longer than we had anticipated but we feel that the end justifies the means. We have a very stable product that only has relatively minor issues. Not including a hasty fix made to the bulk mailer 20 minutes before we released RC 2. That aside, the bugs we’ve fixed are mostly trivial (language missing, quirky browser bugs, etc) or esoteric (character set encoding issues, safe mode issues, etc).

However, no amount of beta testing will truly free a product of bugs. Especially one so comprehensively new as IP.Board 3.0.0. This is where the confusion is born. It is inevitable that ‘final’ will still contain some issues. They will be relatively minor and impact few but they will still be there. This shouldn’t surprise as this is the first release of our new software but it does catch a few people out. Both the 1.x and 2.x branches took several releases before the bug reporting rate slowed up.

Of course, I don’t want to put you off upgrading; quite the contrary. We’re using 3.0.0 RC 2 on our company forums just fine and we experience barely any issues and you should expect the same.

Keep in mind that when 3.0.0 has been released we plan to make small frequent minor releases to address any pertinent issues. This may be bothersome for some, but it really is the best way of deploying fixes quickly.

Whatever you chose, we hope that you enjoy using 3.0.0. It’s been a long journey and we thank you for sharing it with us.

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.

.. and the wait is over!

If you’ve not already seen this, go see it now!

I spent the greater half of last week tearing out clumps of hair in sheer frustration over an annoying bug in Safari.

It wasn’t the kind of bug that you could really code around. I can’t get into specifics but it was to do with iFrames and javascript. The bug caused a significant problem with how the application I’m working on functions.

This was the beginning of four days of javascript hell. The end result of which is a lot of recoding and a fair amount of patching to get it sort of working. A search on the ‘net revealed that it was a known bug in Apple’s WebKit which has been fixed already in the next version which isn’t due out until the next version of OS X ships.

It transpires that this abomination of a web browser is now being inflicted on Windows users now. I can’t wait to see which bugs show up in Windows that don’t show up in OS X.

I love Apple. I really do. But Safari is a constant thorn in my side and I wish it would go away. I’d love for Apple to stop dicking around with their WebKit and use Gecko instead.

What finished me off is that I’ve had zero problems with IE 7 and my javascript code.

Safari: The Web’s Best Browser? I’ll allow my SVN commit messages tell you what I think:

This follows up from my previous entry where I found a very easy way to set HttpOnly cookies for Internet Explorer 6 (SP1+) without requiring PHP 5.2 or hand-rolling set-cookie routines.

Due to reasons too long to explain here Firefox doesn’t have support for these cookies yet. However, there is a Firefox (well, Gecko) only solution.

The solution requires you to add this simple line of javascript as near to the top of your document as you can.

HTMLDocument.prototype.__defineGetter__("cookie",function (){return null;});

This overwrites the default cookie “getter” function and simply returns “null” when document.cookie is requested.

Unfortunately, it suffers from two major problems.

Firstly, it prevents any cookies from being read by javascript. This is a problem if you have javascript set and get cookies on the fly for dynamic web applications (read Web 2.0). and more fatally it can be undone simply by using:

delete HTMLDocument.prototype.cookie.

For example, if you managed to craft a link like so:

<a href='javascript:alert(document.cookie)'>Click me!</a>

Then you’d get an alert box with “null” thanks to the overridden cookie getter – however, crafting this link:

<a href='javascript:delete HTMLDocument.prototype.cookie; alert(document.cookie)'>Click me!</a>

Then you’d get access to the document.cookie as we’ve just deleted our custom getter.

The first problem is quite easy to overcome. You can set up an array of cookies that you want to ‘hide’ then parse up document.cookie storing the cookie values into an array and simply return the value of the array key when you would otherwise request a cookie.

The second problem is a little more difficult. After toying with it for a little while, I took a rather crude approach. I simply add an onload function that examines the document’s innerHTML and just replace “HTMLDocument.prototype” with a safer version (note, you can’t convert to hex or ascii entities as Firefox runs it just the same). There are two cavaets however.

Firstly, this will only stop “passive” attacks – that is scripting in URLs and images. It won’t stop a <script>..&lt/script> block of code as the script code is executed before the onload function is called. Secondly, as the document’s innerHTML is replaced, all subsequent javascript on the page will stop working. I don’t consider that a major stumbling block as there aren’t many legitimate cases where you’d want someone to post “HTMLDocument.prototype”. If it is a problem, then I suggest you add a line of code in your PHP script to convert this string into something safer before javascript has a chance to see it.

Of course, this isn’t an excuse to stop checking for javascript in URLs and images – but it does provide another barrier a determined hacker must overcome before accessing your cookie information. It’s also not fool proof. There are hundreds of ways to obfuscate javascript code and it’s almost impossible to catch them all. Hopefully when Firefox 2 is out of BETA it’ll support HttpOnly cookies and deprecate this rather crude solution.

Here’s the complete code.

So I had a fun hour this morning.

If you’re unaware, any javascript that’s returned via ajax (XMLHttpRequest) which is embedded in the returned text isn’t executed which is a bit of a problem.

To ‘fix’ this, I wrote a little function in the ajax class that takes the returned text, finds any javascript blocks and eval()s them. The problem is the regex. My first instinct was to write this:

source_code.match( new RegExp( “<script\s+?type=['"]text/javascript['"]>(.+?)</script>”, “i” ) )

However that didn’t work. After some tweaking it seemed that ( .+?) wasn’t matching across newlines. A quick search on the internet informed that RegExp’s dot character doesn’t match across newlines and I should use ([^]+?) instead ([^] being match every character except (none)).

I made the changes and everything snapped into place, so I figured I’d quickly blog about it so that I won’t forget in the future.