Anatomy of a head-wall interface
I’ve been doing some work on the website for my new co-venture, WhiskySquad – a monthly whisky tasting exercise designed to give enthusiastic amateurs a chance to get their palates around some interesting stuff – and the problem that needed solving in this instance was that of easily setting up a way for people to register their interest in the strictly limited number of spaces for that month.
My initial thought was, “Ah, there are services that do this!” – Meetup.com and Eventbrite.com both provide systems to set up events and have people respond. Both also provide payment gateways, however as you’d expect these both charge for the facility, and one of the core goals in the short term of whiskysquad is to run at an affordable cash-neutral position.
Andy suggested that we just publish each new tasting session on the site as a Post (the site is a very simple WordPress installation), and interested parties email us for that particular month’s session. We then email them back with our bank details, and they transfer the money – once the transfer’s come through then we mark them down as “officially on the list”, and could then potentially edit the Post to reflect how many spare spaces we’ve got.
Being a programmer – as well as a fairly busy & fundamentally disorganised person – I tend to eschew entering into arrangements which are going to involve me keeping a lot of hands-on manual effort from my part, when there’s a possibility of automating some or all of the process. I figured that WordPress, being a fairly mature platform now and widely felt to be a CMS product in its own right, would more than likely have add-ins available to speed me along my way.
After some concerted searching of the calendar plugins available I was quite surprised that Events Manager seemed to go quite a long way to solving the problem. A typically easy installation later, and some need for tweaking became evident.
The problem for me is that the Event Signup form is a web form, so anyone can sign up. It provides no protection against formbots (automated scripts that trawl t’internet and submit forms full of spam details), or nuisance submitters. Many CAPTCHA plugins exist for WordPress, however they only insert/provide CAPTCHA ability for the “standard” WordPress forms: I couldn’t find a way of inserting one into the event form. The obvious solution is therefore to limit it to Registered Users, whereby a person needs to sign up as a site subscriber, then verify that they’ve signed up, and only once they’re logged in will they see the event booking form.
I still want to keep the event notice and some info visible to non-registered people: calendar of upcoming tastings is a selling point/promotional tool, however there is a WordPress plugin that allows you to display part of your form to the public and keep some of it for subscribers – the Hidepost plugin.
After installing & playing with this I became frustrated that the user registration process takes you into site back end rather than front end, and one thing I can’t stand is confusing sites that send you places you don’t want to be. Installing a sidebar-login box solved the problem of being sent off elsewhere in the site upon login, but not on registration – I couldn’t find a way around that, as part of the registration process is filling in your personal details, and then once that’s done you’re directed to the back-end dashboard, where the path back to the front end isn’t necessarily obvious.
It also occurred to me that site-registration is a little old, and in 2010 we’ve got better methods available, such as OAuth. Wordpress doesn’t have a functioning OAuth plugin at the minute though, and by this time I was losing interest in perfection, and just wanting to get the damn thing out there. Standard registrations, it was.
Once you’d registered and then found your way back to the main site it wasn’t too bad, and if you logged in from the sidebar login box in the first place everything worked OK, so that wasn’t a showstopper. However I then got very irritated that you had to type in your name & email address to the event form after having logged in – presumably once a user logs in this information is already accounted for? But how to pre-populate the event form… the Events Manager plugin authors hadn’t provided any means of doing this, and perhaps my search engine skills are lacking, but I couldn’t readily find any way of retrieving these variables, and then working out the escape sequences required to insert them into the form (which itself is inserted into the page layout by way of a “shortcode”).
Aware now that I’d wasted the better part of the day on this, I figured that for simplicity’s sake in the first instance I’d just have a publicly accessible form, and would deal with it further down the line if it became a problem. The next issue though was RSS feeds – we use Feedburner for our page’s RSS feed, as it both increases flexibility for the end user (email subscription as well as RSS), and gives us access to see how many people are reading our feed.
The Events Manager plugin literature plainly states that it stores events in a separate table to WordPress Posts, and I had a horrible feeling this meant that Events would therefore not show up in the RSS feed when published – this turned out to be the case. The literature, however, reliably stated that the plugin produced its own feed. Do you think I could find any indication ANYWHERE of what the address of this feed might be? Could I BOLLOCKS. It’s certainly not included in any obvious documentation/readme files I could see. I managed to dig it out by grepping through the source code, however the problem now came about that I had 2 RSS feeds, and I only wanted one. How best to amalgamate the two, then plug them back in to Feedburner?
Yahoo Pipes! Surely? It’s fairly trivial – as it turns out – to amalgamate multiple RSS feeds and get a resultant output feed from Pipes. I felt it was almost *too* easy, and it turned out I was right. Whilst getting a joint feed was fine, convincing Feedburner to swallow that feed wasn’t going to happen – it kept reporting a 404 error.
Currently I’ve abandoned the RSS feed problem: I’ve decided that in parallel to publishing a date via the event system I’ll also write a News post to say there’s a new event, which will therefore appear in the main RSS feed.
However the problem still stands that it’s possible to submit blank or incomplete booking forms – which is nigh on useless for any sort of website.
So, do I take the code of the Events Manager plugin and develop my own (and try to plumb the myriad depths of the WordPress system – mindful of the fact that WordPress 3.0 is due for release any day now and probably dramatically restructures the entire system), or would it just be easier and a better use of time to publish each new tasting session on the site as a Post, interested parties email us for that particular month’s session, email them back with our bank details, and they transfer the money?
Looking at it, paying for Meetup.com is sounding like an attractive option.