People seem obsessed with captcha these days.

Small web sites that I know couldn’t possibly get more than a few enquiry form submissions a week come looking for it.

I, with 13 years experience of the Internet and decent eyesight have to repeatedly re-attempt registration on websites where I want to do scary things like buy products.

Try signing up for a windows live account. Only a blind person can do it at the first attempt. Not because they can hear the audio (their hearing is many factors better than the sighted, but not that good), no, they can deal with captcha easily because any Internet literate person with sight difficulties are aware of all the tools and plugins that can defeat captcha easily.

In no particular order, these are the reasons I really, really do not want to put captcha on your website:

• You don’t need it. Have you had more than 1 spam submission in the last 2 weeks? Oh I see, all the OTHER sites have it. Like what, Google? Microsoft? Ebay? I admire your self confidence, but I’m not sure your site or service is quite there yet.
• How dare you put the onus on the person you want most to interact with you: a potential customer, collaborator or Internet stalker, and make them jump through an extra hoop simply to register or contact you. Do shops take fingerprints at their doors lest a shoplifter gain entry?
• It is lazy to use captcha. If you really have a problem with spammy signups, contact form submissions etc, a bit of imagination on the part of you and your developer can solve this problem without sticking it to the visitor. Email verification. Spam Filtering. Bad Behaviour. Akismet. It is your problem, so put a bit of effort in.

I’m delighted that I have my first SilverStripe website under my belt that I developed from start to finish. I find it quite frustrating these days that I only get to do bits and pieces of websites, add modules, modify code etc – seems I only ever get asked to the hard bits! The same holds true for SilverStripe: I have been working with it for several months now, developed modules, modified sites and other odd jobs, but never a complete site.

But at least all the bugs in Cashtrack.co.nz are all 100% mine! I worked with the very talented ladies of Decisive Flow on this project: they provided the fantastic design of the site, and I tried not to ruin it too much as I combined it with the Silverstripe development

Cashtrack is a pretty simple website (hence my ability to do it on my own!?), it lets New Zealanders enter the serial number of their note and little about where they picked it up etc. As the database grows, I think it will become a really interesting site that can might go in directions we haven’t thought about before.

I’m already thinking about some of the reports we could run: Where in New Zealand do people have the most $100 notes? What dollar amount has the site tracked so far, etc. 

We stuck with the philosophy of keep it simple at the start and adapt the site as required over time. I think it is the best policy for a site like this as it lets the site direction be guided by how users interact with it.

So best of luck to Rupert with the site. I certainly enjoyed doing the web development with SilverStripe and the development framework, Sapphire.

Almost finished my next big SilverStripe project too!

Oh dear, SilverStripe 2.3.1+ now has an updated meta tag function that has a “generator” meta tag which includes detailed version numbers of the CMS. Eg for version 2.3.1, it has the text: “SilverStripe 2.3.1 – http://www.silverstripe.com”. Take a look here as to why I think this is a bad idea.

This is a real pity, and not something I want to have in a production website. SilverStripe is a great CMS and development framework and deserves praise (as does the web development company behind it, SilverStripe), but not right down to the release number!

Removing the generator tag is pretty straightforward:

1. Open the Page.ss for your theme. Eg for blackcandy, open /themes/blackcandy/templates/Page.ss
2. Remove this function call: $MetaTags(false) (could be $MetaTags(true) either)
3. This prevents the generator tag from being output, but it stops a few other meta tags too, so I suggest you add the following to your Page.ss in the <head> section:
   <title><% if MetaTitle %>$MetaTitle <% else %>$Title <% end_if %>- MyWebSiteName</title>
<% if MetaKeywords %><meta name="keywords" http-equiv="keywords" content="$MetaKeywords" /><% end_if %>
<% if MetaDescription %><meta name="description" http-equiv="description" content="$MetaDescription" /><% end_if %>
<meta name="generator" http-equiv="generator" content="SilverStripe - http://www.silverstripe.com" />

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en"/>

4. Save your file and upload if necessary. Once you flush the cache, your should see the changes

Now you might notice that I did slightly more than just meta tags there: I also updated the <title> tag. The $MetaTags function call I removed can output a title tag if $MetaTags(true) rather than false is set and you have a meta title set for your page in addition to the standard title.

This is a good idea for some pages. For example, a page on a site I was recently working on was called “Home”. This was fine for the navigation label and actual on page title, but “Home – MyWebsiteName” does not look good for a window title or in google search results, so we used the meta title to set something which only appears in the meta data and not on the actual page, which was more descriptive and useful.

