Web Design & Development Blog
We're headed to DrupalCon Amsterdam! Excited to see what everyone's working on.
SourcingLine identifies top Drupal development firms and displays independent customer reviews.
We're happy to be listed as a Market Leader as of today, and supremely grateful for our customers' glowing reviews.
WordPress is great - we love it and gladly support it. But ... at a certain point it can become difficult to customize things. We consider using Drupal when we sense a customer is likely to exceed WordPress's capabilities, or if WordPress is going to start to become a pain to customize, or if there's a fair chance of needing to customize more things as time goes on. If it's going to be just a basic static site + blog posts forever, WordPress could be just fine. It wouldn't save much in terms of development time though, because getting things set up correctly with WordPress requires more grunt-work / custom coding than we're used to with Drupal. It would be mostly a wash. Some items, like automatic URL redirects, might not even be deliverable in a reliable way if we went the WordPress route. There certainly are WordPress plugins out there such as Simple 301 Redirects that would handle that, but we'm pretty wary of those 3rd-party plugins (having been burned one too many times by some that seemed nice but ended up buggy) and have more faith in the community-tested Drupal modules.
WordPress: Pros: great admin interface, easy to set up. Cons: not terribly granular, and extending its capabilities requires a mix of plugins, which can lead to problems.
Drupal 7: Pros: good admin inteface (can be made great), very extensible, modules ("add-ons") are very well-tested by the Drupal community. Cons: harder to set up and configure than WordPress, theming usually involves custom theming, more resource-intsensive.
I can write a lot about the benefits of Drupal over WordPress .... but here are some things that come to mind:
- Pretty, easy to use, great for blogs and basic sites that don't need too much customization.
- Has a good built-in SEF URLs (search engine friendly URLs) system that's easy to configure and use, as long as you are coo with the same URL pattern for all blog posts / pages.
- Many plugins that can extend its functionality. However, the best WordPress installations rely on < 10 plugins. More than that and you're likely to face some upgrade issues eventually. Choose your plugins wisely.
- Automatic updates. This is a great feature; just make sure you also have a backup system in place in case the automatic upgrade breaks your site. We haven't seen it happen yet, but it could.
- Mobile-friendly admin interface and tons of responsive themes
- Again, it offers loads of plugins and themes, but many of these are commercial and require commercial support.
- Version 3+ is pretty, pretty easy to use
- Can be used as a CMS (mainly) but also for blogging.
- The URL aliasing system still leaves something to be desired. This can be partly overcome with addons like sh404SEF.
- Mobile-friendly admin interface and a decent selection of responsive templates
- Joomla itself is free, but many of the best add-ons are commercial, and require subscriptions in order to keep them secure and up to date. You should be using the best commercial addons because there are many shady third-party add-ons out there, and while free, they will cost you much more in the long run because they will wreak havoc on your site during your next major upgrade. Choose your Joomla extensions wisely!
- Its name is Dutch, meaning "water drop". So that's an advantage over WordPress or Joomla right there. Admittedly, we're biased. Plethora Design's founder, Casper Voogt, was born in Amsterdam.
- Super extensible. At its core is a system of content "types" and fields, so you can design your own content types, whether it's for news, blog posts, products, user profiles, and so on.
- It has Views. Here at Plethora Design we LOVE Views. And it ships as part of Drupal 8's core! You might be wondering what this is. It's a query builder that comes with many display options. You can display a list of content as a table, responsive divs, bulleted list, slideshow, iCal feed, CSV export, and so on. This allows you to reuse content items in a myriad ways, all the while exercising full control over the code output, so that you can style specific content fields discretely. Joomla and Wordpress, by and large, do not offer this granular level of control. It can be added, but takes custom coding to accomplish in most cases.
- Features an awesome ACL / permissions system. It is incredibly granular, such that every add-on can add its own specific permissions as it sees fit. Joomla 2.5 and 3 offer similar ACL controls, though these have been baked into Drupal for over a decade, whereas Joomla is still absorbing these new features.
- A critique of Drupal has long been its seeming lack of good themes when compared to WordPress and Joomla. This is partly true, because Drupal is more developer and enterprise oriented, so there is a certain expectation that the functionality and theme will be custom-built or at least heavily customized. As such, there are not many commercial ready-made Drupal themes out there, but there are some truly wonderful "base themes" such as Zen and Omega, which are the only ones we work with on Drupal sites. The beauty of using such frameworks is that the framework is free, and enables you to leverage a community of many thousands of dedicated developers, versus relying on a commercial entity to provide support. It's a great choice if you need to exercise a great deal of control over layout, but don't want to reinvent the wheel. All the bells and whistles you might see on WordPress and Joomla sites can be done with Drupal, and then some. It's just that Drupal is geared more towards those who have a need to heavily customize workflows, content types, layouts, and so on.
- Out of the three, Drupal has the strictest coding standards. It has unit tests and processes in place that modules (add-ons) must pass before they are approved for general use. There is a spirited community that reviews modules, and as a result Drupal modules tend to be capable of more robust functionality than many (not all!) Joomla / WordPress add-ons. And if you don't like some aspect of the user interface you have the freedom to change it. As they say in Drupal-land, "there's a module for that".
- Debugging Drupal modules is more straightforward. This speaks to how Drupal attracts more developers than either Joomla or WordPress. Drupal has automated testing and patch testing in place to ensure code is up to snuff. This avoids much of the ridiculous forum discusssions on Joomla and WordPress forums, which often involve hard-to-reproduce issues which are subsequently no tracked as bugs. With Drupal, the default position is to track issues as bugs and resolve the in a an orderly fashion that benefits the community at large.
OK, let's be honest. We favor Drupal. But Joomla and WordPress can be very good choices for some projects, and we do recommend these for new projects all the time. When planning a project, just make sure to plan for eventual 'enhancements' and extra functionality, because more often tban not these things will happen.
Out of the three, Drupal may have the highest learning curve, but it does offer the most flexibility in terms of handling any complex requirement you may throw its way. For even greater flexibility you could build your own home-grown CMS, and in many ways that is what Django does, but that is for another post.
This post is probably not news to some readers, but could come in handy for others.
Ever used Drush? If you manage a Drupal site, you ought to. It makes installing modules, clearing the cache, and other tasks much easier.
Say you want to install a module. You could do this:
#: drush dl somemodule
#: drush en -y somemodule
.. but that's two steps. It could be done faster like this:
#: drush en -y somemodule
This works in Drush version 5.9 but not 5.6. I have not had occasion to test with 5.7 or 5.8 and don't know in which version this was introduced.
Drush is psychic and knows that what you REALLY want is to A) download this module and B) install it. It already knows you want to sa "yes" to enabling it since the command includes "-y" in it, so it's not psychic on that count. So.... this one command will download AND enable the module. If you do a lot of module installation, this can save LOTS of typing.
We've been revamping some customer Joomla sites, moving them from Joomla 1.5 to 3.2. The migration process means a move to Joomla 2.5 and a subsequent move to 3.2. It's a bear, but it's worth it. Joomla 3.2's admin interface is far superior to even Joomla 2.5's. I personally LOVE the Isis administrative template. It's mobile-friendly, and pretty intuitive. Much of the mundane, repetitive work of managing articles, modules, etc. is now much easier. Batch processing has been made available throughout.
Now the bad: if you want to be able to add custom content fields you will still need to use something like K2 (getk2.org), Zoo, Seblod, etc... see http://extensions.joomla.org/extensions/authoring-a-content/content-construction. K2 is the only one we have used and could recommend. The lack of CCK within Joomla core is indicative of Joomla being more of an out-of-the-box CMS than a 'framework'. Drupal has had CCK built-in since its inception, and has very powerful entity handling for individual fields. Each field can be formatted and displayed differently, and this can be done via an admin interface (using default Structure > Content Type > Display, or using Display Suite), or by custom-coding the display in your template (TPL) files, or using custom display formatters (plugins). You can even combine data from several fields into one, using Computed Field.
Drupal 8 is still in the works, and promises full mobile support as well as editing-in-place, with no need for page refreshes. If you don't want to wait for eight, you can install the Edit module .. see https://drupal.org/project/edit. I'm not yet sure how this interacts with the Autosave module; it may not save auto-saves the same way as before.
When editing a web page and adding a link, what happens when the target URL changes? Your links breaks. To some extent you can use the Internal Links and Link Checker modules (see our earlier post, "Drupal link tools for improved editorial workflow and SEO"). Those are handy for external links especially. But what about linking to Drupal nodes? The ideal setup would be to use only internal links, e.g. "node/123" and never link to aliases, such as "about-us" or "/about-us". The reason being that if you linked to your About page using "about-us" or "/about-us" and later on you decide to change its alias to "about", your link to this page will break. You can use Link Checker to track this down, but it would be even better to not have this issue arise in the first place. You can avoid this by using only internal links. You can build this into your editing workflow using the following combination of modules:
- CKEditor - https://drupal.org/project/ckeditor
- CKEditor Link - https://drupal.org/project/ckeditor_link. Make sure to edit the CKEditor settings AND your text format(s) to enable the CKEditor Link plugin. Otherwise your links may still get displayed as "node/123" even if you selected your path using the CKEditor Link too when editing the page.
- Pathauto - https://drupal.org/project/pathauto - creates automatic paths based on the node title. Can also be configured to set custom paths based on the content type, and other more advanced options (using tokens). These are called Patterns. In Drupal 7 see admin/config/search/path/patterns.
- Redirect - https://drupal.org/project/redirect - handles automatic redirection, for example when you change a node's alias from "about-us" to "about". Then then old alias "about-us" will redirect to "about".
- Global Redirect - https://drupal.org/project/globalredirect - redirects any node/123 style paths to their corresponding aliases, if any exist.
We're putting the finishing touches on two new Drupal 7 modules. These are still "sandbox" modules as of now, but we'll update this blog post when that changes.
If you have ever had a use case that called for a double or triple text field with those text fields grouped together, this module may be for you.
- 1-3 text fields (text fields ONLY!) grouped into a single field.
- Field formatters to display only text box 1 (Title), text box 2 (Details), or text box 3 (Additional)
- Views integration
The problem: the Redirect module can result in the occasional "Oops, looks like this request tried to create an infinite loop. We do not allow such things here. We are a professional website!".
This module removes redirects that cause infinite loops; this only applies to redirects created by the Redirect module, and as such this module has just one dependency: the Redirect module. The module hooks intro cron. When cron runs, this module checks for any aliases that clash with existing redirects, and then removes them. It logs these actions to the watchdog table.
- Runs when cron runs
- Logs each redirect deletion to watchdog
Note that the Redirect module has a pending patch (see https://drupal.org/node/1796596) that takes care of the infinite loop issue at the moment it gets created, but our module is intended to remove pre-existing infinite loops during a cron run.
Some Drupal sites don't allow regular users to log in at all; they may only be used by administrators. In such cases it may be desirable to lock down access to the login and admin screens. This can be done using htaccess.
In this example let's assume the site is installed at /var/www/yoursite.com/public_html. First you need to create the .htpasswd file. You should not put it in public_html - it needs to be outside your web root. In this example we can put it at /var/www/yoursite/.htpasswd which keeps it in a logical, easy to find place. To create this file do the following:
- htpasswd -c /var/www/yoursite.com/.htpasswd yourdesiredusernamehere
- Next it will ask you to enter a password (hit enter afterwards). Then it asks again.
In your web root folder (where Drupal is installed) open up .htaccess. If you're using the command line, type:
That will show all files, including normally hidden "dot" files.
Go into public_html and edit the file (e.g. "nano .htaccess" or "vi .htaccess") and add the following code to the top or bottom of the file;
Now http://www.yoursite.com/user and http://www.yoursite.com/admin are protecting the Drupal login form from brute force attacks. Doesn't mean it still couldn't happen, but it makes it much less attractive to the brute force attackers. This approach is not a good for sites that need to allow regular users to log in. This is intended only for sites with NO regular users who need to log in to the site. Admin users can still get in. You can set it up so each admin user has his/her own unique htpasswd username/password, or they can all share one. In any case their Drupal logins will differ.