A person choosing from two options

Choosing a CMS is definitely a challenge. The landscape for web development moves so fast.

When I started building websites for nfp's eight years ago organisations were facing the challenge of convincing their board or managers why a website was even necessary - usually someone had to die or retire before the attitude in those organisations changed. At the start of the year I had a chat to a CEO whose board still didn't think they needed a website.

Eight years ago (and for some years) it was also a challenge to convince people to even consider an open-source platform - the tides have turned on that trend because technology changes. 

Over the years I've built or been involved in building and supporting a handful of Wordpress websites, over 60 Joomla sites and about 40 Drupal websites. All three definitely have their pros and cons.

At the end of the day a system is only as good as the people that put it together - it's like anything, houses, cars, pinatas - if you make it ugly, it doesn't serve it's purpose, and it's made with cheap, tacky crap, no one is going to like it. 

So this is a blog, and blogs are opinon and experience based, so in my opinon this is how I think the three major CMS' stack up for nfp's.

Wordpress

Wordpress is defintely awesome - Wordpress has opened up the world to easily putting together websites. It's stopped digital agencies from hacking together crappy html sites and has brought web technology to the masses. 

I've set up Wordpress websites for friends and family when they've needed something quick. And I've gotta say, I've been disappointed everytime.

The problem I find with Wordpress is it's theme/template driven - and the way that template has been built dictates the way you put content in to different bits. I built a Wordpress site for a friends business at the start of this year, and when I started writing some documentation I had to spend a bunch of extra time explaining how stuff worked. 

For example with this theme to make the slider work you had to get the article ID from the url go to the add on's area and add the ID to a field. Because this isn't managed in the content area/as a content type they need to remember or consult the documentation every time they want to change it - needless to say they haven't changed the image slider yet. 

Of course I could have found a better image slider that used a content type - but I'm not advising my friend to pay another five hours of development to switch out, configure and restyle an image slider just because the default one is stupid. 

I've seen too many Wordpress sites end in disapointment. 

A few years ago the company I worked for pitched for the development of an organisation promoting science - they went with a local wordpress developer - because I knew and liked these guys my heart sank when I saw their new site. I knew how much functionality and engagement they were aspiring to, but the weight of this aspiration just buckled the site. It was slow, the look and feel was inconsistent, images didn't load and it looked like it had been patched together using a million different plugins. They ended up killing all of their background images so the site is now stark white, all of the colouring that gave context to the different sections removed, and they've been left with a bland, inaccessible website that is so far removed from their vision.

And looking at the site right now, it's full of broken links and content types and functionality such as a members area aren't used. Simply, the site was too big for Wordpress and for a solo developer. And, my guess is it's been crap for that organisation to maintain. 

My other bugbare with Wordpress is that it needs a lot of plugins to get complex functionality working. I'm not involved enough with the community to be able to comment on the code integrity and security standards - but the more stuff in your site the bigger the security risk. You have a site hack due to a plugin vulnerability and you loose user data it's baaaaddd. 

Joomla!

Joomla! was the first CMS I started building in so I definitely have a soft spot for it. I've migrated many sites from 1.5 to 2.5 and one site to 3.5 (the last site I'll ever migrate to 3.5).

Joomla! was the first open source community I became involved with. Coming from a community building background I instantly loved that people came together to collaborate, share ideas and put time and energy into building something for a wider benefit.

Joomla! is a great CMS (although I find the 3.5 interface pretty uggo), and for many years we built great not for profit websites with it. But as a site builder and project manager I saw hours being wasted on trying to build and theme inconsistencies across different components. 

When you have someone managing your website, or it's for your own business it doesn't really matter if things like your administration interface isn't consistent - but it does if your an nfp! 

So, while I always found great Joomla! extensions usable, configurable and functional having to explain to a not for profit customer why the back end of their events calendar or directory operates differently from their content area is a total pain. It makes it difficult for new staff to transition and it means that functionality use ebs and flows - so an organisation may never get the benefit of the system. 

Drupal

It took me a long time to want to make the transition from Joomla! to Drupal - I owed Joomla! so much love - and wouldn't learning another CMS be hard? Isn't Drupal super scarey and hard?

I gotta say I was converted to a fan very quickly.

Drupal has a pretty tight development circle, you want to build something, it has to be done in a "Drupal way" and it has to pass scrutineers. Some people critise this, but your not-for-profit will benefit from a platform that is well maintained and managed.

Drupal is a content construction kit, so it's like lego, you don't open the packet and find things mostly built and plug them in, you get the bits. So if you are going to put them together into something sophisticated, well built, and usable you have to know how to do that.

With Drupal you are relying on the people behind the system as much as the technology. But you should know who's acutually doing your build with any site. 

Who did the agency you paid so much to get your branding and "digitalness" correct on paper get to do the actual site build?? Doesn't matter what the platform is - if your pinata is full of crappy, cheap, bitter lollies it's a disapointment for everyone involved!

Drupal allows for expandability and flexibility in a really structured way. My team saved time theming Drupal sites because despite many different content types there is consistency in how fields are used. Organisations benefit from being able have different content types set up and displayed according to their needs. I could make features and functionality and share them across other websites so development costs are be shared. 

There isn't much you can't do with Drupal. We don't know where the next five years are going to take organisations in terms of web use.

Many organisations are diversifying their income streams and working harder to provide membership benefits within their sites to retain their networks. I've seen organsiations build custom functionality that could have more easily been built in Drupal - from grants management to job application management. 

A problem with Drupal is containing expectation, when you can do so much you need to be clear about what you expect you are getting. I think for many Drupal developers they focus on the technology without enough focus on the people that need to take the site and run with it.

It's not acceptable for sites to be built that organisations can't run and manage - and this means configuring Drupal to be user friendly.

I don't have any problems with configuring Drupal to provide restricted access for organisations - just because you can pull a lego sculpture apart and rebuild it doesn't mean you should. But organisations should never pay someone else to manage their content or everyday site functionality (unless it's a requirement).

You should only need to go back to your developer for new functionality or when they need to perform updates, or some training from time to time to refresh or update new staff - and this is the same with any system no matter which one you choose to meet your needs. 

0 Comments
Jul 4, 2016 By lyndsey

Add new comment