You might also notice I did not completely remove the generator tag. Well I do want to show my support for SilverStripe so in this particular instance I have just removed any mention of version numbers. At least you now have control over this text.

Some caveats though: my code above replaces what the MetaTags function currently does, but this may change in future so that were additional functionality added to the function, you might be missing out. It also gathers data such as the language and content-type automatically which you need to set manually in my code (if you need to change it).

I will blog again on the MetaTags function if it does change. A perfect reason for subscribing to my RSS feed!

Ray Kerr of The Personal Tagz Company has been producing personalised id tags for several years now. As well as your standard id tagz, The Personal Tagz Company also produces Medical Tagz, Property id tags (for luggage and other expensive items) and you can even put them on your kids.

As well as allowing engraving essential information such as medical conditions, allergies and next of kin information, The Personal Tagz Company has a unique web based system (developed by Cupla Web of course) which allows the owner to store additional information online.

A unique Tagz ID number and the web address on the tag will allow emergency personnel to access detailed medical history or, in the case of a lost pet or luggage item, allow the return of that item via The Personal Tagz Company web site.

Ray has just returned from the Middle East where he was involved in the development of a new airport (he has many talents). During this time, ordering of new Tagz was not available, so the web site is now being dusted off and put back online.

It will be interesting to track the progress of the website over the next few months as it tries to build up it’s customer base once more after a break of almost 12 months.

None of the websites I have custom coded from scratch have ever been hacked. I’m not saying I’m the world’s best web developer, I will assume my readership is smart enough to draw that inference for themselves!

On the other hand, several sites that I have worked on that used “off the shelf” type programs for CMS or e-commerce have run into problems of late. It stands to reason that if enough people use and abuse a product they will eventually find flaws and security holes in it. In every case, the security exploits had been known about for quite a while and patches/upgrades available .

So why weren’t things patched? Well, the reasons for not patching up mainly fell into two areas:

1. There was no longer a technical resource available to perform the required actions
2. The site had custom modifications that prevented a straightforward patch/upgrade

Now as a professional web developer I can’t really do much about it if a client doesn’t want to pay me or someone else to keep the site updated and patched. I’m unlikely to be overly pro-active about getting in touch with customers from a few years ago that might need to upgrade when a particular security flaw is uncovered, but I would drop them a mail if I thought it affected them.

I can understand a customer’s reluctance to engage me on an ongoing basis or even to bring me back in every year or so to perform updates. Most of the projects I do are brought to a stage where the site or web application can be managed and operated by non-technical users, the idea being that the customer stumps up a higher up front cost for a system that doesn’t require regular interventions and updates from a techie, thus saving them money in the long run. I think though, for my part I will have to flag the necessity of security updates to clients outside of any other ongoing maintenance/support contracts which they may or may not want.

Most of the off the shelf systems such as Joomla!, Mambo or X-Cart (which I use for some e-commerce projects ) have very easy patch/upgrade systems that would even allow a non-techie with a bit of bravado (and hopefully a database backup!) to perform the update.

This assumes however, that the core code and functions of the website application remain intact, and this is not always the case. The customer might require an extra piece of functionality that is not currently present and must be custom coded. In this case, the preference would be to develop some sort of module or plug in that stands outside of the core code, allowing a clean upgrade path. There is no guarantee your own custom code will still work once the update has been run, but in most cases it should be straightforward enough to do, and at least the main body of code has been updated without much trouble.

In instances where there have been modifications to the core code, the task becomes more complex. The developer then needs to see what the upgrade/patch is changing, and then manually apply the code updates/patches using some sort of text file comparison/merging tool. In short a bit of a nightmare!

There are often very good reasons at the time of development for modification of core code in this manner. It isn’t always possible to code add on functions as separate code or indeed source a program that does everything you want, exactly as you want it to, and if the customer has a genuine requirement for a particular feature, then who am I to argue?

I might not argue, but I should underline the seriousness of breaking the upgrade path to a product. It really adds significant costs to future upgrades which in turn might have the consequence of necessary updates and upgrades being put on the long finger.

It isn’t always the customer though. Sometimes the web developer can be lazy and simply lash something in any old way without worrying too much about how it might affect things in a years time when an upgrade is needed. After all, he or she will have retired to a non-extradition Caribbean island by then. As a developer it is important for me to ensure a clean path to future updates/upgrades for web applications wherever possible.
If your site is running an off the shelf web application, it is important that you make yourself aware of any security updates and alerts that come from the developers of the application. Even if it is just to check that your techie is applying the necessary updates, it is an important step. Ultimately it won’t be the guy who did the site 3 years ago that suffers most if your site is hacked using a year old exploit…