Updated 16 December, 2010
While my colleagues in IT are reading this post and, with mouths agape, thinking “WHAT, you giving a plug to Open Source CMS?”, I still remain a hardcore champion of Enterprise Content Management (ECM) to suit the right needs and when the right resources and commitment are in place. And so begins my plug for what I found to be a robust, scalable, usable and well-engineered Open Source CMS – WordPress.
Blogs and Wikis have revolutionized Web publishing, paving the way for wider adoption of their publishing tools and instilling simple publishing processes, hence changing the culture in organizations.
The problem is, when faced with the to CMS or not to CMS conundrum, IT managers are presented with the whole gamut of information management solutions (Web, document, digital asset, and so on), all of which promise Content Management. Just take a look at this “list of notable content management systems that are used to organize and facilitate collaborative content creation”, and you will see a variety of Open Source and proprietary solutions, supported technologies, portals, frameworks, and blogging platforms, as well as licensing models.
To quote my good friend and colleague in IT management, Tobias Carlander of World Food Programme, when evaluating and choosing solutions, “there is no silver bullet”. Large organizations, both international public and private companies, often struggle with choosing information systems which can be a part of a heterogeneous IT landscape. And so when evaluating IT solutions, IT managers must consider interoperability, sustainability, and alignment to strategic information and content management objectives among the highest priorities.
The release of the CGIAR Ongoing Research Web site is the result of an effort to both enrich and expand the exchange and reuse of the CGIAR agricultural project information, as well as support new views of agricultural research, as the new CGIAR research agenda unfolds and is put into action.
This effort required migrating the Ongoing Research Web site and editorial system from a Web application framework to a proper CMS in order to:
Customized Editorial Interface: Catalogue Browse/Search
A usable editorial interface (in our case, one where scientists and researchers voluntarily provide project information) can be greatly aided by a usable CMS. Why? Because when customizing/extending beyond the basic blog or Web site, developers can take advantage of libraries and methodologies already in the CMS to deliver usable interfaces to extended functionalities. Here is a good example of a usability testing report done on WordPress 2.7′s Administration (editorial) Interface.
After reading the latest literature on Open Source CMS and having consultations with Open Source CMS experts (thank you to Peter Casier of WFP and mastermind behind Blog Tips) and colleagues, I evaluated and investigated the core of three Open Source Content Management Systems (Drupal version 6.17, WordPress version 3.0, and Plone version 3.3.5) by downloading, installing, and configuring the systems. I looked at each system’s core CMS functions (e.g., managing content and metadata and delivering it on a Web site).
All three systems were easy to install and set-up as a basic CMS.
While Plone is quite beautiful from the pure developer point of view (I will not compare apples and oranges, that is general-purpose languages like java and python to server-side scripting languages like php), it does not really fit our express need to have a multitude of hosting options. Also, Plone appears to be a framework in which one must build or attempt to install combinations of modules and other frameworks for developing the system beyond the basic hierarchical Web site. Also, developing the system beyond the very basics requires a much higher skilled programmer. It is quite similar to the implementation of a portal to manage Web content. It should be mentioned that since my evaluation, Plone 4.0 was released and promises many new and important CMS functionalities.
There are no great differences between WordPress and Drupal with regards to hosting and scalability. But when it comes to user experience, out of the box, WordPress wins hands down. Note that Drupal 7 should correct and/or improve upon many of its challenges with usability.
After the initial evaluation of Drupal and WordPress, in order to make a final decision, I put the systems to the test by putting on my developer hat and building a few of the required functionalities (a migration data loader, invitations to contribute to the system, multi-authorship of projects, and querying projects for display in the interactive map interface).
Both have a large number of hosting providers to choose from (Dreamhost, GoDaddy, Host Gator).
With the advent of version 3, WordPress can no longer be considered just a blogging platform. Version 3 improves on or adds several important CMS functionalities: custom post types (which should be called custom content types), custom taxonomies, and custom menu management. Add this to a system which provides a solid user-centered editorial interface and has the concept of Web publication at its core, and you have the recipe for a sound solution.
I developed the entire back-end and non-visual design front-end customizations of our WordPress CMS to satisfy requirements of the system. This involved migrating content and users from the old system, extending taxonomies by linking them to master data, configuring custom content types, creating new user roles, making information required for publication, making master lists browsable and searchable in the editorial interface, and much more.
I used several plugins from the WordPress community of developers to extend roles and permissions. I also developed two custom plugins to implement business rules for email notifications, required fields, Google Maps and Charts integration, and managing and linking to master data.
I only found one core issue with the system, which I reported on WordPress’ issues tracking system, and to my amazement a few hours later, WordPress core developer Andrew Nacin responded and had a patch ready for testing: they are serious, too.
The problem with WordPress vs. Drupal is that the literature you read comparing the two can be misleading and quickly outdated. So be careful when you read “The best solution is…”, and WordPress is good for blogs and simple sites but Drupal is good for complex Web sites, etc. Technically, either of the two would have been able to fulfill our requirements.
My final thoughts on choosing an Open Source CMS:
Did I make the right choice? Have you recently selected or evaluated a CMS, or are you planning to do so? Please share your experiences and comments below!
All content created by ICT-KM is published under a Creative Commons 3.0 license. You are free to share, republish or remix so long as you attribute ICT-KM clearly as the original source.
Dear god who was your tour guide through drupal? Satan? Did he have you use Drupal 4.7!
You reallllly missed what makes Drupal amazing and far more powerful than WordPress!
Thank you, Jesse. The version I evaluated was Drupal 6.17 (the latest stable at the time), not 4.7! I certainly hope that Drupal 7 really does correct many of its usability shortcomings as it promises!
Really solid write-up. One of the better ones I’ve seen from this perspective, for sure. I think the delineation you drew between WordPress and Drupal were quite fair to both CMSes.
Slight correction though: I had responded with a patch within 50 minutes.
Thanks for the correction, Andrew!
We faced similar choices. We chose WordPress for our nonprofit sister organization,Sitia (sitia.org), and Drupa for our CGNET site (cgnet.com). WordPress is so simple that it is wonderful, yet it is limited. Drupal has soooo many options, but can be a hassle to get it to work right. Bottom line: WordPress if it is simple and will stay simple. Drupal if you might do more complex stuff AND you have a techie oriented person who is willing to learn and manipulate Drupal.
Thank you, Georg, for sharing your experiences! I still maintain that WordPress 3 can handle complex sites, too!
Michael, ok i change my vote! Go for WordPress 3.0! You will save yourself much hassle.
Dear Michael,
Thanks for this post. I guess you will attract comments from people who are using either and their views will be on either side too. However, I believe this kind of debate should also be brought down to the level of the person who is not a technical expert but needs to understand the factors (and functionalities) that the experts consider in making such choices.
Thus, it is good to say that WordPress will be simple to use and yet can also handle complex sites, while Drupal is great for handling multi-site hosting for large organisations with powerful indexing abilities. But, what does that mean to a less technical reader?
I would have liked to see some descriptions of the cases where someone chose to go for CMS A and at what point they decided to change to CMS B, so that we give the newbie decision maker something to work with. I liked what Georg mentioned – giving a context in which both CMS were used.
You may be aware that there is a group, AgriDrupal, that has been discussing the use of Drupal in Agriculture. One of the comments to the group was why AgriDrupal and not AgriWordPress or AgriCMS?
I would like to see the experts providing the newbie with a spectrum of options suited to their needs at different levels of development of their information management processes.
Would this kind of discussion be useful on a larger platform, like the CIARD Content Management group?
Thank you, Krishan. To the non-technical reader, I hope that my post will encourage comments, like Georg’s. I also hope what comes across for all readers is: don’t believe all the hype.
When it comes to the Agri-system flavor, I can understand providing well-supported, standards-based tools (like AgriDrupal) to help provide sustainability to the agricultural community. However, I believe that the real value in this community is the set of standards/methodologies it makes use of: AGRIS AP (metadata standard), AGRIS/CARIS Categorization Schemes, Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). I do hope their use spearheads their application in a broader context, and therefore to other systems, beyond Drupal.
I do believe that the Content Management Task Force (CMTF) is a perfect setting for such discussions, as it promotes information sharing and adoption through the use of standards, and is devoted to open systems and sharing, not a particular software solution.
Dear Krishan,
you raise many issues, that raise as many issues in return. And hopefully the points below will help clarify the overall sense of our case.
1. You say: “I would have liked to see some descriptions of the cases where someone chose to go for CMS A and at what point they decided to change to CMS B, so that we give the newbie decision maker something to work with. ”
Our case unfolds over three phases: when the CMS solution was identified, we were already in the third phase of the project. The first was a simple prototype built with an HTML form, a google spreadsheet and a google map. Then we went for an application framework with a relational database, a custom-built solution, which was what was there for nine months in Beta. Third phase was the move to a CMS. The objectives had changed, the needs had emerged much more clearly: a content management and publishing workflow, enhanced usability, the need to be sustainable within a tight budget (i.e. configuration over customisation) had clearly become priorities from the experience with the Beta.
Bottom line, it’s partly features and partly maintenance/expansion over time that we had to keep in mind in making this choice. The pragmatic approach outlined in the post was part of due diligence in identifying the best fit for the job at hand.
As part of due diligence, our experience suggests not to jump to a solution without getting enough hands-on experience with the cost, effort and benefits of any software solution. Which brings us to the next point.
2. You mention the newbie decision maker: who is this persona you have in mind? Content management is a matter of IT, management and processes. Each one of these factors can be broken down into many more that can hardly be distilled into a 10-easy-step approach. A decision maker, whether a newbie or not, should ensure due diligence, and the posts suggests some critical decision points that they need to go through:
1. clarify your needs;
2. don’t look at features only;
3. don’t believe the hype;
4. get your hands dirty with the solution before making a decision;
5. make provisions for the financial and technical human resources you need to make available to support your decision;
6. go through a prototype-beta- final (or interim?) solution to clarify the needs in point 1.
I believe it’s difficult to generalise when it comes to deciding on a CMS. In our case, we had to consider cost/benefit factors that have been validated through an iterative approach. Is this always the case?
3. It would be very interesting to understand how Drupal was chosen for Agridrupal: What was the case? What were the criteria, priorities and needs that this choice is satisfying? When the issue was raised in the group, what was the final rationale for choosing Drupal over any other CMS? Who is the decision maker for Agridrupal?
It would be great to be able to compare experiences on the basis of specific requirements and contexts.
Hi Antonella, I think this is one of the more objective reviews.
I have had opportunity to develop on both Drupal and WordPress and both are really solid, secure and extensible. Your choice really depends on the needs of the project [complexity of the problem and content management situation].
Drupal is much better at complicated sites and wordpress is better for blogs and general news sites. There are many options in Drupal that can make it heaven or hell for you depending on which end you approach it from. WordPress on the other hand is really easy and rarely goes wrong. Many people have had positive experiences with wordpress – the same cannot be said of drupal. Its many options have not made it an easy technology.
We discussed the same issue at the Drupal conference in August 2010. Why don’t people want to use drupal despite is very advanced features? There was general consensus that it has a steep learning curve.
Drupal is built from the ground up as an enterprise CMS and wordpress as a blogging platform – though its improving. Drupal allows you to configure custom install profiles that bundle modules, design and contexts to an single installation. This allows for drupal versions optimised for specific applications. Agridrupal, pressflow, open atrium are good examples.
However, I, think that it pays to invest time and resources in learning technology and I prefer to get the stronger technology first and have capacity for my/organisation’s ideas and plans. Drupal can do everything that wordpress can do – with less code. WordPress may one day be able to do what drupal can do now.
I really haven’t spent much time in WordPress as I did in Drupal, but upgrading drupal is really a pain in the neck! let’s not talk about custom themes.
I have heard this quite often, Ibrahim, regarding upgrades. I also read similar stories about custom themes. Would be interested to hear the particulars of your experience with custom themes and upgrades in Drupal. Could you share a few?
I don’t find upgrading Drupal to be hard at all. Within a release (D6, D7, etc.) just replace the core files and run the updater. Same goes for modules.
When going between versions (D5 -> D6) the only issue is making sure your non-core modules are compatible with the new version. For modules contributed by the community, you just have to get a new version once its released. For custom modules, you have to do your own work. But that’s just the way it is.
Eric
Michael, when u talk abt usability, u probably mean for a developer… I agree that while Drupal has powerful code, apparently well written, it’s developpers userinterface is bare bone one. Maintenance is a drag….
Hi Peter, thanks. Usability goes for both. WordPress is very strong especially in the contributor/editorial interface (user-centered design), which greatly aids uptake by authors/editors, and is also wonderful to rely on when extending the system to manage different types of content (e.g., I used WP’s standard controls and visualizations to implement catalogue browsing in the editorial interface).
Dear Antonella (and colleagues commenting on this post),
Whenever I read the posts that appear on the ICT-KM blog, I tend to read it from the perspective of someone in the NARS, in some institution, trying to look for guidance on what to do next, or how to convince their Manager that they need to move with the evolving ICT technology. I often forward the posts from the blog to a network of AR&D Information managers in the SADC region (e.g. the latest being the ICT Roadmap), guiding them not to just look at the specifics, but to understand the vision that these experts are now targetting, because we may also have to give these some thoughts soon. Hence my comment, to request that we also illustrate our ‘lessons learnt’.
The debate about which CMS is indeed a prolonged one, but as Antonella reflected, there may not be an easy 10-step linear process to reach that decision. It does look like we have all gone through the iterative process of better understanding our needs, once we realised the potential applications of the tools we started using.
Now, as Antonella mentioned, CM is about IT, management and processes. In large organisations we may have the luxury of having person(s) in each of those positions that creates a critical mass to take the process forward. But how does the one individual (or two if you are lucky) who has been given a title like ‘IT/Information/Documentation Officer or Knowledge Management Officer or an Extension/Research officer attached to an Information Unit’ get started in convincing Management that something has to be done?
I would like to propose that we, as ‘experts’ having had the experience of such processes, start documenting these very same processes and the lessons that seem to emerge, as some form of guidelines for the officers mentioned above to use, especially to make a case for their plans to Management. The current approach in most NARS is that ‘we need to bring in consultants to set up a system for us’ when we all know that most of the time this does not bring about ownership and ability to sustain the reflection required at the level of the institution.
I particularly like the way Antonella’s step 6 says go back to step 1, but with a higher level of awareness. So if the decision about the choice of a CMS is not simple, let’s tell them, that based on our experience, it is mostly a learning by doing process (experiential learning too) and admit that one may have to start with a simple system that enables us to focus on what we would like to do, and as our ambitions get bigger and more complex, we then need to shift to more complex CMS systems. In that way, Management is also aware right from the start that the process may involve starting a cycle a few times, which may seem like repeated expenses for the same thing, but are not.
I would propose to our colleagues from the CGIAR, that in addition to responding to the needs of your scientists and stakeholders located in your Centres, you also see the approach described above as a ‘social responsibility’ that may help the CG System capacitate its partners, i.e. the NARS in embarking on processes and tools that will have synergies and multiplier effects at various levels.
Wow, this feels like my letter to Santa for this year!
On the issue of AgriDrupal, the argument put forward was that it is not [necessarily] an endorsement of Drupal, but an investigation into the scope for collaboration among people in the agricultural sector who are already or about to use Drupal. Thus, there is no reason why there could not also be an Agri-WP group for example. Nevertheless, I personally feel that the spirit of these collaborative efforts should be to bring back the generic principles and methods back to the ‘Content Management Community’ such that users of other CMS can also implement the same techniques using their own CMS (or develop modules that can be tapped from other systems)[Michael seems to share this view].
Therefore, (my last request to Santa) for example, I would see it beneficial for the CG-Map approach to be extended (perhaps under a different module or hosted elsewhere if necessary) to enable other researchers to enter information about projects they are implementing, such that ‘we’ can tap a larger resource base of information generators…
Apologies for the long comment!
Best Regards
Krishan
Thank you for your comments and clarifications. It may sound like a letter to Santa, but you articulate many reasonable points. If there was a “Like” button here, I’d click it on “iterating as part of a learning process” and “being honest with decision makers”. Your final suggestion sounds interesting, and you’ve been an advocate of this for a while. To turn it into something “usable”, this embryonic idea needs quite some thinking in terms of cost-benefit, reusability and applicability. Would you be happy if I put it too in my letter to Santa?
Sure!
…Global Public Goods are not only what we find out through field experiments, it’s also the result of experimentation and reflection: lessons learnt. The latter come out of the process of sharing our knowledge with others and getting new insights on the issue we are addressing.
So, if Santa thinks we left it too late for this year, why not let’s work on discussing the embryonic idea early next year on the ‘CIARD Content Management Community’ Forum – (another of Santa’s gifts)- so that we can all have a wonderful Xmas next year. In fact, we should gather all the letters to Santa from our community…
There’s more our there than drupal and wordpress.
Squiz has just recently launched the squizsuite (squizsuite.net) which provides cms, search, analytics & an integration engine.
It’s all fully supported with auto updates and more out of the box bridges than you can poke a stick at.
http://www.youtube.com/watch?v=8dEnudlbBds
Been a lover of both CMS, simply to said, I prefer WordPress on simpler setting which does not require much customization. Yet when it comes to specific requirement or need more coding I prefer Drupal in term of scalability and customization. For example, it is easier to build bilingual site on Drupal than on WordPress.
I’ve worked with both, and feel the decision may be moderated by these concerns:
1. which do I know best?
2. what is my budget for web development? For maintenance and follow-up development?
3. how large is the WordPress/Drupal web development community in my area?
No matter which CMS you pick, you will need skilled web designers and web developers, and web maintenance. The skill-sets you have inhouse may make the difference.
I was most interested in flexibility in the CMS I suggested for our organization, and felt that Drupal provided the most flexible options. I needed Drupal’s ability to define custom content types and program views specific to content type.
So far, we’ve received rave reviews for the newly developed site.
> 3. how large is the WordPress/Drupal web development community in my area?
This is a good question. Drupal 7 was officially released on Jan. 7, 2011. Drupal release parties took place all over the world. Looking at just those that registered at http://www.drupal7releaseparty.org/ there were 96 different countries represented. One can also look at the groups.drupal.org site to discovers hundreds of local drupal communities from all over the world.
The post does not mention RDF / Linked data / semantic web applications. Although I assume that this is not an urgent concern for those who create and maintain (networks of websites) but this development seems to be gaining momentum. Drupal 6 gives some support, Drupal 7 will offer more. How about WordPress?
The Semantic Web’s data exchange formats are important to syntactic interoperability, and therefore a CMS must be able to exchange data for semantic interoperability. Both Drupal and WordPress offer core capabilities for exchanging machine readable data.
Drupal 7’s RDF mapping API looks promising for applications like AgriDrupal, which rely on data exchange standards like AGRIVOC.
I am not sure of the utility of having RDFa in the core as opposed to a module. I am more comfortable with the module/plugin/API approach to data exchange to opt-in to the right standard and in the right context. RDF, RDFa, and microformats lend themselves well to templates and not core systems. RDF integration at the core of a CMS is not a conditio sine qua non for data exchange.
“Both Drupal and WordPress offer core capabilities for exchanging machine readable data.”
I’ll have to admit, I’m not that familiar with WordPress. What is the mechanism that WordPress uses for exchanging readable data? I have worked quite a bit with Drupal, RDF, and the Feeds module to produce/consume machine readable data and find it extremely flexible.
“I am not sure of the utility of having RDFa in the core as opposed to a module.”
Actually, it’s not an either/or situation with Drupal 7. D7 has RDF in the core *and* there is a rdfx module (it’s a bit confusing as it’s a contributed project available at http://www.drupal.org/project/rdf) and several value added module such as evoc (part of rdfx), sparql_views, varql, etc.
Thank you for sharing your expertise on this, John. The mechanism WordPress uses for exchanging readable data is from the core feed funtionality (RSS, ATOM, RDF). This is easily extended via plugins.
I don’t quite understand your comment that “modules must be built ground up (vertically) and most time require dedicated development resources for obtaining an end-product.” So many incredibly useful modules for expanding Drupal’s functionality exist already! True, it is tricky to choose and implement the correct ones. Our solution has been to engage Acquia. While they don’t do all of our development, they are available to answer questions we have as our web team gets up to speed on the finer points of Drupal. Acquia is also a superb way to dispense with the annoyance of constant upgrades – they do all of that for us! And no, I swear, I have no affiliation with Acquia other than being a very happy customer.
Thank you, Laura, and your comments prove my point … in your case you rely on a dedicated third-party Drupal solution provider for support and some development. Many times in International Organizations, we cannot rely on one resource (usually due to budget). I agree that there are many useful modules for expanding Drupal, but the way Drupal modules are built (vertically from the core system) makes them prone to bugs and incompatibility.
That leaves us with the question what you mean by ‘horizontal’ and ‘vertical’. Let me give it a try: Drupal modules should be written according to certain conventions that hook into the code of the core. Is that vertical? In my understanding the niterface between plugins and Worpress is the API. Is that then horizontal?
Yes, this is basically what I mean by vertical and horizontal. I found that the WordPress Plugin API with Hooks, Actions and Filters provides a distinct layer over the core system, but Drupal many times requires development down to the core system.
WordPress’s architecture is optimized for search engines. Google simply loves WordPress sites. Numerous SEO plugins also enhance the visibility of WordPress sites with search engines.
I’m almost split down the middle with my websites–around 8 to 12 each. I find it refreshing to see other people struggling and straining to figure out which one they like better
I was going to move them all over to Drupal just because I’m cheap and lazy and wanted to share an APC cache among several installations sharing code. I started to give up on WordPress because I had some trouble with the domain mapping thing at first. But, then it was fixed and now works great.
Upgrading both seem quite easy to me. If you’re running some modules like the htmlpurify, smtp or jquery modules, you may need to follow a few extra instructions to copy some external packages into these module directories. But, it’s no worse than customizing tinymce so that you can edit your materials and feel a little like you were in your normal web environment while you’re doing it. The spell checker may need a little adjustment, or the page break may need adjusted. But, if you’re working with wordpress, you may have to install some modules into mu-plugins and copy some files around.
But, neither one is really that bad. With Drupal, you can share multiple websites in a single installation and have those share the database by using prefixes, or you can separate them out into separate databases. I’ve done both, but mine are currently separated. Using prefixes is a good thing. But, with WordPress, I’m not sure if there is a way around this, but all my blogs are in one database where your tables are usually a prefix of your own choosing (unless you stick with wp–I don’t–I change it), then the prefix is followed by an underline and digits to specify which blog. And there are only about 15 tables per blog. But, my drupal installations have between 110 and 170 tables each.
I found WordPress blogs easier to move from one WordPress installation to another just exporting and importing. However, I’ve also moved whole Drupal installations by simply backing up the database and sending it over and wiring a fresh installation with the same modules and themes installed and files directories copied across into the subdirectories under the sites directory.
Even though my Drupal sites share a single installation, if a module or theme needs to be updated, you’ll have to run the update on each site individually after you update the files.
On the other hand, with Drupal, you have tremendous flexibility to separate out the themes and modules. You can place some in sites/all for all sites to be able to access. Or you can put no themes at all in the /sites/all directory and put the ones you use in each site’s themes directory individually.
For my sites, I just have one theme per site and cram a zillion of them along with parent themes like Zen into a special theme development directory for my eyes only. Then when I’ve tested it and like it, I can copy it into the target website and switch over.
Again, if I were rich, I’d totally have a separate system. Actually, that’s just a dumb excuse because I have a MAMP installation right on my laptop and can work on all this stuff totally disconnected if I like. But, I’m lazy and these sites are mine and they’re in start-up helter-skelter mode. Well, I suppose I’m not really lazy, but I like to align things so I can get them done really fast.
What else? The granularity of permissions in Drupal is quite incredible. One person said WordPress is better set up for SEO, but I have a hard time justifying calling either one better than the other. You can silo them, place content close to the top, have all the titles, alts, keywords, description and other things that people argue over whether they still have value or not. You can have good themes or themes that stink, W3 compliance or not, XHTML compliance or not. You have your sharing buttons. You can alter your titles for multi-page postings. For WordPress you have Ultimate SEO, All in one, and Greg’s Ultimate SEO if I remember the names right, and many others. You have nice URLs with both and canonical and you can set them both up with things like Google Analytics. Drupal even has a module that gives you a checklist and some modules that will analyze your writing and tell you where your keywords are properly represented without being under or over presented. ON WordPress, if you have the ultimate seo package, you can go down the list of your posts and see which ones are missing title tags, keywords, descriptions and such. And it’s hard to beat Drupal’s flexibility. Views, panels, all sorts of custom content, various input filters. Of course much of this can be done with plugins in WordPress, too.
I’m really stuck. I’ve been using both for years, and I’m still doing that, but at least I’ve reduced my usage of so many others. I still used TikiWiki until recently. Joomla was nice, too–a fork off of Mambo, I used it a few years more than I used TikiWiki I think.
But, does anyone remember PHP-Nuke and PostNuke, or b2evolution? I wonder how many websites are around that still use those. When I moved from the Nukes to B2evolution, I thought it was the most awesome thing for multiple blogs and SEO. But before that I was either had coding HTML or using NetObjects Fusion to build static sites with an occasional special database module that was not very flexible for doing anything substantial.
CMS and blogging have come light years in no time!
This comment is not about WordPress vs. Drupal, but “what do we use a CMS for”. Indeed it is an invitation to share more of your experience. I was intrigued by Antonella’s comment where she told us about the different versions of the system that you have been working with last year: from a mashup with Google spreadsheet and Google maps, to an application framework with a relational database management system (RDBMS), to a CMS. That is what I call a journey. I would love to hear more about the background of those choices. If it is too technical for this forum, there are other places.
I have some reservations about some potential uses of CMS’s. There are my concerns: a CMS often uses an RDBMS in the background, using a data model that supports a workflow to publish and maintain a website. Some CMS’s – like WordPress and Drupal – allow to define content types or post types, and defining constraints for the elements that constitute those types. So in a sense the CMS becomes an RDBMS in its own right, relationality through the functionality of the CMS or plugins. So in a sense we get a food chain of RDBMS’s. What happens if you want to migrate a data structure from a CMS to something else? Migration between RDBMS’s is a pain but not impossible. Migration from a CMS (or its underlying RDBMS with all the CMS specific definitions) sound a lot worse to me.
CMS’s can also work with a variety of RDBMS’s. My intuitive choice for more complex systems like CGMAP, that may evolve over time, is to store the content in an RDBMS, and let the CMS do what it is good at: defining an attractive user interfaces (both for searching as for data entry).
Hugo, thank you for your comment. You do touch on some of the real issues and consequences regarding the choice to go with a CMS. I recently gave a presentation on Platform as a Service (PaaS) at an Open Source workshop at Bioversity International, and your description of CMS/RDBMS brings to mind how today open source CMS is much like middleware, and the use of APIs is fundamental to building, configuring, and repackaging (or even migrating) content and Web applications. I have found that the use of this “middleware” allows me great flexibility, even with regard to migration. Now that Ongoing Research is in a CMS, it is quite feasible to repackage the managed content and application logic to other CMSes.
Hey, I would like to remember that drupal and wordpress are NOT the only two CMS existing. I always use Joomla and I feel so comfortable with it. Most important, all the people using the sites build with Joomla feel at ease and empowered pretty soon. And this, I think, is the main driver while choosing which CMS to use.
Michael, this is a nice piece really, and it helped iron out a few debates here and there.
Is it possible to get a few details on the security strongholds and shortfalls of both CMSes?
Thank you for your comment. When it comes to security with any system, look first at you infrastructure (networks, servers), then the technologies used (in the case of WordPress, PHP and MySQL). Regarding Drupal and WordPress, both have strong communities behind security, and Drupal seems to be well-known for the Drupal security team. Since using WordPress this past year, I have seen that security is taken seriously with releases of WP which contain security enhancements. The main thing here is to watch out for the hype and not forget the overall picture infrastructure – technologies – then the CMS.
I think the emerging consensus is: WordPress is good for most sites and excels at usability, Drupal is better for more complex projects like social networking sites.
If I were to build a company facebook for knowledge management, I’d use Drupal. If I need a quick subsite for a research project, I’d go with WordPress.
See interesting thread(with plenty of flaming!) here: http://www.chapterthree.com/blog/jennifer-lampton/wordpress-vs-drupal-saga-continues
Thanks, Ben. The link you posted is great, and in the end, the author states “WordPress and Drupal are still two very different beasts”. I agree on many levels with this statement. My post has brought so much interesting conversation and shows how we are conditioned by the current literature. I continue down my road to promote 1) a pragmatic approach, which leads to 2) don’t believe everything you read, and 3) usability is paramount!