In previous posts on this topic I covered the reasons for using an open source content management system for the new Redwood Technology Consortium site and the process we went through in planning and choosing a system.
One of the core concepts of the open source CMSs I have looked at is their modularity. That is each system comes with a core set of features and then a long list of plugins or modules that can be added that extend the featureset of the site. These add-ons can include enhancements to existing features or completely new functions. Some add-ons are designed soley to allow integration of other open source systems that have been developed totally outside the core community. Examples of add-ons might include forums, shopping carts, elaborate contact management systems or photo galleries.
Many modules are created by third party developers and freely contributed to the CMS community. Drupal (which we used for the Redwood Technology Consortium site) has a long list of modules. This extensibility is one of the advantages of these open source packages. New modules are added all the time. And existing modules can be modified and themselves extended. A challenge in working with these systems is knowing what add-ons are the most appropriate for the particular task to be accomplished. Looking at the list of module descriptions in Drupal can be confusing. It’s often difficult to know exactly how one works from the description. It really becomes necessary to get involved in the Drupal community to learn more about modules, their functions, strengths and weaknesses.
Also, as the core package changes from one version to another, modules are not always updated to work with the new version. For example, the latest major release of Drupal is numbered 4.7. But some well developed modules only work for version 4.6. So, depending on the needs of the site you may have to make a choice between using an older version of the system with the modules you need already available, or use the latest version and either make do what what modules are availabe or write new ones.
In the case of the RTC site we found pretty much everything we needed in 4.7. But since then, on other sites we’ve started working on, this issue has become very important. Writing or modifying modules can take extra time and therefore raises the cost of the project.
One issue we did run across with the RTC site is trying to translate what the organization calls a member to what Drupal calls a member and make the two work together. Membership in a Drupal site is specific to how Drupal works. But this has only limited application to what membership means to RTC. We are still trying to work out this interface.
A drawback we have found in the Drupal system is the weakness or underdevelopment of ecommerce modules. Perhaps we haven’t found just the right module. Or perhaps there is an opportunity for a richly featured and easy to use ecommerce module.
Another weakness in the current stable release of Drupal is the integration of the WYSIWYG (What You See Is What You Get) content editor. This allows non-technical users to create and edit content without having to know or use any code for controlling the display of content. Drupal uses a third party Open Source module (called TinyMCE) that needs to be installed in two stages, one using a Drupal integration module and the other the installation of the third party module itself. But even that doesn’t complete the steps. You also need to integrate an image upload tool that allows the user to insert images into their web pages easily.
Finally, going forward, as Drupal evolves, some modules become incorporated into the core package, while others will need to be updated by the individual developers. This makes moving from one version to another a non-trivial matter. Some modules are updated quickly and easily while other suffer long delays. Unless you have the time and expertise to upgrade your installed modules to work with the newest version, you remain at the mercy of the module developers as far as migrating from one release to another.
So, while this extensibility and modularity has some tremendous advantages, careful research and planning needs to be built in to the management of any project based on them. It’s easy to throw up a basic site with any of several of these systems. But if your project has very specific needs that are not met by the core system or a module doesn’t work exactly as your site needs expect to either modify your site plan to match how things work, or to get your hands dirty modifying or writing new code to suit your needs.