System Of An Upload

cms-learning-curve

When considering what Content Management System to deploy today, one question needs to be answered first.

Why not just use WordPress?

WordPress was created to be the software behind the popular blogging service¹, and only a few years ago would have been dismissed as little more than that. It was never conceived as a general-purpose content management system, but designed with the singular goal of getting a person’s words and pictures onto the Internet simply and quickly. The thing is though, that is the core functionality of content management. Do it particularly well, and you’re onto something.

Combine that solid core with the ability to add functionality and you’re really onto something. Though invented for blogging, conversion into a different sort of content management system – say a gallery, a forum, or an e-commerce store – is available through third-party plugins. There is a staggering ecosystem of (the last I checked) nearly 29,000 of these. Consequently WordPress has become the most popular CMS in the world. And not by a margin – almost by an order of magnitude. Sixty percent of all content-managed sites use WordPress, one in five out of the ten million most popular sites on the Web. I’ll give that a second to sink in.

But by the same token, using something so well-accepted feels almost like copping out. We’re students of this technology, we’re assumed to be on the cutting edge. What’s the point in being just part of the crowd? There are innumerable content management systems out there. Many use the same attractive PHP + MySQL open source formula. Others again are based on ASP, Java, Perl. Some are even designed specifically to create online galleries, which is certainly closer to what our client needs than a blog is. But while these are worth looking into, the requirements go well beyond just the presentation of images. There is a great deal of text that needs to be easily and well presented, and a dedicated gallery system might not envisage that. The client also needs to manage membership, promote upcoming events, and automatically archive past ones. We will need something extremely flexible, and WordPress scores highly there.

But it’s not alone. Joomla¹ is also designed to be extended – it seems particularly rich in image galleries – and unlike WordPress it was a general-purpose CMS right from the start. It will have to be on our shortlist, especially as the team has had some experience with it in the past. Perhaps the biggest mark against it is that, with only around 6,000 available extensions – about a fifth of what WordPress offers – it just seems less likely that the functionality to meet our client’s needs will be readily available.

Initially, my instinct was to use Drupal. Also designed from the start to be a universal content management system, this one has put even more emphasis on flexibility. So while with WordPress you can have a usable blog virtually the moment it’s installed, Drupal is at first confusing – all you have is a framework, with few features except basic database and user management. Useful functionality is added by downloading and installing “modules”, over 25,000 of which have been contributed by the community, very comparable to WordPress’s 29,000 plugins.

But while plugins and modules might sound like two ways of describing the same thing, there is an important conceptual difference. WordPress extensions are very much goal-orientated. If you wish for example to add gallery functionality to your site, you compare the galleries available and plug in the one that best suits your needs. Drupal modules are function-oriented. To add a gallery, you consider what additional functions it would actually require – image management, display, cataloguing and captioning for example, possibly also resizing and retouching – and add modules for those functions. You’ve got a huge smorgasbord of features to avail of, what you mix is up to you. Such a level of flexibility is both challenging and exciting. A much more precisely customised result should be possible with Drupal, and this is why it is considered by some to be the best CMS of all. But the learning curve is also infamously steep (see illustration). I have to admit that this is part of the attraction. I’ve built several sites based on WordPress and it presented little challenge; the Drupal one I started over two years ago is still far from finished. It definitely represents the greater learning exercise. But that is not the objective today. Even if the team could become sufficiently skilled with Drupal within the timescale, it seems likely that that time could be better spent.

Plus, with Drupal skills being relatively hard to come by, future site maintenance would inevitably be more difficult. Perhaps a clinching argument in favour of WordPress is that, as by far the most popular CMS in use today, future maintenance and improvement should not be a problem. Indeed as an open source tool with both a strong community and the backing of a commercial interest, WordPress would seem to combine the best of both worlds in terms of support.

I wish we could use all three just to see which came out best, but the postgrad workload is too heavy for that. We should be making our decision shortly. For now though, my money’s on WordPress as the one most likely to deliver the client’s requirements without excessive drama.

____________________________________________________________

¹WordPress the open source blogging software, sometimes also referred to as WordPress.org, should not be confused with WordPress.com, whose business model is the hosting of WordPress-driven websites. Both the software and the hosting service are managed by the Automattic company. An aside: Though basic WordPress.com blogging is free – this site uses it – the feature set would be too limited for our client.
²Actually they style themselves “Joomla!”, but I have a strict policy on companies that expect you to shout their names. This policy being: Shush. 

The Machines That Make The Web

