Home > Drupal > Drupal is NOT a CMS.

Drupal is NOT a CMS.

October 9th, 2010 Leave a comment Go to comments

Contrary to what you may call it, and even what they say it is - a "Content Management Platform" - I consider it to be an extensible core framework that "happens to ship with many content related features by default."

Stripping it down to bare bones would reveal a flexible and fairly well designed framework that can be used for anything really.

That's my major beef with Drupal - that it ships with so much content-specific functionality in place. For instance a node is something everyone universally agrees is a "great concept" - a basic item that is extended by custom options (CCK is the model of how easy this is) - but nodes still have a "Title" and a "Body" and publishing options and other fields that shouldn't be there in a truly generic system. The idea of one central basic element though is spot-on in my mind. With all that in mind, I begin my thoughts...

When it comes down to it, almost everything can be considered some form of a "content" item. For example, I designed something to track transactions. At first I cheated and used CCK and just made some custom fields. I also made a version using Drupal's schema API that just made a normal database table, to skip any CCK overhead and node "addons" Drupal glues on by default. However, the overhead aside, I was able to use this system and with not a lot of code, make a fully functional transaction tracking system based off of node concepts. I used CCK as a "schema designing" frontend, and could use Views to get the information back out in a variety of ways.

Is a transaction "content" in the common sense of the word? Not at all. It's a reference to someone purchasing something, in this case a user purchased another type of node - so really it was just a user reference and a node reference. I didn't care about the "Publishing options" or any of the other Drupal-related built-in node specifics, and anything else that may attach itself to nodes - Pathauto, Fivestar, etc.

I [ab]used the node-based system and CCK's UI to make myself a flexible schema to track transactions. I was also able to use pure API to create a database table and manually track the information, and skip any of the hooks related to node processing (Pathauto, Fivestar, publishing options, etc.) - which one was better? Well, I'm still deciding that. By using the node method I can easily expose it in a view. I am not sure I can using custom schema (I think someone told me I could but I haven't tried yet) - I'd really like to use Views for it, and be lazy on the delivery side of it. By going custom, I track only what I want in the database and save probably many levels of pre- and post-processing on the result set.

Getting back to my original statement - Drupal's foundation is pretty solid. It enables anything to be accomplished, it's just that damn middle layer that I wish would be more decoupled and moved into modules that can be enabled or disabled. For the most part, people who use Drupal seem to use it mainly for it's CMS/"Content Management Platform" capabilities just fine. Some of my sites require custom work though, and that is where I enjoy the framework/platform's underlying capabilities.

Typically when developing a site, there are common elements such as user login/registration/roles and management, form processing, XSS/CSRF/other attack vector protection, output encoding, data and request normalization, etc. I've built my own little library of functions and even a bit of a stub framework to use them which do a lot of this. Drupal however has already generalized most of this and provides it to you for no cost.

Frameworks in the typical definitinion such as RoR, Symfony, and half a million others give you the basics, but don't give you that much. It's still up to you to create everything else. While I may whine about Drupal's content-heavy core packaging, it does provide some built-ins that I do find useful to be included. So I guess that can be chalked up to some personal opinion - I would rather the it push the content stuff out to modules (and strip nodes down to even simpler basic structure) yet keep the user registration, login, role and capabilities and form processing available.

All in all, I am having fun looking through the directories of modules out there, and trying to approach things with a more Drupal-eqsue model in mind, understanding that I will sacrifice some performance and add some overhead, but also save myself the headache of all those tedious user submission and form processing screens and such. That's usually where typical self-coded projects seem to start trailing off for me, is winding up getting into the user interaction piece of it. Database design, delivery - that's easy. Form processing and user experience? Annoying as hell :)

Categories: Drupal
  1. Drupal development company
    January 16th, 2011 at 22:11 | #1

    I want to say that Drupal is well-known search-engine friendliness Content Management System... It provides all the tags in which the engines are looking for. Apart From other CMSs, Drupal developer creates search engine friendly URLs. However the Drupal CMS is SEO Friendly it can’t do better in the search engines, by adding few modules in your Drupal sites, your sites can easily get higher rate in search engines. In other words, Drupal makes it easy to practice good SEO.

  2. mike
    January 16th, 2011 at 22:21 | #2

    Most CMSes nowadays are SEO friendly. That's against the point of the post. The point is that I do not consider Drupal a "CMS" it is more of a "framework" or "platform" it is just used primarily as a CMS for most people.

  3. Ryan
    February 25th, 2011 at 00:01 | #3

    The more I understand Drupal the more I find myself using it as a framework as well. There is a nice separation of 'design elements' and 'programming functions' in using Drupal this way, and only minimal "gui" configuration is necessary. Most anything can be overridden in code once you do a bit of research. That's why I really like it, you can easily find modules and customize behavior and everything 'just works'.

  4. mike
    February 25th, 2011 at 03:39 | #4

    The one thing I dislike is having certain options or having to put markup in the GUI for certain things. To me, that should all be offloaded to the theme layer. Some of those still confuse me or I am not aware of their impact for example.

  5. Ryan
    February 25th, 2011 at 09:30 | #5


    Agreed. I work with some sites where the developer tends to prefer these little code snipplets scattered throughout the site. It certainly makes it harder to dive in and start working but once I find out where/why it was setup that way I tend to agree with why he did it.

    As I mentioned in my comment, *usually* there is a way to do it in code but obviously some things like Views are really their own beast.

    Lately my favorite way of dealing with this issue is to check the variables table to see if the thing I want is stored there - those variables can all be managed with Drush now making initial setup even easier by shell script.

  1. No trackbacks yet.