I get the occasional bit of spam via the comments on this site. However, all have to be authorised by myself so I don’t allow any thorough. I’ve now added reCaptcha to the comments section and added a personal message stating that nothing will be displayed if it’s spam. Never-the-less I still get it. Now, reCaptcha is rather good and I can’t believe they’ve found an automated way of getting around it ( I use it on the BMTG site and it isn’t bypassed). If that’s the case, they’re typing things in manually, surely knowing nothing will come of it.

Yet my contact form never gets any spam. I’ve only recently added any kind of captcha and it’s not as sophisticated as reCaptcha. Is that because it only gets sent to an individual and isn’t potentially displayed on a website?

My favourite, though, is the BMTG site. I have 3 contact forms on the site – a guest book entry (publishes on the site, but only after being approved), customer form (where they can send their details to the membership secretary) and contact form (where they can contact various members of management). Based on what I said initially, you can probably guess that it’s the Guest Book they target. And you’re right.

I have an easy-to-use switch which allows me to turn reCaptcha on and off for each of the forms, and I only have it turned on for the Guest Book. If I turn it off I literally get flooded. Why? What is the point? Nothing gets through and it’s a monumental waste of their time, surely? Because the Captcha in this case is fooling them, it must be an automated method being used – that might explain why no matter what messages I use, the message isn’t getting through.

Having said that, if it is automated, why doesn’t it target the other contact forms?

Earlier this year I made the decision to stop updating the BMTG site as-and-when and more formally as packages. Yesterday I launched the 4th such package – Deoxys.

Unlike some of my other packages which have had more visible changes, this is more “back end”. Having said that, to me, it’s exciting stuff. The site is performing more caching and I’ve completely re-written most of the MySQL – it’s more efficient and protected against SQL injection (I hope).

There’s also detection of MySQL failures – when this happens a message bar appears at the top of each page indicating that a problem is occuring and that the site may be affected. The site pages are then designed to degrade gracefully – in other words, either cope with the lack of database access (easier for some pages) or simply display an appropriate message to indicate that no information is currently unavailable. In the past any database problems have simply lead to the site erroring and generally looking shabby.

Additionally, I’ve added some flags to the back-end database. These indicate either a major problem or that the site is undergoing maintenace – I can then flick these flags on when required and a message will appear on the site. The maintenance is particularly handy to turn on whilst I’m upgrading the site.

Lastly, and one of the few visible changes, I updated the member profiles – they’re a bit plainer than before but I think they work a lot more effectively now, as they’re less “fussy”.

Now I’ve started work on the Eevee package – I’ve already written the maintenance changes (including the width of the pages being increased, whilst still ensuring that a horizontal scrollbar doesn’t appear on 800 pixel wide monitors), but the main changes is to the online shop, which helps to generate some much-needed cash for the society.

Meantime, if you can guess (no looking on Wikipedia!) the naming convention I’m using then… you’re sad. Ok, that makes me sad too. And Catherine Furber, who also knew it.