CMScartoon1For our next project, we don’t just make a website. We make a way to make a website. Ya may have noticed the Web has transformed drastically in the last few years. Well OK maybe you haven’t noticed. Transformation is pretty much the norm for the Web. But in a short time there has been a sea-change behind the scenes. Or a scene change beneath the sea. One of those. To be clear, this ain’t your parents’ Web.

Twenty years ago when HTML was new-born, most pages were just text with a few code words (called “tags”) laced through. You could type a page into a computer by hand, upload it to another computer called the web server, and voilà, you had a website. Or more precisely, you had a document sitting on a server. Someone typed the address of your page into their browser, the software on the server sent them a copy of what you uploaded. Done. Things were simpler then.

You can still do this indeed. It’s easier than you will be imagining to create a basic website. What’s considerably harder is making a page someone will actually look at. Constantly-changing, information-rich things like Google search results or Facebook timelines or eBay auctions clearly aren’t waiting around as static documents on a server somewhere. Nor are they being typed up on demand by millions of underpaid interns – though that is an entertaining thought. All such modern sites have one thing in common: a database.

This really means no more than putting your information into tables so it’s logically organised and accessible, but the difference that makes is enormous. Say you’re looking for a particular car, a blue Golf around ten years old, for less than about 2,000 eurodollarpounds. Imagine having to read through the details of hundreds and hundreds of used cars arranged in no particular order. You’d settle for the first one you found. Hell after an hour you’d settle for a burnt orange Daihatsu three-wheeler. But if the info is in a database the computer can do the tedious work for you, instantly winnowing that huge list down to the few that meet your criteria. Most excellent; this sort of thing is why we keep those darn machines around.

And a huge proportion of modern websites also work this way. Instead of sending out static documents on request, new software on the web server takes the visitor’s input, queries the database for relevant information – which could include images and other media as well as text – and pours the results into a template to create a custom page. And that is what it sends back to the visitor – a document that didn’t even exist before they asked for it.

This ‘new software’ on the web server is called a Content Management System, or CMS. You create the templates that dictate how your pages will look, you put the information into the database, but the CMS mixes them together and serves them to your website visitors. Modern ones even give you tools to create those templates and an interface with which to enter your information. A good one is as easy to use as a word processor – like the one I’m writing on here.

A content management system is what we need for the ‘team thesis’ I spoke of. We could make our own one using PHP, a popular language for writing code that runs on web servers, but the objective is not to show off our coding skills. The objective is to deliver a real working solution to a real working client. If we were consultants here, we’d recommend they use an existing CMS, customised for their needs. So that’s exactly what we’ll do for them – choose the best for their needs, and customise it to suit them even better. There is a huge range of great ones available.

The question we face now is, which?

My Web Design Hell

image

You know when you’ve got some news or an idea you’re dying to tell someone, but can find no one who has the faintest idea what you’re on about?

Good.

I’m trying to learn some advanced Web design. Briefly, websites were originally done pretty much like you might lay out a document or design a magazine spread. You put things in their place, they stayed there. The more modern way is to use a ‘content management system’ (CMS). With this you just design the template of your page, then upload your content. The user enters search terms, and a page containing what they want is created for them.

This is obviously a lot more complex, as your website is now essentially a computer program. But there are plenty pre-existing systems you can use. WordPress, the one behind the blog you’re reading, is a fine example.

I’m using the CMS called Drupal because it’s widely said to be the most flexible and capable of all, and if I’m going to the trouble of learning any it might as well be one I can use for other things. But lord, I bit off something chewy. It has that vast sprawling-ness so typical of popular Open Source Software projects, and the learning curve is vertiginous. It’s made out of modules; a core with all the basics built in, then countless others you can add for greater functionality (and complication). I parachute into this jungle with little idea of how to tell a tree from a tiger.

But sometimes things are hard for wholly wrong reasons. I was stuck there for weeks – well, hours spread over weeks – because something really basic didn’t work. You see I want a site I can upload cartoons to, so that people can search through them. But Drupal 7 flatly refuses to display images in search results. Imagine how annoying that would be on eBay. Of course I thought that this was my fault, that I’d just got one of its (many, many) settings wrong. But I discover eventually that it’s a bug. The only solution – or at least the only one simple enough for me to implement – was to add a whole other module that did it right.

So I have solved my first real CMS problem, and went to bed tonight with the basics of my new site actually working. Whereon I find I’m too excited about the damn thing to actually get to sleep.

Thanks for listening.