-----
title: "A look at Drupal"
content-type: article
timestamp: 1137048164
tags: "php|webdevelopment|review"
-----

<p><strong>Important Notice:</strong> This article is about changes occurring to zZine Magazine's site[1]. At the time
    of writing, <a href="http://www.zzine.org">www.zzine.org</a> uses the old site, and not the Drupal-based one
    presented in this article, which is currently under construction[18].</em>>
<p>

<p>"Why can't we log who edits
    the articles?"</p>
<p>"Can we send newsletters?"</p>
<p>"We should really have a members' area..."</p>
<p>zZine.org[1]
    is a scratch-built site, coded from the ground up to offer zZine journalists, editors and readers all the
    functionalities and features they wanted. I'm not totally against sites being coded from scratch, but what happens
    if
    something needs to be fixed, or new functionalities have to be implemented and you realize that the code cannot be
    extended or patched easily?</p>
<h3>Case Study: zZine Magazine</h3>
<p>zZine Magazine is an
    online magazine which publishes not only IT-related and other articles on a weekly basis, but also monthly
    publications
    containing CyberArmy[2] digests, special columns, and featured articles. A team of journalists, researchers,
    editors,
    publishers and outside contributors has access to the zZine site to write, submit, and edit articles, manage
    publications and perform various other tasks through a password-protected administration area. This is common to
    approximately 75% of the websites on the Internet: they have a front-end to present content to the general public
    and a
    semi-hidden administration backend which is normally more difficult and tedious to code. That's why someone started
    developing <em>Content Management Systems</em>[3]: ready-made, fully-featured administrative back-ends for creating
    and
    managing almost any kind of website, from blogs to eCommerce portals.</p>
<p>Could a CMS be used for zZine Magazine?
    Probably - zZine doesn't need any innovative or advanced features, just a bunch of commonly-used functionalities
    like:
</p>
<ul>
    <li>Add, delete, edit and publish articles</li>
    <li>Customizable user permissions, ideally role-based </li>(writer, editor, publisher, etc.)
    <li>Creating and managing monthly publications</li>
    <li>Editor's tests</li>
    <li>User signups, notifications, etc.</li>
    <li>RSS feed generation</li>
    <li>Sending newsletters to subscribers</li>
    <li>Logging user actions</li>
</ul>
<p>Some members of my team raised some concerns regarding the usage of a CMS, which were mostly based on our
    past experience with just a particular product and not CMSes in general. Everybody agreed that if we were to go back
    to
    a CMS, we <em>had</em> to choose the <em>best</em> this time: something flexible, easy to use, fast, search-engine
    friendly, and extensible. I spent some time researching CMSes, because while I knew that there's no such thing as
    the
    best CMS, there was certainly a CMS that was best for our needs.</p>



<h3>Making the right
    choice</h3>
<p>In the past, I had played around with Xoops[4] when I first thought about creating
    websites, and I used Mambo[5] for some other sites. I admit that I never actually spent time creating complex Mambo
    components and modules, but I must say that in the end I felt somehow tied to third-party modules and unable to
    understand how they really worked: Mambo seemed to give developers too much freedom, and had neither a solid API nor
    conventions to follow, at least when I used it.</p>
<p>So I decided to have a look around again, starting from the
    two most important sites people should look at when choosing the most suitable CMS for their work. </p>
<p>The first site
    is CMS Matrix[6] which - as the name implies - provides a really handy <em>matrix</em>, or chart, to compare the
    various
    features offered by nearly all CMS available, both proprietary and open-source.</p>
<p>I remember choosing Mambo
    last time I used the matrix simply because it appeared to be one of the most feature-rich. This is actually
    something
    <em>not</em> to do when choosing a CMS: always concentrate on what your site needs rather than what the CMS is able
    to
    offer. Otherwise, you run the risk of having too much to work with.
</p>
<p>The other important website to visit when
    choosing a Content Management System is OpenSourceCMS[7], which basically allows you to try a demo of every open
    source
    CMS online. This is perhaps more useful, but also much more time-consuming: it's better to narrow down the list of
    possible CMSes after checking CMS Matrix and then try each one rather than just picking one at random.</p>
