Posts Tagged Drupal
Let me start with a note on my bias – I love WordPress. This said, I have tried not to let it color this post that attempts to highlight when and where to choose between WordPress and Drupal. No matter, I look forward to some solid comments from all sides on these ramblings.
This evaluation really comes down to a definition of the task you desire. I have found that WordPress is the ideal selection for any blog. I have also found it to be an excellent choice for a small to medium Web site. Why? In two words, elegant simplicity.
On the setup side, WordPress is so simply to install, create themes, add enhancements that it is easy to get an excellent site up and running in a very short time. Then on the administration side, the user experience is an excellent one for those who are not familiar with technology. I have been able to bring luddites up to speed in WordPress post, page and comment management in mere minutes.
Drupal I have found to be more suitable to larger Web sites that require a greater level of development for custom applications, multiple themes, multiple languages and other aspects you would expect of a full bore content management system. For a blog or small Web site I find it to be overkill and adds a level of complication that adds too great an expense to sites that so not require custom applications.
This difference is apparent in the extensions to WordPress and Drupal. Drupal features a large set of modules to extend features. WordPress appears to offer many more. The difference comes not just in volume, but types. Drupal has a set that is clearly more technical in nature than WordPress. Also, a good number of the modules are seen as jumping off points for custom development. This is far different from the WordPress plug-ins that are targeted to the Web site maintainer who has little if any programming knowledge.
WordPress on the other hand has a greater balance between the average Joe that wants to have a blog/site and the developer. Surfing to wordpress.org you find that this is tailored much more to the layman than Drupal.org. WordPress also has a broad commercial path to get started via wordpress.com. Then when you do dive into development, you find that with minimal PHP skills you can customize and modify themes.
I find that this separate target of hard core a developer (Drupal) to the general population (WordPress) is clearly evident in area of theme management. In Drupal, the themes are all managed external to the Drupal interface. You compile and create the various layouts on the backend (as you do in WordPress) and then must manage these from the back end. In WordPress, you have access to theme templates form within the interface for modifications. This distinction is key. There are two levels of expectations here. In Drupal there is the expectations that the framework will usually require far more coding and management than should be permitted via the interface. WordPress on the other hand considers the possibility of editing templates to be something that should be permitted to the administrations right from its graphical shell.
Again, this comes back to suitability of task. I would not want a large scale site with numerous complex templates to be accessible by any old administrator – hence Drupal. However, if I have a small site where the admin, maintainer and developer are likely the same person and the theme is straight forward then the interface access is reasonable.
Here are some other side-by-side comparison.
I hate the Drupal editing interface. The listing of pages without any management options means it takes me a long time to find and then adjust content. The content listing and editing options in WordPress are simply far more elegant than anything offered in the Drupal core or via any add on modules I have found. For this interface reason along I prefer WordPress.
WordPress has focused for years on its comment moderation capabilities. They are top notch. Drupal’s are rudimentary at best. Having now used both, I would have to eliminate Drupal as a blogging option for a site that expected high comment volume. Drupal is a fine technical solution. Drupal is simply not up to the task when it comes to the associated workflow.
Simplicity of Free Themes and Theme Design
WordPress and Drupal take a few minutes to install. Getting started with adding a free theme for WordPress takes a few minutes to find tens of thousands of items to get started. Drupal then takes quite a bit to customize even free themes. This difference real comes to the forefront with my experimentations. I can transfer an existing site with drop down menus and a couple of area designs to WordPress in half a day. The same effort took me (and an experienced Drupal developer) a week.
WordPress offers a simple but elegant media library. And a couple of plug-ins really push it to an even better solution. Drupal’s media management is barebones. Media is considered a node or content element just like any other item such as a page or post. This is excellent when you want to develop a larger application on top of the framework. However, it falls short for a simple site.
WordPress offers not just one plug-in for everything imaginable – there must be three or four. The modules that extend Drupal are simply not as varied and there are less options for each task. More to the point, adding, testing and tweaking just seems to be so much faster and easier in WordPress than the developer focused interface offered via Drupal.
Here are some other articles for thought
- Consider using Drupal and WordPress. WordPress for the blog and Drupal for the application side of a Web site. This appears to be in use by companies such as The Bivings Group –See http://www.bivingsreport.com/2009/integrating-tweetbacks-into-your-wordpress-blog/
- An Apples versus Tanks analogy – http://www.elithecomputerguy.com/content/drupal-vs-wordpress-blogging-comparing-apples-tanks
- A kind of funny video version http://blip.tv/file/829821
- An article also about suitability but brings into the fact that the Drupal arena does not focus on marketing of its own efforts in a manner that encourages broader appeal. http://graduallythensuddenly.com/2008/05/04/wordpress-drupal-irrelevant/
- Here is one that has found a clear reason why Drupal may have an advantage over WordPress http://www.danmyers.name/wp/2009/02/drupal-vs-wordpress-why-i%E2%80%99m-having-second-thoughts/. Then again I have used a WordPress plug-in for two years that fixed the problem he has been having without ever having to do any programming
- Here is a side by side list of features http://mydrupal.com/drupal-vs-wordpress. I do not agree with the bulleted list of statements. One I find funny is this one. It says to choose WordPress “If you want ease of use and Navigation…” Okay, is this not one of the basic all time requirements of everything that has to do with any sort of Web site.
- A nice balanced evaluation is at http://www.thesitewizard.com/general/wordpress-vs-drupal-vs-expression-engine.shtml
- Some fun as folks snipe at each other on the Drupal site at http://drupal.org/node/257065. One person claims that WordPress has a “less active development community.” Personally, I have found this to be the reverse. I have found far more global WordCamps and help with WordPress than I have found from Drupal and its more limited meetings. In fact the tone is entirely different. The WordPress folks have been generally welcoming to newbies and encourages exploration by neophytes. My forays into Drupal have been met by cold responses that I should improve my PHP and CSS before I ask questions. Kind of like a family response WordPress) versus a clique (Drupal)
- A nice simple evaluation and balanced perspective from a developer who does not mind getting into the down and dirty of things http://www.webdesignstuff.com/web/designers/03/2009/drupal-vs-wordpress/
One of the things I fear when working with a developer is that they will claim to be as someone around here did to be a “code monkey.” Good Web site development and campaign delivery is not about creating code. It is about utilizing best practices to provide the best user experience. Those who solely want to work on the code level often miss the forest through the trees
Each CMS must be configured to align with marketing, user interface and other best practices. The following provides for common best practices that should be noted for attention with the Drupal CMS configuration. These items are included in this document to confirm the configuration as the technical defaults are often focused on specific functionality rather than such general best practices
A great list of best practices in an easy to read format is available here: http://zzolo.org/thoughts/drupal-basics-and-best-practices Rather than recreate those items, just start and there and then come back to this document for more.
The Drupal core package for download from www.drupal.org has the most basic set of core files and modules. This is always supplemented with additional modules. Use of the Acquia Drupal package distribution from acquia.com can provide a simplified install with a large number of the modules that would have to otherwise be individually installed. This provides the entire core Drupal functions with added services from Acquia. The services from Acquia may not be desired and can be easily disabled.
The following settings, configurations and modules should be installed and activated.
The following basic configurations options should be set:
- PING – Activate ping with a long list of ping servers..
- User Administration – Any agency account management team Role should have the ability to add and configure users to be authors.
- File Quota – Set the file size and upload quotas to at least 50 MB or unlimited for all users. The default of around 8 MB is almost always inadequate.
- Full HTML – Set FULL HTML as the default input format.
- File attachments – Activate file attachment capability for all users.
- Video – Activate the video module for the easy inclusion of YouTube and other videos.
Modules provide functionality beyond the Drupal “Core.” It is the underlying philosophy of the Drupal CMS that any installation will contain a variety of these modules to provide services beyond the basic items built-into the CMS. The main issue when selecting these modules is that they are maintained by individuals often with no real development plan. They may break, be withdrawn or be incompatible with future versions of the Drupal core.
Even so, be sure to check the Drupal module availability prior to developing custom code.
The following are a variety of helpful modules that appear to be well maintained and respected by the Drupal community. This list has been determined based upon Drupal community recommendations and other base level best practice requirements.
The following modules should e downloaded and installed for all sites. They provide base level functions that should be expected for delivery on all sites.
- Content Construction Kit (CCK) http://drupal.org/project/cck
- Views http://drupal.org/project/views
- TinyMCE http://drupal.org/project/tinymce
- Image http://drupal.org/project/image
- Image Assist http://drupal.org/project/img_assist
- CustomError http://drupal.org/project/customerror
- Draft http://drupal.org/project/draft
- Google Analytics http://drupal.org/project/google_analytics
- Image FUpload http://drupal.org/project/image_fupload
- Page Title http://drupal.org/project/page_title
- Pathauto http://drupal.org/project/pathauto
- Search Engine Referrers http://drupal.org/project/search_engine_referers
- Search Files http://drupal.org/project/search_files
Basic Drupal Module Configuration
This provides a method for an editing review with a draft of content. This way someone can make changes and hold then for review or come back later and complete edits and then publish.
To turn this on:
Place a check box in the “Allow drafts when editing” box
This provides for a custom page to be displayed when Web server or browser error occurs. This is important otherwise a blank page is displayed with very little wrapper display.
To turn this on:
Design page nodes or HTML files to display for 403 and 404 errors and place these details in the settings.
On content creation pages, gives you the chance to specify the page title rather than defaulting to the content’s title.
To turn this on:
Active – simply use area in form to set the page title.
The following are common modules that provide some frequently required functionality.
- http://drupal.org/project/headerimage – for custom banners for an area of the site.
User1 should not be used for development, maintenance or other tasks. Set it aside for very restrictive use.
Layout and Development
Never alter the Drupal core. Instead adapt an existing module or create required customizations as a module. These methods will isolate customizations from the core and other modules so that the core may be updated without impact on custom development’
Use the Content Construction Kit and the Views module. You can bypass this kit and module, but future development and adjustments are easier if they are utilized.
Use the From API. Define the forms in php syntax and let Drupal create the html. This will let other modules adapt the form and enables programmatic submission.
With the Form API make sure to check text only fields with check_plain(). This will check the fields for malicious content such as scripts, HTML and so on.
For a normal (single site) installation, you should put all non-core modules or themes in the sites/all/modules or sites/all/themes folders. For a multi-site installation, put modules or themes in sites/all that you wish to have available for all sites.
The following is a good resource for Drupal scalability – http://www.optaros.com/blogs/drupal-scalability. Most of these tips come from this page.
Choose modules carefully and deactivate them when they are not required. This would apply mainly to modules that assist in development. Deactivate these following the development cycle and reactivate when adjustments are required.
CCK is a critical module but can slow down high-traffic sites. Consider its impact on such models. 
A theme is not just the look and feel. It is the data architecture and should be created with performance as a key concern,
MySQL should be tuned for performance for any size site. See this page for four tips to follow : http://www.optaros.com/blogs/drupal-scalability.
Follow at least the basic guidelines for shared server and mySQL optimization as found on http://drupal.org/node/36628
Drupal Site for Best Practices
The Drupal site itself has a whole section on best practices. This is of course a great resource and no one should start developing in Drupal without reading these areas targeted to the deep developer audience.
Other Best Practices Sources
The following are some of the solid best practices locations I have found for Drupal. The information in this document is heavily drawn from these sites.
· http://zzolo.org/thoughts/drupal-basics-and-best-practices – Great great easy to read bullet list – start here.