The BPC dev team site (where this blog and the other interactive apps are located) does not have as much comms bandwidth as the main web site, so we have to be a little circumspect with the comms weight of apps we put here.  The nature of this site is that it hosts our production and experimental apps that face the internet and therefore has highly variable bandwidth consumption and is under a lot of stress.  On the plus side, it gets 24*7 human monitoring because it has to have high availability and is constantly being updated. 

We dropped a second hi-speed link into the dev site a year ago but have retained the slower link as the main comms path as it is 99% reliable, whereas the higher speed link still has emotional problems with the local exchange.  So all up, we need the apps we put here to be as light on comms overhead as possible.

It was quite an issue deciding which way to go.  The riskwiki (using media wiki) running on php and MySQL for about a year or two has proven to be very reliable and reasonably ‘tinker-able’.  As a production language PHP is not my first choice, because like most web languages (JavaScript, PHP, ASP Markup, HTML, DHTML, Java, CSS) it is a syntactic design disaster that begs coding errors.  This is not to pass judgement on these languages from the perspective of performance, versatility, or reliability.  Syntactically PHP is better than most, but still far from perfect.   By syntax we mean the grammar of the language.

On the plus side, PHP is incredibly easy to use, and lends itself to some very neat template based layering decisions and design patterns, works well with HTML/CSS/JavaScript/Ajax based clients (like browsers), gives instant feedback during development and is incredibly cross-platform portable.  So as an open source development language it has some advantages.  Debugging, however, can be a nightmare. 

So when we investigated the blogging options and came across WordPress we were comfortable with it using both PHP and MySQL on the same server as our wiki. 

The previous post discussed our experience in getting the WordPress system to work.  Except for the bug we had to deal with, it was an extremely simple exercise.  If we had not had that issue to address, it would have taken about 30 minutes – if that.   Similarly, setting up the RiskWiki a year or so ago was a fast and simple exercise.

One of the really impressive things about WordPress is the astounding range of quality themes and plug-ins available for it at no cost.  The plug-ins expand the functionality of the WordPress system to be way more than a simple blogging application.  There are plug-ins for e-commerce (turning your WordPress into an online shop, petition management (for lobbyists), content management (for web site control), and even a bulletin board/forum plug in that turns WordPress into – you guessed it – a bulletin board.

So when we turned to the question of what system to use for our forum, naturally we first considered using the WP-Forum (or rather its later cousin) for our bulletin board.  In the end, however we decided that it was best to use an application dedicated to an intended purpose rather than a plug-in that converts a blog engine into a bulletin board, a purpose for which the underlying software is possibly not optimised.  It was a close thing however, and we may yet go back and change to the Forum plug-in for WordPress.

The bulletin board we settled on was MyBB – for no particular reason other than it had a plug in for WordPress (that we aren’t actually using yet) and had a long development history, an apparently vibrant development community and seemed to have a huge range of management capabilities available for it.  Also – critically for us – it runs on PHP 5 and MySQL – so it matched the existing open-source software environments used by our RiskWiki wiki and RiskThink blog platforms.

The installation process was similarly straight forward – except that we had to make a few edits to some of the admin pages similar to the fix for WordPress to ensure the browsers were not caching some of the PHP files.  (I am starting to wonder whether IE has changed the caching model with recent security patches).

Now the tricky bit – we now have 3 systems using PHP and MySQL – all open-source.  Our apps of course use Delphi and MS SQL – which means they are all compiled (not interpreted apps). 

When we just had the two systems – RiskWiki and WordPress the shared environment was 100% reliable.  Now that we have added the third – MyBB we are getting periodic page drops (As you may have noticed). Necessitating the server to step in and restart the offending application.  This is particularly likely to occur when you jump from one to another, rather than going via a static web page.  Assuming there is nothing intrinsically wrong with any of the apps, we are thinking that it is a either a MySQL or PHP problem. 

We have turned on full logging to see if we can trace what is happening and hopefully we will have a solution in a few days. 

More on this to come…

The reality is that our email response system has been so good and the robustness of the applications so high that there simply is not the demand for a bulletin board style help system.  Even though the team.bishopphillips.site has been available for client access, clients have almost universally opted simply to email issues and questions and get a response in a few minutes to a couple of hours.  We sweep the emails every month and add common issues, or issues we think are of public consumption to the FAQ in the riskwiki.  The fact that a traditional layer of support is really just not needed with BPC RiskManager  is difficult to explain to new clients and so we have decided to launch a site.

It is monitored continuously by the BPC Dev team so we should see stuff arriving pretty quickly.  Please remember that it is new and the software is a little experimental so it may have short outages from time to time.  If it is down when you access, try again in a few minutes and it should automatically restart in about 2 minutes.

The RiskWiki (MediaWiki), the Blog (WordPress) and the Forum (MyBB) all use the same underlying technology - PHP and MySQL.  The introduction of the Forum to that set has introduced some instability which we are still working through so periodically one causes the other to fall over.  Everything is on auto restart, so if something is down when you first access it will come back  up in a few minutes.  I am sorry about this, but hopefully over the next week we will find the culprit of the problem and get back to our normal 99.9% system reliability.