<p>At
    this point, an experienced CyberArmy staff member[8] suggested Drupal[9]. I asked her why, and she simply said that
    it
    seemed to be the best choice according to zZine's needs, as it basically offered all the features we were looking
    for,
    either natively or through modules. She also admitted to be biased, as she's actually <em>part of Drupal's
        documentation
        team</em> and involved with Drupal development[10].</p>
<p>Before making any kind of commitment, I checked out
    Drupal's website to see how they organized things, and I was quite impressed. I immediately noticed the Handbooks
    section[11], which contains all the official Drupal documentation and it seemed pretty much complete. No "under
    construction", "please write content here" or "we're a new project, help us write the documentation" notes, just a
    load
    of good-quality documentation, including a fully documented and <em>stable</em> API![12] </p>
<p>This surprised me,
    because some projects I came across, even really good ones, lacked a proper documentation section. I think this is a
    common problem with new open source projects, and Drupal for this reason gave me the impression to be quite mature
    and
    useable already. After visiting the very clear and organized Downloads Section[13], I downloaded the CMS and a few
    modules and installed it on my laptop.</p>



<h3>Installation</h3>
<p>Drupal needs three
    things to run:</p>
<ul>
    <li>A web server - Apache is fine, and ISS is reported to be working</li>
    <li>PHP - Either version 4 or 5, Drupal started supporting PHP5 since 4.6.0 release</li>
    <li>A PHP-compatible database - MySQL or PostgreSQL is recommended</li>
</ul>
<p>I used a WAMP[14] installation to test Drupal. First of all, I created a MySQL database, granting ALL
    privileges to the database user accessing the Drupal database. When I uploaded the site to the remote server, later
    on,
    I had some problems because the LOCK TABLES privilege wasn't granted by the host. Drupal requires this, so I had to
    contact my host to solve the problem. I then imported the database scheme located in the <em>database</em> directory
    under the installation directory and modified the configuration settings (sites/default/settings.php) to allow
    Drupal to
    access the database. Installation complete.</p>
<p>Drupal was now up and running with the default configuration
    settings, with a minimum of fuss. For all the details concerning the installation process, consult the exhaustive
    documentation.[15] I didn't read it when I installed it, but it can really be useful in some situations.</p>
<p>There are actually two non-critical things to consider if you're planning to use Drupal for a medium-sized project:
    the
    first involves changing a few settings on php.ini, in particular increasing the amount of memory allocated to PHP
    from
    8MB to 16MB, especially if you're planning to use either a lot of simple modules or a few complex ones, and the
    second
    is setting up your crontab to execute <em>http://www.yoursite.com/cron.php</em> every hour or so. This is required
    by
    some semi-essential modules like the site-wide search, but a common alternative (if you don't want to setup the
    <em>cron</em> task manually) is the poorman's <em>cron</em> module[15], which I used myself and found to be
    workable.
</p>
<h3>Keeping your site under control</h3>
<p>Perhaps one of the best things Drupal has
    to offer is a rock-solid general-purpose administrative backend. The first thing I found in the backend which really
    impressed me (and that also I never found in another CMS) is the ability to create <em>custom</em> role-based user
    accounts and access permissions for <em>everything</em>: every module can be configured so that, for example, not
    all
    people can see its output and just a few can administer and modify it.</p>
<p>For zZine, I created four types of
    accounts:</p>
<ul>
    <li><em>Administrator</em> - Able to access everything and change every setting of the site</li>
    <li><em>Publisher</em> - Able to write, edit and publish every kind of content on the site, but not able to
        administer user accounts, permissions and similar administrator-only tasks.</li>
    <li><em>Editor</em> - Able to write
        and edit anything on the site, but not to publish it.</li>
    <li><em>Writer</em> - Able to write articles, blogs and
        similar content, but in some cases not allowed to edit it.</li>
</ul>
<p>These were precisely the account types I
    was looking for in a CMS. Granted, other products offer them by default, but having pre-defined account types is one
    thing, and being able to customize them completely is another.</p>
