There are a lot of things to worry about when you’re building a website, whether or not the system you’ve chosen to manage content will scale properly shouldn’t be one of them. Most development shops, those I’ve dealt with anyways, have a go-to CMS they sell to their clients because in most cases the salesman isn’t responsible for development. That’s fine 90% of the time but every now and then you run into a project that might have been just a bit easier build in Joomla, or maybe a bit more user friendly if it was Wordpress.
A story about plugins
I’ve seen a lot of really terrible plugins written by a lot of truly terrible developers who have no right to call themselves programmers. Nobody is perfect, but there are no excuses for a lot of the commercial plugins out there.
I built a site once that was essentially an event registration system wrapped in Joomla. It relied on a plugin, whose name I can no longer remember, to provide almost all of the event registration functionality. This would have been fine, but this plugin broke every rule in the book. It followed the MVC design principles mandated by Joomla’s framework, but broke the rules at every possible opportunity. The views were thousands of lines long, functioned as the model, view AND controller, and abused the Joomla framework just because they could (possibly because they didn’t understand what MVC meant). Initially, our development team got together and evaluated a bunch of different event plugins to see if they would match the requirements. None did, due to the rather specific nature of the requirements, but it was decided that we would start building off a product that was already at least half way there (as in, it functioned as an event registration/management system). Most of us believed a completely custom solution would be best because this would be a one off system that had a very specific list of requirements. What should have been a simple project dragged on for over a year as a result (or longer, I left the company before the project launched).
The moral of the story? 3rd party plugins are great for their intended purpose but you really, really have to be careful when you’re choosing them. If a custom solution can be realistically produced within the timeframe, do it.
Drupal hate inbound
Personally, I don’t use or recommend Drupal. I think it’s a complete mess, but it hasn’t really affected me because the only time I’ve ever used it is when I decided to install it on my dev machine to see what it was all about. Nobody seems to be asking for it and that’s just fine with me.
Joomla
Joomla is really good for big data-driven websites and apps. Plugins (modules and components) and themes are easy to develop, the code follows a strict MVC architecture and it receives sufficiently regular security updates. This is a large departure from how things used to be in the Joomla world, but ever since version 1.7 things have been good. It’s strengths lie in the way components display information, which means damn near everything is a list. Lists are boring and, when you have a lot of content, difficult to navigate at times but Joomla is designed to make creating and navigating lists of links (which typically link to content editing pages) easy. The ultimate goal is efficient and effective content management, however it is not the best content creation experience.
As of version 3.0, the backend is designed to be completely responsive (powered by TWBS) and easy to use on mobile devices. Prior to this it was difficult, if not impossible, to use on a phone or tablet unless you used one of the various iOS/Android apps. Inventory systems, advanced event systems, product catalogues, hell even small scale social networks are all really good projects to build on this CMS.
One very big technical plus for Joomla is how it stores configuration data - it’s all in /configuration.php. This is a big deal when it comes to deploying your website on the production server! Deploying Wordpress is a pain in the ass by comparison.
API Documentation and Plugin Directory.
Wordpress
Wordpress is a blog platform that, thanks to an overzealous developer community, became something else entirely. In my opinion it is best used to build blogs, news and other single-to-many (as in single content creator, many consumers) style publishing websites. Small businesses already know how to use it because the interface is so intuitive. Unlike Joomla, the back end interface is designed to make writing posts and creating pages as painless as possible. Content creation is clearly the focus here, it’s second to none. However, because it is so extensible, developers have done the impossible and created frankenstein frameworks that bring a sizable amount of functionality into a platform that really doesn’t know how to handle it. Coding standards are either non-existent or are not enforced and as a result, plugins are typically defining their own internal frameworks to get around the lack of one within Wordpress itself. It’s a fairly simple problem that the project leaders either don’t see as a problem or are unwilling to resolve.
Plugins, widgets and themes are easy to develop, the architecture is generally a mess (there are some efforts to streamline it), but probably the best thing about it is clients already know how to use it (well, not ALL of them, but a lot).
API Documentation and Plugin Directory.
The Lesser CMS’
Static website generators are great at what they do but are intentionally very limited in terms of functionality. This list will change as I evaluate others.
Jekyll
Jekyll isn’t a CMS, but it is pretty great. For simple websites you can knock out in a few hours/days, you want jekyll. Obviously it’s very simple but I re-built this site in 3 hours using jekyll. Jekyll itself is, essentially, a translation service. It takes your blog posts and other post-type data, written in Markdown and spits out folders filled with HTML according to a number of settings (located in _config.yml). It’s actually a Ruby application, but I don’t run ruby on any of the servers I run jekyll on because our projects are mainly PHP-based. If you configure your FTP/repository to push only the _site directory and regenerate the site locally on your dev machine, the only thing that gets pushed is your static HTML content (details here). For my usage, that’s perfect.
If you’re looking for a solution that provides pseudo-dynamic CMS functionality but doesn’t require a database, jekyll is your man.
Plugins are available on Github but you really have to know what you’re looking for. You can write your own if you know Ruby, but I have yet to write one myself so I can’t comment on the extensibility of the system. Documentation is available here.