by zhirayr
| Jul 31, 2012
Introduction
The strength and beauty of a CMS is that it separates the content from the programming from the design. That way, the designer knows their layout is standardized throughout the whole site, the content writer can use the familiar what you see is what you get editor to write and format their text without having to know any strange little tags or short codes, and the programmer does not have to worry about a misplaced semi-colon or apostrophe putting them through hours of debugging hell. We have thoroughly discussed all the pros and cons of using CMS’s previously. Once you are certain you want to proceed with a CMS, you should choose between blogging platforms and other CMS’s.
Some readers may recall, we have made a review Joomla and Drupal earlier, but this article is different: it focuses more on some specific aspects of these CMS’s such as performance, changes in the latest versions, etc.
Two of the most well-know CMSes out there are Joomla! and Drupal. Drupal started off as message board and Joomla! was originally a branch of another CMS known as Mambo. While Drupal started off in 2001 and rapidly when from version 1 to version 4 by 2002, version 5 didn’t come out until 2007. There was a three year gap between 6 and 7, which came out in 2008 and 2011, respectfully. 5 and 6 pretty much looked and acted the same, but 7 was a complete overhaul from the ground up. The interface is a lot cleaner and better organized in 7. Plans are in the works from Drupal 8, but there is no firm release date as of yet. Joomla! has gone through a similar sporadic development and not as consistent version numbering cycle. 1.0 came out in 2005 and 1.5 was released in 2008 with 1.6 and 1.7 being released 6 months apart in 2011. 2.5 came out at the beginning of 2012 and 3.0 is planned for later this year with 3.1 and 3.5 coming out in 2013.
Changes in the Latest Versions
One of the biggest touted improvements in Joomla! 2.5 was the addition of supporting other DBs besides MySQL. According to the Joomla! Website, “Current drivers exist for the MySQL and MS SQL databases, with PostgreSQL, Oracle, SQLite and PDO drivers close to being ready.” Drupal 7 also underwent a major revamp of their DB support. Drupal 7 now includes SQLite, a zero-configuration, single cross-platform disk file version of an SQL Database. It also requires PHP Data Objects to run any other type of database. If PDO isn’t installed, then the system will default to SQLite. Drupal now also defaults to InnoDB, rather than MyISAM on MySQL when the DB server is capable of doing InnoDB. According to a study done by Oracle , “Compared to MyISAM, InnoDB delivered 35x higher throughput on the Read / Write test and 5x higher throughput on the Read-Only test, with 90% scalability across 36 CPU cores.” Full documentation on the MyISAM and InnoDB engines for MySQL 5.5 can be found here . Links database engine documentation can also be found on that page.
Joomla 2.5 also boosts new natural language search engine functionality, choosing for admins to be notified when a new user registers, adding notes to menu items and users so you know why they were created (1.7 gave this ability to modules) and many other new features which can be found here.
So what has changed in Drupal besides the database. What hasn’t changed in between Drupal 7 and earlier versions is the better question. First off, when you login into Drupal 7’s admin section, you’ll notice that all the familiar stuff like Site Configuration, Site Building, User Management etc are gone. They have been replaced with words like Modules, Appearance, and People. In the modules screen, you still see the familiar list, but now you don’t have to leave that screen to find the permissions, help, or configuration for them. If the module makes them available, links to all that are right next to the module’s name and description. Module updates are now a tab next to the module list, though that particular update only displays the most current version. If you want more of a choice, like for example installing a dev version, you need to go to Report and choose available updates. A complete list of changes for Drupal 7 can be found on their website. Current release notes for all versions of Drupal from 4.7x forward can be found at Drupal.org.
Performance
The type of server (shared, dedicated, virtual private, cloud, and semi-dedicated), how it is configured, and the number of users on the server besides you will affect how your site performs. While you may not be able to control the configuration of PHP and MySQL, make sure you are able to work with your webhost should a special configuration need arise. Also, if you are on a shared host without a dedicated IP, do a reverse IP look up to see how many sites are actually hosted on your server. Finally, keep in mind that VPS, cloud, and semi-dedicated servers blend the best of both worlds, they offer the privacy and security of what appears to be your own server, but your are still sharing resources with other users.
Part of performance is memory. Joomla! doesn’t say on its site how much memory is required, but a person reported in their forum that they received a memory allocation error when trying to run a Joomla! site with only 16MB allocated. Drupal 6 had a minimum requirement of 16MB and Drupal 7 has a minimum requirement of 32MB, but that’s only for a basic install. When you start adding modules and extensions, especially stuff like image cache and views, then you probably want to allocate anywhere from 64 to 96 MB. The more modules you have, the more memory you are going to use. It doesn’t matter if it is Drupal or Joomla. And that’s just the PHP memory allocation, you also have to worry about the memory and wait time allocated for MySQL. If the wait time, or time that the server think the transaction should take place, is set too low then you will start getting “MySQL has gone away” errors.
Another consideration is bandwidth. Most web hosting accounts have a limited amount they can go through every month. Every time there is a request made to the server, the size of the item being requested is the amount of bandwidth that is consumed. This is double when a Secure Socket Layer (SSL) certificate is involved. A few things you can do to minimize your bandwidth consumption:
- Only SSL encrypt the pages you need. Recommended areas include your shopping cart and transactions, user information, and the admin section. Drupal has a module for this called Secure Pages, though it’s currently only a dev version for Drupal 7. Joomla has Yiero SSL redirection
- Minimize the areas that crawlers, aggregators, and search engine spiders have access to through your robots.txt file. In other words, you don’t want them to crawl the template directory or your admin section but you do want them to crawl your content pages. Also, you might want to consider limiting what automated bots and spiders crawl your site. Anyone or anything that hits your site, even if they are not a live person, consumes bandwidth.
- Cache as much as you can whenever you can, including your JS and CSS files. Not only will this help with your bandwidth and speed, but it will prevent you from running into the 31 linked stylesheet limit imposed by Internet Explorer.
- Make sure to resize your images and optimize them for the web. Sure HTML allows for you to set the width and height of an image so it appears to be smaller, but the bandwidth of the image is going to be the filesize of the image. Larger images that resized by HTML also impact the speed of the page load. Finally, resizing images by HTML might lead to pixelization or blurriness.
User Management and Permissions
Prior to Joomla! 1.6, the only thing you could really control with user levels without a 3rd party extension was the security level of content entry. Everything else was pre-determined for you. Joomla 1.6 changed this by introducing Access Control Levels and now in Joomla 2.5, it seems like that control is on every page and controlling most everything. This includes being able to allow non-admins the ability to manage modules and users. While this makes Joomla! about equivalent to Drupal as far as access control goes, Drupal’s user interface is a little more friendly. Permissions are laid out one page with a column for each user type so instead of having to select one item and set the permissions for that and then move on to the next, you can do it all at once.
That being said Drupal’s permissions can be overwhelming and confusing. The permissions are in short little phrases, so you are not always clear as to what the permission does unless you study the code or read the documentation. This is especially true for the Super Administrator role. Some modules, FCKEditor as an example, require a specific role. So prior to Drupal 7, you would have to make your Super Administrator an Admin as well and give them permissions from there. This led to a module that automatically assigned all permissions to a specific role in Drupal 6. Now, in Drupal 7, that module’s functionality is part of core.
Content Management
The differences in content management between Joomla! and Drupal is an interesting dichotomy. Everywhere you go in Joomla!, it seems that you have to hit either apply, save, or close or the item is locked. Drupal doesn’t do this unless you install a module specifically for content locking. Joomla has a simple content publishing and approval workflow built in that is based on user levels. Drupal has one as well in the fact that you can set the node type to always be unpublished and then set the user level of the writer so that they can write and edit content, but cannot control the publishing of that content. Another user would then have to have the permissions for publishing. Both CMSes have extensions that enhance the workflow process, you just have to pay for the Joomla! ones. Content versioning requires a 3rd-party extensions for Joomla! whereas Drupal comes with it as part of the core package, you just have to configure the permissions for it.
Entering content is pretty standard between the two, depending on how the permissions are set up. You put in the title, content, and category (term, in Drupal’s case) from the content screen. It’s the actual display of the content is affected by the content screen and the differences between the two systems that gets really interesting. Both use templates to display the content. Choosing what is displayed is definitely different. Joomla! allows you to set stuff like the display of the title, date, and links right on the content entry screen. With Drupal, you have to use views or templates, either created in the Contemplates module or by hand, or a combination of the two to achieve the same effect. Joomla! also has the ability to set CSS classes that affect the content from the content entry screen. With Drupal, you have to do this through the template files and functions. Finally, Joomla! allows you to enter meta data on the content screen. Drupal does this too, but it requires a couple of add on modules.
Where Drupal excels is the fact that it allows you to set the menu and the URL of the same screen as the content because of Drupal’s core path and menu modules. If you have the PathAuto module installed, you can set up path patterns and it will do create those URL’s automatically. With Joomla!, you need to create the menu item on a separate screen, which will in turn create the URL. You can also use a third party module for URL creation, but again it is on a separate screen. Joomla! also gets a little confused when the same menu item is in two different menus. While it will still go to the same place, it won’t always highlight the menu item. Drupal has no problem with this.
Extending Functionality
Joomla’s Extension Directory boasts 9,675 extensions. Now that sounds like a pretty good number and it is, but you have to pay attention to the license. While they are all GPL, or General Public License, the developer can still charge for the extension or require a registration. This is an unknown gotcha on the part of Joomla! extensions. Drupal’s modules page boasts 10,464 modules. Of those roughly, 6,675 are compatible with Drupal 6 and 4.462 are compatible with Drupal 7. Some of these modules are compatible with both versions. Drupal modules, if they are listed on the Drupal site are usually free.
What’s really cool about Drupal modules is that if the community likes them enough, they eventually become part of core. Content Construction Kit (CCK) which allowed for the building of content types that held more information than just the body and title and Status Report, which showed the current status of current modules are two great examples of this. Joomla! doesn’t seem to follow this process.
Theming
Theming Drupal and Joomla! is fairly straight forward since they both use CSS and templates to do the work. The main difference is how the templates are coded. Joomla! uses its own specific tags indicate where the sections of content should be where as Drupal uses div ID’s after the section is designated in the template’s info file. Also, Joomla! allows you to create a section on the fly and put the short code in your content area that refer to a module section you have created in the Module Manager, but not in the theme. Drupal doesn’t have this functionality.
Both Joomla! And Drupal allow for template overrides. Template overrides are when you have a standard template and want to display a variation of that template depending on. Joomla! Takes the approach of creating a template in the module directory, choosing that template in the Module Manager, and then choosing the menu items where the override is taking place. Drupal takes more of a programming approach to this. You name the file using theme hook suggestions and a naming convention to tell Drupal what is being overridden. For example page–node–1.tpl.php will override the page display of node 1. Also, in Drupal, if you want to change the output of a particular item, but not the whole template around it, then you can use functions in your template.php file. Joomla! doesn’t have this functionality.
Working with Other Applications
There are two ways to customize Joomla! and Drupal to work with other applications. If you don’t need them to share any sort of information with the other application, then you can theme the application to look your Joomla! / Drupal installation. One thing to note is that some third party applications use .htacess to perform the URL rewrites for SEO functionality. If this is the case, you need to make sure that there is a Rewrite Base command included in it that points to the app directory. That way, the Drupal / Joomla! .htaccess won’t try and take over.
If you need to share information between Drupal / Joomla! and another application the you need an extension called a bridge. A bridge is exactly what it sounds like. It connects or “bridges,” the database information of two applications so they can share the same users and login information. Bridges are probably the least safe extension to use because they are dealing with the database, so if you need to use one, make sure to read up on people’s past experience and be careful.
Security
One of the best ways to keep your CMS secure is to keep it updated. Before Joomla 2.5, you had to manually check on the core and various extensions. Now there is an auto update feature right on the main dashboard. Drupal has had the same sort of functionality since Drupal 5 with the Status Report module and now in core with Drupal 6 and 7. Drupal 7 takes it one step further and allows you to automatically install the latest release module directly from the admin back end. The only problem with this is that it’s the official release and not the dev modules.
Updating your modules means sometimes means updating your database scheme. Drupal 5 through 7 has always had a place in the module list or on the status report screen where it reminded you to do this. It wasn’t until Joomla! 2.5 that Joomla! added a database fix button, which does the same thing.
Other things to do to maintain security on your site are:
- Try to use a stable release of an extension – Dev and release candidates of extensions should not be used on the live sites where you want the most stability and security. They are meant to test and prove new features or bug patches before being rolled into the official release version. That being said, it is sometimes necessary to use a dev module when it has a feature that another module is looking for. Read the instructions on the modules for any necessary pre-requisites and make your decision from there.
- Never modify core files – Always use extensions to add or correct the functionality of your CMS even when modifying the core file might seem faster than creating the module. There are two reasons for this. One is that when you go and update your site, you might forget what you modified and why, so all your changes will be overwritten. And two, there are a lot of interdependencies between the core files, so what you might think is a simple change affecting one line of one file could impact several lines in several files.
- Backup your database and files - It’s always a good idea to back them up before you do an upgrade. That way if something goes wrong with the upgrade, you can revert to the previous version and then figure out what went wrong. What you might not think about is doing a daily or weekly backup, especially on sites where your users are constantly changing content. Servers die or are compromised and web hosts go out of business. It’s a statistical fact and sometimes even a noteworthy news item.
- Use Captcha on your forms – Captcha is some sort of visual challenge to test and make sure it’s actually a human being filling them out and not an Internet bot. Currently, Drupal 7’s Captcha plugin is dev with a beta release. Joomla! 2.5 has Captcha built in plus a few listed in their extension directory, but you have to pay attention to the version that they support.
- Use a private directory not in your main web directory for private files – Make sure you can easily set up and access a private directory on your web server. On CPanel system, this would be done by creating a folder above the public_html. Plesk has a folder called private. Ask your web host about how you can do this on other control panel types. Drupal’s Ubercart module requires a credit card encryption key and they want to put it in some place that isn’t web-accessible. You also might only want to have private files that logged in users can see.
- Check your folder and file permissions – Make sure, if you can, that they are never 777 or read-write-execute. That kind of permission allows modifications from a plain web browser.
Conclusion
So what CMS is right for you? That answer depends on what you want to do with it, how much time you want to take to learn the CMS, and how much effort you want to put into your development. If you are looking for a birds eye view on all major CMS’s, here’s a great resource for that. The table lists a lot of useful data on popular CMS’s. In a nutshell, though, if you are looking for a simple, no frills, just put up a few pictures and go type of website, then WordPress might be your best option. A little more organization and user control, Joomla is your best bet. Drupal, with its steeper learning curve, is meant for those who want control of absolutely everything and not be forced into a certain way of doing things. The final option is to build your own using a PHP framework. Some people go this route because they have so much customization that they want to do, they feel an out of the box solution won’t work for them or they feel that the codebase of current out of the box solutions is too bloated.
Post Tagged with