<p>User accounts are great, but sometimes it's
    good to know what the users of your sites are doing as well. On our old site we had user accounts for editors and
    administrators, and even if only a few people had access we had no way to determine who edited an article or who
    published something unless that person told us. Drupal comes with a radical solution to this: Almost every action is
    automatically logged by the <em>watchdog</em> core module. Every website error, every page not found, and every PHP
    or
    MySQL error is logged, as well as every content submission or modification. Page accesses, meanwhile, can be logged
    through the statistics module.</p>
<p>Themes & Templates</p>
<p>"We shouldn't use a CMS: I don't want zZine to
    have the overly used *nuke-style look." I've heard this too many times. Sometimes people associate the word "CMS"
    with
    "lack of original design", and that's not true by any means, especially for Drupal. Of course, there are plenty of
    ready
    made themes[16] which can be freely used or modified for any Drupal-based site.</p>
<p>I must confess that when I
    first saw the themes section I feared that Drupal "themes" used their own template engine, like some CMSes do
    nowadays,
    but I was wrong: currently Drupal supports some template engines[17] but also pure PHP-based ones. Theme engines do
    their job wonderfully and can offer some interesting features, but templates written natively in PHP tend to perform
    better, simply because there's no extra parsing or additional overhead involved.</p>
<p>I decided to have a look at
    a standard PHP theme. Basically, it's nothing more than a PHP-enriched xHTML file and its corresponding stylesheet.
    There are a few functions which must be used to perform particular tasks, like showing the main navigation links,
    but
    nothing too hard to understand. It's also <em>very</em> customizable. In fact, we're already working on a custom
    zZine
    theme, which doesn't seem any harder than coding a standard xHTML template. As design should always be the last
    thing to
    worry about, I decided to use a temporary template I created by slightly modifying an existing
    one.[18]</p>


<h3>To switch or not to switch?</h3>
<p>When creating a new site for an
    organization which already has one, there's something very important to consider: <em>what happens to the old
        data</em>?</p>
<p>Assuming the old site was dynamic and using a database of some sort, there are three
    possibilities:</p>
<ul>
    <li>Don't bother doing anything: any data on the old site will not be transferred to the new one.</li>
    <li>Make the old website available somewhere else as an <em>archive</em> of old documents.</li>
    <li>Import all the data from the old site to the new one.</li>
</ul>
<p>Obviously we went straight for the third one, which is the most difficult to implement, but it was necessary:
    there were over 1000 articles on the old site-</p>
<p>Of course, in reality, I didn't even mention the possibility
    of using Drupal until I figured out a way to import the old data into the new database structure. Never praise
    features
    or convince people to switch unless you're 100% sure you can handle the situation. Luckily for me, it turned out
    that
    everything could be imported easily enough.</p>
<p>The first difference I found between Drupal and zZine was that we
    didn't really have proper user accounts. Every article had an author, but it was stored as a field in the article's
    record, and that was all. Drupal, on the other hand, supports (and perhaps requires) user accounts - everything
    present
    on the site must be written or edited by an existing user.</p>
<p>The solution I cam eup with was rather drastic: I
    created about 120 user accounts, retrieving usernames from the articles and inserting them through a custom PHP
    script
    into Drupal's user table. Of course, those users never registered on the new site[18], so I didn't personalize the
    accounts at all: I simply put a notice on the first page asking everyone who contributed to zZine before to contact
    me
    in some way to enable their account with a valid email address.</p>
<p>After this initial difficulty, importing
    articles was relatively easy. Pretty much every type of content in Drupal is, in its simplest form, a <em>node</em>.
    Nodes have a title, which is a teaser generated automatically from the body text, and an author (the node table in
    the
    database has more fields, but these are the key ones for us). Essentially, Drupal's two default models for writing
    <em>stories</em> and <em>pages</em> write data to this table only. The most important thing to understand about
    Drupal
    is that almost every module used to create <em>something</em> on the site - an article, a blog entry, even songs -
    will
    use the node table, and add everything else on other tables. This makes the whole system much easier to administer:
    every node can potentially be extended <em>in any way</em> by third party modules!
