At Rouge we favour Drupal over WordPress for many reasons, security not being the least of these. The sad fact is that there are a lot of people out there that just want to ‘break’ websites for ‘fun’, although there are some that also do this for more nefarious reasons…
As you know Microsoft faces the same issues (hence all those updates), but what you may not know is that Apple Mac’s are targeted far less often, this being for the simple reason that there is less of them, the hackers deciding to concentrate on the bigger ‘market place’ as this gives them a greater chance of success.
Besides the security issue there are other reasons though, Drupal being ‘stronger’, the code also being more efficient, it taking less resources to run than WordPress. Basically, WordPress was conceived as a blogging platform, so when you start using it for more demanding purposes, like Ecommerce you can run into problems…
There are other things about Drupal that make it better than WordPress (for bigger sites at least), one of the main areas being its superior ability in the API development area as well as having better caching features (this helps with making the site faster).
There’s a lot more to our favouring Drupal than this and we’d be happy to discuss these with you, and of course, if you really want a WordPress site, we can create one of those for you too.
For those of you interested in the history of Drupal, please see the blog below, or for the full story click the link above.
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.
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.
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.
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.
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
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
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.
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.
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 left-to-right 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.
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.
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.
What can we expect next?