Drupal began as a forum for a few friends to monitor their shared Internet connection, which "was expensive and being spliced between them," according to Jared Whitehead's The rise of Drupal and the fall of closed source. Today, it's one of the most popular content management systems out there, competing with powerhouses like WordPress.
So, what has the Drupal community done to ensure continued competitiveness, usability, and overall sustainability? In this article, I'll walk you through Drupal's evolution chronologically, including key design decisions and feature upgrades. My sources include the History of Drupal: from Drop 1.0 to Drupal 8.0 slideshow by WebSolutions HR and Drupal's CHANGELOG.txt.
Drupal 1.0
Creator Dries Buytaert based Drupal a great deal on Slash, a modular CMS. To start, there were 18 core modules, and each was a PHP file. You could input code into one of the seven hooks in the modules. The admin hook could only be used by administrators. There were themes already in the core, and you could create your own themes as well. With themes you had control of colors, markup, layout, and block positioning. To modify the database, you imported an SQL file. Features included story submissions in hard coded categories, a diary that acted as the blog, accounts, comments, search, RDF headlines, and a calendar that acted as the archive. Importantly, anyone could be a contributor.
Drupal 2.0
The second iteration's major development was a translation feature, which allowed you to either create or overwrite your site in a different language. In order to do this, you had to edit the configuration file and SQL database with the t() function. Version 2.0 also contributed more notes of complexity to the framework by adding user ratings, sections for stories, and a user permission system. The user_access () function became more fine-tuned, allowing for different user groups.
Drupal 3.0
This is the release when nodes, as opposed to pages, became the primary unit for content. All types of content—story, book, diary, forum, blog—existed as a node which was managed by the node module. The key here is that you could create any type of content as a node. Comments became connected to nodes. With the node module, you could arrange how content types were configured and set defaults for how blog posts were displayed. Ten years later, nodes would become the basis for the mobile web.
Drupal 4.0
In 2002, tech news site KernelTrap.org migrated to Drupal 3.0.2, signaling Drupal's ascension in the world of tech. KernelTrap's Jeremy Andrews wrote the Throttle module, which was later included into Drupal Core. Throttle detects surges in traffic and then provides congestion control.
The fourth iteration of Drupal introduced the taxonomy module, which replaced meta tags and attributes. The core taxonomy module was an important classification and organization feature that is still a core Drupal feature. You can create vocabularies based on keywords, assign different types of content to these keywords, and create, assign, and modify content types.
Drupal 4.1 to 4.7
This phase included tons of modifications and growth, including the first e-commerce module (4.4). It was something of a Cambrian explosion for Drupal:
- a profile module
- a theme template
- configurable menus
- translation improvements
- WYSIWYG (What You See Is What You Get) support—which allows an editor to see how a bit of code will appear to the user
Overall, Drupal was becoming more accessible to a wider base of users. Version 4.2 included support for the Microsoft SQL server, and in 2003 presidential candidate Howard Dean used Drupal for DeanSpace. This helped lead to a 300% increase in content activity on Drupal.org.
Version 4.7 included a new forms API, which offered greatly expanded freedom to play with any sort of form in Drupal. Additionally, instead of having to manually install databases in modules, modules could now install databases using a simple query-and-install hook.
Drupal 5.0
Version 5.0 featured the famous jQuery, a JavaScript library that makes HTML scripting easier. Drupal was quick to jump on this, and it's now a web standard.
Another feature was support for distributions of pre-created Drupal packages, which people could then customize to their liking. A new web-based installer did away altogether with users having to manually alter the database, and showed runtime requirements. Users could now cache files from the backend, and create custom content types. Modules were moved to their own directory, and became easier to install and uninstall. In terms of themes, a CSS preprocessor migrated cacheable stylesheets into a single compressed folder, improving site load times.
Drupal 6.0
Whitehouse.gov adopted Drupal 6.0 as its CMS, another big step up.
The menu system was rewritten from scratch, making it a lot easier to use. Administrators could now drag-and-drop a number of features, including blocks, menu items, and taxonomy vocabularies and terms. The language system was modified to support right-to-left languages, and overall it was adjusted to make non-English usage easier. The installer was improved with a new form that provided site info during installation, and automatically used the Garland theme, which had been implemented with 5.0. Security feature improvements included an Update Status module to automatically check for available updates and warn sites if they were missing security updates or newer versions.
Drupal 7.0
Three years after Version 6.0, Drupal 7.0 again imporved on core and usability features. All modules could interact with any node at runtime, so that nodes were no longer dependent on a specific module. In that sense, everything on 7.0 and beyond is an independent entity: content types, taxonomy, users, custom entity types. And to process multiple or long-running tasks, Version 7.0 added a queue API. jQuery was upgraded, and translations modified to support message context.
Version 7.0 marked the primacy of web-based apps: The installer was refactored into an API, and node bodies and fields, and taxonomy terms became Field APIs, which enabled custom data fields. In fact, with this version, any object could register as a Field API, allowing custom data field attachment.
For search engine optimization (SEO), Version 7.0 added the rel="canonical" link on nodes and comments to prevent the indexing of duplicate content. Image manipulation was improved, and files became their own entities, or objects.
The addition of OpenID allows users login with their email address when the email domain is powered by Google.
Drupal 8.0
Here we are at present-day Drupal.
Versions 6.0 and 7.0 accomplished a great deal, and 8.0 goes even further. A post on the Appnovation blog encapsulates some of the key innovations: Drupal 8.0: Where features meet functionality.
There is now a standardized release cycle of six months, meaning we'll see Drupal 8.2 in November 2016. Semantic versioning, or SemVer, alerts users to every patch release. Version 8.0 incorporates code from outside of the Drupal community, and that code is largely object oriented. The Views module is now a part of the core, with bulk operations functionality. Several core APIs now have a plugin system. Configuration is housed in YAML files, where it can be managed alongside code.
A concept from Facebook, BigPipe, is a part of 8.1. It helps pages load faster by sending the cacheable parts first. The Migrate module helps ensure seamless upgrades from 6.0 and 7.0. And, on the front end, PHP is simplified into a Twig template that's easier for front-end builders to manage.
What can we expect next?
Drupal's evolution has consistently prioritized quick adjustment and forward-thinking adaptations to prioritize ease of use. The community took it from a specialist's CMS to a wide-ranging site-builder anyone can use. Expect to see continued flexibility as Drupal continues to evolve.
2 Comments