</p>
<p>What about categories?
    Well, Drupal has become famous for its taxonomy module: whereas most CMSes only support, or in fact <em>impose</em>,
    a
    one- or two-level hierarchy for categories, Drupal's taxonomy module supports the creation of as many different
    terms to
    describe data as you can think of. Each piece of content (categorization can be applied to <em>any</em> node, and
    since
    almost everything is a node-) can belong to none or <em>n</em> different categories, which can be nested in a
    <em>n</em>-level hierarchy. Since the zZine articles were already divided into categories, I imported all of them
    directly into Drupal. On the old zZine site, every article could have at most one category, which is fine, but it's
    good
    to know that we can now configure the system to support a more advanced categorizing system.
</p>
<p>After importing
    the articles, the last important thing to transfer to the new site were the zZine Publications. Publications are
    what we
    call the article collections that we release as an issue every month. I could have created a new module for this,
    and it
    wouldn't have been that hard, but there was already an excellent module for that. This was pure luck, but the
    <em>epublish</em>[19] module seemed like it was tailored specifically for our needs.
</p>



<h3>Drupal API
    and Modules</h3>
<p>We were lucky enough to be able to use existing modules for the main functionalities
    of our site, but in some cases you might not be able to find <em>exactly</em> what you're looking for.</p>
<p>In
    our case, even if we could have used the <em>story</em> module, which is part of the default installation, for zZine
    articles (stories have a body, a teaser, a title and an author, exactly like our articles) we decided not to. I
    wanted
    our editors and writers to know what to use when submitting articles, and the name "stories" sounds a bit too
    ambiguous
    for my liking. So, I decided to have a look at the standard story module to see how modules work, and create
    something
    similar.</p>
<p><em>Note: I'm curious by nature and I didn't read anything in the Drupal API[12], or about
        developing custom modules; I looked at the story module without any prior knowledge of Drupal's
        conventions.</em></p>
<p>All I found in the story module was a bunch of functions
    like:</p>
<pre><br />/**<br /> * Implementation of hook_node_name().<br /> */<br />function story_node_name($node) {<br />  return t('story');<br />}<br /></pre>
<p>which seemed to be enough to tell the Drupal core what to do. I was used to Mambo components, where developers have
    more
    liberty to do what they want, including outputting HTML code anywhere. Drupal is nothing like that; on the contrary,
    it
    has its own structure and coding conventions that developers have to follow when creating custom modules. Even if a
    simple function like the one above is fully commented, it has to have a standard indentation (two spaces) and an
    obviously standardized name. I noticed that all the functions similar to this one started with "<em>story_</em>", so
    I
    created a new file named <em>zzarticle.module</em>, copied and pasted the story module code into it, and changed
    every
    function accordingly, like
    this:</p>
<pre><br />/**<br /> * Implementation of hook_node_name().<br /> */<br />function zzarticle_node_name($node) {<br />  return t('zZine Article');<br />} <br /></pre>
<p>Trivial
    enough, and it worked fine! I put my shamefully copied module in the /modules directory and I was able to create
    "zZine
    Articles" (which were nothing but stories with a different name).</p>
<p>At this point I decided to have a proper
    look at the API, and read about hooks:</p>
<blockquote><em>"Drupal's module system is based on the concept of "hooks". A hook is a PHP function that is named
        foo_bar(), where "foo" is the name of the module (whose filename is thus foo.module) and "bar" is the name of
        the hook. Each hook has a defined set of parameters and a specified result type.<br /> To extend Drupal, a
        module need simply implement a hook. When Drupal wishes to allow intervention from modules, it determines which
        modules implement a hook and call that hook in all enabled modules that implement it. [-]"</em></blockquote>
<p>A <em>hook</em> was used for the previously mentioned function, and this was diligently
    commented:</p>
<pre><br />/**<br /> * Implementation of hook_node_name().<br /> */<br /></pre>
<p>This
    made me understand how Drupal is actually geared towards developers and at the same time suitable for non-technical
    users. Wait a minute, what if someone is not familiar with PHP and still needs custom modules and features? Is there
    any
    way to extend Drupal without having to physically code new things? Yes, there is, and two modules come to mind:</p>
