I was tasked with migrating a website from internal hosting to paid hosting. When that “migration” actually meant a redesign, I surveyed the CMS landscape. The current site was running on Joomla! 1.5. This website was the first site I had administered running on the Joomla platform. To be completely honest, I hate Joomla!. There are limitations and things done backwards that just don’t make sense to me why they’re done that way.
My strongest CMS experience is with WordPress. Most of my sites run on WordPress and I’ve been using the platform for the past four years. My first attempt at migrating the site in question was actually a translation of the site from Joomla to WordPress instead of just copying files and databases. I migrated everything over manually and used a flexible WordPress theme that allowed me to customize it so the layout, color scheme, and everything else from the front-end was nearly indistinguishable. However, the back-end was running on glorious WordPress in a far more stable environment with a much easier to use interface. With some plugins and external web applications, I was able to reproduce the features and functionality of the current site.
When I presented the website, I received funny looks. While I was afraid the translation was worse than I thought, they were expecting the site to receive a huge face-lift. When it was almost the exact same thing as the current website and I found out the second-hand miscommunication, we were both very disappointed and frustrated. (Probably my worst experience in a project though it certainly made concepts from my project management class concrete.)
With a clarified purpose and direction, I was told to make the site my own and redesign it how it needed to be for the modern web. The non-technical vision I received (first-hand this time) seemed to be very page-centric and require a very straight-forward and top-down navigation structure to really serve the site visitors. For that, I chose to use Drupal.
I had never worked with Drupal before but the more I investigated it with a quick setup on a sandbox server, the more I liked it. I felt like an artist getting my hands on a lump of clay. I was able to mold it and shape it how I needed it to work but at the same time Drupal told me how it would work and it was knowing where those two goals could meet in the middle that resulted in a great finished product.
Terminology
Enough of my editorializing… Like most frameworks, Drupal has its own terminology for items and its own organization for where you will find various settings. Understanding the terminology is about all it takes before you can dive in on your own.
Nodes – Earlier Drupal seemed to be all about the nodes, so much that it seemed to stop people from adopting the CMS. In Drupal 7, nodes are still present but you can understand the concept without getting hung up on what a node is or isn’t. A node is the final item of content. If you were to draw out a heirarchy tree, the nodes would be at the bottom. One or more nodes might combine to make a useful page. Not that important, don’t get hung up on it.
Block regions – Block regions are, in my opinion, the coolest thing about Drupal. It is what really gives you the simple but flexible control over your site’s design. It is the reason you could be using one of the most popular themes but have a completely unique look because you use the regions to create a layout that works for you. In the regions is where you shove the previously-mentioned nodes.
Themes – I’ve mentioned themes a few times already. If you are familiar with any other CMS, a theme is just what pulls the content from the database and presents in a nice, consistent manner. Just because the definition is simple, it doesn’t mean themes in Drupal can’t be quite astounding, flexible, or perfectly tailored for specific tasks like blogging, ecommerce, microblogging, photo galleries, portfolios, etc.
You can find themes under the Extend part of Drupal.org. If you’re interested in customizing a theme, you might be interested in subthemes.
Content Types – Content Types are another one of the things I love about Drupal. Drupal 7 comes with several default content types. A content type is what defines the fields available for you to fill in when you are creating new content. It also controls how those fields are displayed to site visitors and the default entries to some of those fields. A simple content type could be simply a Title field and a Body field and you could write with just that. You could also go to the other extreme and have specific fields for everything, like the date of an event, a field for attaching files, the address of an event, and so on.
In some sense, custom content types can help organize your site, provide a “to-do list” approach to creating new content, and ensure a consistent look from that type of content on day 1 to the content on day 1,000. Custom content types also allow you greater granularity of control. In a shared environment, you can independently allow other accounts to only be able to create, edit, or delete each content type. This means you can safely delegate the task of posting specific content without worry that the rest of the site or more sensitive areas could be affected by another account.
Modules – Modules, comparable to plugins, are how you extend the functionality of Drupal from the core. I use a wide variety of modules to get the exact functions I need from a site. You can search for Modules under the Extend part of Drupal.org. I find it helpful to look at the Most Installed Modules to see what many people are using for their sites. Modules are installed very simply by pasting the URL to the module’s .tar.gz file from Drupal.org into the Module page.
Views – Views is a specific module of Drupal and it is very popular for a reason. It greatly increases what you can do with Drupal. Views allows you to create queries against the fields in your database and present them how you would like. This allows you to merge information across content types and really just use the data in flexible, unexpected ways.
Versions of Drupal – I went with Drupal 7 and was happy with the choice. There were a few modules that I wanted to use that were only compatible with Drupal 6 that I couldn’t use. Drupal 8 is also on the horizon. Whatever version you end up going with, just make sure you filter modules, themes, and documentation by version so you don’t waste time on things that won’t work for you.
Room for improvement
About the only complaint I have with Drupal is that minor updates need to be made a lot easier. Module updates are easy, just a few clicks to update the files and the database. Drupal core updates have a long way to go though. While most of your information is tucked away safely in the database, updating Drupal from 7.9 to 7.10, for example, involves deleting the Drupal folders and files (save for a few specified in the upgrade.txt) and uploading the new files. I understand the process (having been through it enough times) but it’s still a little nerve-wrecking that you might lose your customization, configuration, or something along those lines.
Concluding
Overall, I like the Drupal platform. WordPress is really easy to pick up and use and once you have mastered that, I feel Drupal is just as easy to pick up. I like the flexibility of the platform and the straight-forwardness that I can treat it like a a website, a CMS, or a database depending on what I want to do with it. I will probably look for some way to incorporate using Drupal in a personal project down the road.
I would recommend downloading Drupal and installing it on a sandbox server to play around with. You might just be working with the perfect tool for your next project.