What are the best building blocks for a successful Drupal website?
Drupal is a content management system with approximately 15 years of history. It started as blogging software in an era when free Open Source software (FOSS) for content management was taking off.
At its core, Drupal manages three things: content, display and user access. Those are the tips of three icebergs. Each Drupal developer has a different philosophy for how they build sites. This is my Drupal design philosophy.
When I hear “CMS” I think: “content management SYSTEM.” Drupal makes a powerful system available to users and stakeholders. I always look for ways to leverage that power to provide a feature rich website. A static website is easy to accomplish with Dreamweaver or something similar. If you have a Drupal website, use its power.
The cornerstone of Drupal content is the node system. By default, nodes are isolated pieces of content with a title, a body and meta data (publication time, node id, url, permissions, etc.). I like to add more to the content to make it more useable from an architectural standpoint.
Content types make for a large amount of “database bloat”. At the foundational level, MySQL will load in a database’s tables as part of its execution process. Many installations of MySQL will be limited to loading and using 500 tables at a time. If a Drupal site is overly complex, it will have hundreds of tables. Such inefficiencies can be easily addressed through thoughtful architecture.
I see Drupal deployments where there are many content types to satisfy many units or verticals within the organization. I don’t agree with that approach. A different content type can be assigned different role permissions, but I will defer to using other approaches to segment user rights. This is where taxonomy can take on a more substantial role. I will associate the user role to content editing via the module “Taxonomy Permissions” to rule in or rule out users from gaining administrative roles. Likewise, content viewing can be controlled through the same tool.
While I prefer to re-use fields in multiple content types, I will sometimes make a single field with one use. When a content type is deleted, that can change the data model and the number of tables used. Again: careful planning allows for the leanest possible database beneath the Drupal architecture.
The ideal way to make changes to your website is through PHP code changes. While efficient, it involves much more careful development. More than that, it makes it harder to administer the business rules that may be needed.
This is a short list of possibilities through panels:
- Different content for anonymous users, logged in users and administrators
- Adding editing capacity inline in the page
- Link to views and other built-in functionality
- Make landing pages that stand apart from content
The killer app of Drupal is the Views functionality. It draw in the data from different parts of the website and presents it in a number of different formats. The flexibility and power of the Views system cannot be overstated. Where possible, I press to build in relevant Views to provide function for a website. If you have a data-driven website, you should put Drupal and Views into play.
Context can be very handy for controlling the architecture of the layout: blocks, menus, etc. While Panels affects what is in the specific content, Context affects what sits out and around the content.
Meta data is the best means to take long form data and make it brief but relevant. I use taxonomy extensively to organize content, navigation and business rules, and to organize large regions in manageable chunks. The orderliness of taxonomy benefits SEO and users alike.
Interactivity is vital for a website. The best way to get interaction is by soliciting feedback from users through web forms. I generally develop two types of forms in Drupal: the Web forms module that builds feedback forms and polls; and limited access to the node creation system. Through rights management and workflow controls, users can get the rights to contribute to a website.
Most of the hackable exploits that happen to current websites come via exploits in the Web Services (aka XML-RPC) functionality. If a site will not need XML-RPC, I will often remove that capacity altogether. Security is your castle wall. There has to be a strong business case for installing a screen door into that wall. It’s rarely the case, so I rarely open up a client for that level of exploit.
The most important emotional element of your web project is its look and feel. If you don’t like the user interface, you may not like the content. For that reason, theme choices are pivotal in the success of a website.
While I consider myself to be a strong developer and knowledgeable about architecture and best practices for engagement, I don’t have the creative spark needed for making scratch built designs. There is a silver lining to that: a scratch built design is time intensive and often expensive.
I commonly seek out good pre-existing themes. I will either find and deploy a good premium theme; or I will use a CSS Framework. The frameworks of choice (and in this order), that I like to deploy are Bootstrap, Foundation and Omega. They have similar qualities and can work well in responsive (aka mobile) experiences.
Interested in Drupal for your website? Contact us today.