<ul>
    <li><em>Webform</em> - allows the creation of any kind of web form. Users can customize field types,
        values, labels and messages. The module also provides ways to process forms by either saving data to the
        database or
        emailing it, which we can use for things like the Editor's Test and surveys.</li>
    <li><em>Flexynode</em> - This
        module is simple and powerful - it allows users to create their own content types without coding a single line.
        In
        my example, I cloned the story module to create the zZine Article content type. This is easy to do, and
        functional,
        but what happens if someone wants to include an additional field to the article submission form? I can probably
        do
        this using hooks, but if I was lazy I could do the same thing with the <em>flexynode</em> module. I actually
        used
        this module for our podcast section[20], and it did an excellent job.</li>
</ul>

<h3>Conclusions</h3>
<p>For now I must say I'm very happy with what Drupal has to offer, and
    if there's something we need for the site, we can code it ourselves and then integrate it into Drupal. </p>
<p>One of the
    major strengths of this CMS is definitely its developer-friendliness: while other CMSes mainly focus on users at the
    price of limiting extensibility and trapping developers into predefined modules, Drupal even encourages developers
    to
    integrate their code into the existing structure, opening virtually unlimited possibilities. Granted, it may seem
    difficult to understand at first, some people I talked to told me that 'Drupal is too complex' or has a rather steep
    learning curve, but I just think everything becomes clearer after reading parts of the vast documentation section:
    this
    is the only price to pay, and believe me, it is definitely worthwhile.</p>
<h3>Notes</h3>
<small>
    <ul>
        <li>[1] zZine Magazine: <a href="http://www.zzine.org">http://www.zzine.org</a></li>
        <li>[2] CyberArmy Community: <a href="http://www.cyberarmy.net">http://www.cyberarmy.net</a></li>
        <li>[3] Content Management System, Wikipedia page: <a
                href="http://en.wikipedia.org/wiki/Content_management_system">http://en.wikipedia.org/wiki/Content_management_system</a>
        </li>
        <li>[4] Xoops - Official Page <a href="http://www.xoops.org/">http://www.xoops.org/</a></li>
        <li>[5] Mambo - Official Page: <a href="http://www.mamboserver.com">http://www.mamboserver.com</a></li>
        <li>[6] CMS Matrix: <a href="http://cmsmatrix.org/">http://cmsmatrix.org/</a></li>
        <li>[7] Open Source CMS: <a href="http://opensourcecms.com/">http://opensourcecms.com/</a></li>
        <li>[8] Snarkles's CyberArmy Profile: <a
                href="http://www.cyberarmy.net/~snarkles">http://www.cyberarmy.net/~snarkles</a></li>
        <li>[9] Drupal - Official Page: <a href="http://www.drupal.org">http://www.drupal.org</a></li>
        <li>[10] Webchick's Drupal Profile: <a href="http://drupal.org/user/24967">http://drupal.org/user/24967</a></li>
        <li>[11] Drupal - Handbooks: <a href="http://www.drupal.org/handbooks/">http://www.drupal.org/handbooks/</a>
        </li>
        <li>[12] Drupal API: <a href="http://drupaldocs.org/api/head">http://drupaldocs.org/api/head</a></li>
        <li>[13] Drupal Downloads: <a href="http://www.drupal.org/project/">http://www.drupal.org/project/</a></li>
        <li>[14] WAMP Server Package: <a href="http://www.wampserver.com">http://www.wampserver.com</a></li>
        <li>[15] Drupal - Installing and Upgrading documentation: <a
                href="http://drupal.org/node/258">http://drupal.org/node/258</a></li>
        <li>[16] Drupal - Themes: <a href="http://drupal.org/project/Themes">http://drupal.org/project/Themes</a></li>
        <li>[17] Drupal - Theme Engines: <a href="http://drupal.org/node/509">http://drupal.org/node/509</a></li>
        <li>[18] zZine Beta site: <a href="http://beta.zzine.org">http://beta.zzine.org</a></li>
        <li>[19] Drupal - ePublish module: <a
                href="http://drupal.org/project/epublish">http://drupal.org/project/epublish</a></li>
        <li>[20] zZine Podcasts: <a href="http://beta.zzine.org/podcasts">http://beta.zzine.org/podcasts</a></li>
    </ul>
</small>