Once upon a time, website programming was a fairly arduous proposition. You could spend months putting together the various back end processing pages in ASP or PHP or Perl, writing included files that, if you were thoughtful about it, may contain some reuse, but overall writing such code by hand almost invariably meant that the code was not only very targeted to one particular use but was an absolute nightmare to maintain. Yet over time, many of the same lessons that had made their way into traditional desktop application development were also making their way into web development, albeit with the particularly declarative spin that tends to be a hallmark of web applications.
One consequence of this process has been the rise of web portal applications, built largely around the various blogging engines that emerged in the period from 2001-2006. While many of these are high end "enterprise" systems, perhaps the most significant of the open source platforms has been Drupal. Begun in 2000 as a tool for making it easier to create community blogging sites using PHP, Drupal has grown to become one of the dominant web site development tools, in large part because it encompasses a number of the same principles of development that REST proponent and Apache pioneer Roy Fielding laid out at the 2008 OSCon in Portland, Oregon:
- Build a core technology architecture that represents a foundation for the application, one that can be maintained rigorously over the course of the product's evolution,
- Make it easy to build plugable extensions to this architecture that won't collide with one another,
- Establish a community presence that can build such extensions, create documentation, and otherwise interact with one another, and as desirable move the most heavily used functionality of one generation into the core of the next generation.
- Maintain a rolling evolutionary model where at any given time you have a generation of fading functionality, a generation of active (stable) functionality, and an experimental branch representing new technology.
This model has been used successfully by Apache itself (the mod_ architecture), Firefox and of course Linux itself, but the model has also become the defacto one utilized by Drupal. By building the application in this manner, Drupal has evolved into a system where there are more than 7000 extension modules (and perhaps a thousand distinct themes) that are supported just by the Drupal organization itself, most contributed by outside developers who created the extensions for their own needs then contributed them to the community once the extensions reached a certain level of stability. These extensions, in turn, can be put together in a bewilderingly large number of combinations to create sites that run the gamut from blog sites to image galleries to application platforms.
Prepping a Basic Drupal Site
This diversity comes at some price, however - building Drupal sites can be either trivially easy or fiendishly difficult, depending in great part upon what you are trying to do and how many components you need to make that happen.
I recently put together a new website called Drupal Today, a community site intended to foster discussions and provide resources in the Drupal arena (a break from my usual XML-based efforts), with one goal of course being that the site itself would be Drupal based. Overall, I was able to put together a fully functioning multi-group site with blogs, wikis, twitter support, forums, a taxonomy cloud navigational system, authentication and AJAX support in about three days, much of which was involved simply in making decisions about design. I did, on occasion, have to do a little bit of CSS work and once I even had to break out my PHP books for some specialized tweaking, but overall most of the process was just creating the ideal configuration.
The biggest decision that needed to be made concerned which version of Drupal to use. At this stage there are four "active" versions - a 4.x branch which is now essentially just in maintenance mode, a 5.x branch which is the most heavily used, a 6.x branch which came online in the summer of 2008, and a 7.x experimental branch that's still pretty much for alpha testing and early development. This meant that the real decision came down to using either 5.x or 6.x. In June, such a decision would have been relatively easy, as the all important extension base was still fairly small, but that base has grown considerably since then - 2400 compared to about 4200 for Drupal 5. This decision is important, as the extensions generally are not cross compatible between versions.
In the end, I decided to go with the Drupal 6.x version, because I felt that it would let me showcase most of the first run development for new technology, but keep in mind your decision will likely be different. The Drupal 5.x version is quite stable and feature rich, and a fair number of 6.x specific plugins are also back-ported to 5.x, but 6.x is definitely where the majority of extension innovation is taking place.
Drupal 6.x requires both PHP (with PHP 5 strongly recommended) and either a mySQL or PostgreSQL database, and can run on Windows Server, Linux, Unix or Solaris systems. In my particular case, the web server was an Apache server running on a CentOS Linux box, so the code given here will be specific to that. Before downloading the Drupal code, set up a new empty database with at least one admin user (record the name of both user and database as you will need them). Download the Drupal application from the Drupal website (http://www.drupal.org) to your server directory, unpack it, and rename it to the name you will want for your base directory (or unpack the contents into your root web directory if the Drupal instance is the only web application running). The following illustrates the process for a subordinate folder named drupal:
wget http://ftp.drupal.org/files/projects/drupal-6.6.tar.gz gunzip drupal-6.6.tar.gz tar -xf drupal-6.6.tar rm drupal-6.6.tar mv drupal-6.6 drupal
Once unpacked, you will also need to set up a few permissions and copy some files. Specifically, Drupal is set up to potentially handle multiple sites. The folder ./sites/default (relative to the root folder) contains the relevant configuration files as well as a place for folders that hold additional files (such as images that are imported) during the operation of the site. You will need to copy the file default.settings.php in that directory to an active configuration file called settings.php (the former file is just a template), then change the permission to allow the system to update this folder once. You'll also likely need to create a new folder called files:
cd sites/default cp default.settings.php settings.php chmod 666 settings.php mkdir files
Finally, at least in my experience, you will need to change the local value of the register_globals variable used by PHP to off in order to insure that you have no global variable name collisions. Additionally, the default settings for memory allocation of a Drupal instance are deliberately set very low to start with, low enough that they tend to cause problems when developing more complex sites. The default is normally 16MB, but from experience, setting it to 64MB is usually a good idea. These are all done by creating a new file called php.ini within the Drupal root directory that contain the relevant instructions:
cd ../.. echo "[PHP]" > php.ini echo "memory_limit = 64M" >> php.ini echo "register_globals = Off" >> php.ini
The bash script prepdrupal (listing 1) contains all of these instructions, and should be run from within the web root directory where you will be placing your drupal instance by running ./prepdrupal drupalVersion drFolderName where drupalVersion is the version number and folder is the name of the folder within your root directory where you wish to store your drupal code).
#!/bin/sh # prepdrupal script # format: # prepdrupal versionnum folder # e.g prepdrupal 6.6 mysite # Copyright 2008 Kurt Cagle Under Creative Commons License wget "http://ftp.drupal.org/files/projects/drupal-$1.tar.gz" gunzip "drupal-$1.tar.gz" tar xf "drupal-$1.tar" rm "drupal-$1.tar" mv drupal-$1 $2 cd $2 cd sites/default if [[ $1 =~ "^5.+" ]] then echo "Version 5.x invoked" fi if [[ $1 =~ "^6.+" ]] then echo "Version 6.x invoked" cp default.settings.php settings.php fi chmod 666 settings.php mkdir files cd ../.. echo "[PHP]" > php.ini echo "memory_limit = 48M" >> php.ini echo "register_globals = Off" >> php.ini
Listing 1. The prepdrupal bash script
./drupal_setup 6.6 mysite
will retrieve the drupal-6.6 instance from the Drupal server and create a subordinate folder called mysite that contains the relevent code.
This may seem like a lot of prepwork (and to be honest, more of it could and should be automated than is), but it is likely to be (almost) the last of the scripting necessary to get the site itself running.
Configuring the Drupal Site
Once this is set up, the next step is to power up a web browser and navigate to the web page for your drupal instance. If the root for your website is http://www.myserver.com/ and you set up the drupal folder as "mysite" then the address of the Drupal instance is http://www.myserver.com/mysite. This web page will show you a startup wizard that will let you walk through each stage.
The first stage, setting up the database connections, involves entering the database type (either mysqli, which is the current mySQL interface through PHP, or PostgreSQL), the database name and the admin account for this database. This information is actually stored in the settings.php file, which is not normally accesible directly from the web, but as a matter of precaution once things are set up you should change the permissions of this file back to 444 to make it read-only.
Once you press the Next button, Drupal will update the settings.php file and other configuration resources, then will direct you to a screen to set up the first user account. This account is very important, as it is the only account that automatically has all permissions enabled. While other accounts can be set up, this account should be carefully protected and used primarily just for the initial configuration and design of the site itself.
After you set up the primary admin account, you will be sent to the "initial Drupal site" page, which is functional but currently has no content designed for it. As such, Drupal displays a welcome screen and set of recommendations. This screen will disappear once you actually create some content, but it is useful to understand the page that you see first as well as what exactly constitutes a "page" in Drupal before digging in and creating new content.
The simplest change you can make in your site (and one you should probably do to begin with) is to change the site's name. The Navigation menu, the outlined menu on the left-hand side, should include an Administrater link. Clicking on this brings up the administration page which is broken into five distinct groups of functionality:
- Content Management. These handle the creation and management of content types and nodes (Drupal documents), setting up news feeds, forums and and posting, controlling posting, and managing categories (taxonomies).
- Site Building. This area covers enabling or disabling modules, modifying menus, defining blogs (web components), changing themes, and if you use views or panels, will control these as well.
- Site Configuration. This section provides general configuration information both for Drupal itself and for most of the modeuls that are enabled. In general, when you add a new module, you'll go here afterwards to set the properties of that module.
- User Management. This area lets the admin see and modify the user information for the site, set privileges and roles, define groups (if the group modules is included) and related tasks.
- Logs. The logs section provides overviews of activity on the site, and can give you a way of checking that everything is running properly (or debugging the site if they aren't).
You can change the name of the site (and a few other properties) in the Site Information section within the admin's Site Configuration section. For instance, if you wanted to create a site called Drupal Today, then you would click on this link, change the Site Name property and click okay. The name of the site in the site's heading region will then change to reflect this name, though this changes the site name reference elsewhere in the program as well. From here you can also set e-mail address that system messages go to (something you should do immediately), change the slogan and mission statement for the site, change the name of the class of anonymous users (not recommended) and determine the starting page for the site. While this last feature can be very useful, leave it untouched for the moment.
Note that some themes display the slogan as a line beneath the site name and the mission statement in a box above the "river of news", but some sites don't display either one out of the box.
Both to get an idea about the underlying way that Drupal handles content and to understand the content creation process (as well as to help you get a visual sense for what your site will look like), your next step should be to create a story. Stories are one of the simplest content types in Drupal that contain full functionality. A content type should be thought of as a specialized document format, often with additional property components such as date fields or file upload capabilities that define the content type for a specific purpose. For instance, an Event is a content type that includes the same components as a story but that also includes beginning and ending date fields (among a few other things) that are used by calendars and other widgets to display critical information.
To create a story, click on the Create Content menu item in the left-hand navigation menu. This will expand (after a page-refresh) to show all of the content types that you can create. Out of the box, this list is pretty slim, but that can be changed easily when you start working with modules. Click on the Add Story link to bring up the Add Story page.
Most Drupal content creation (and content editing) pages look remarkably similar. The Title control lets you set the title of the story in question, and usually doesn't let you use markup. This title is important because it is what will appear not only at the top of the story but also in lists showing this article.
Beneath this is the Body control, where you actually add content itself. This content can be simple text with line breaks, it can be a limited HTML subset, it can be other specialized formats such as Bulletin Board Code (BBCode), Wiki markup, full HTML content, XML or other input, depending upon the input type assigned to the content type. An input type is a collection of filters that are applied to the body to apply markup code or even enable functionality. For instance, it's possible to create content types that will take a link to a YouTube video page and use that to actually create the code to embed the video within the page. The default Drupal installation includes three filters available to the administrator - Filtered HTML, which includes basic HTML markup such as bold or italic tags but that also converts line breaks in the source into paragraphs in the display, Full HTML , which just renders the HTML content as is in the output, and PHP Code, which lets you embed PHP markup in the page itself.
The Menu Setting section in turn is used if you want to add this story to a menu (and should be ignored for now). Authoring information is used to set the author of the story in question, which usually defaults to the user who created the node. This is more handy from an administrator's standpoint if you want to change the author in question (especially useful if the admin maintains a separate "public" face on the site), or to change the publish time. Finally, Publishing Options lets you set whether you want the story to be made publicly visible (published) or not, whether you want it to appear in the default "river of news" section and whether this article should appear at the time of this river (its stickiness) or similar lists. If you are working on an article across multiple edits, then you may want to set published off, but otherwise its usually safest to leave the defaults as is.
A story is an example of a Drupal node, a concept that plays a significant role throughout Drupal. In database terms, a node is a simple entry in a table that contains the core information described above - title, id, body, author link and so forth. Modules can reference this basic node and add additional terms via joins, essentially adding to the functionality of each node content type while providing a common reference form for all content. This in turn makes it possible to do such things as aggregating different content types, cloning a given node, converting a node from one content type to another and so forth without having to create specialty operations for each type (a kind of quasi-polymorphism for object oriented programmers out there).
One upshot of this is that it is possible to express all or parts of node in different forms. You can render a node as a page, where the title and full body content are displayed. You can render a node as a block, a "drop-in" component or widget view that will display collections of zero or more nodes in lists, tables or grids. You can use a collection of nodes to create an RSS feed, or you can aggregate nodes under distinct categories (with the use of the taxonomy module) in order to provide things like tables of content or related content "widgets". It's the process of breaking the content (the title and story of the node) from the presentation (tables, lists, tables, full pages, RSS feeds, etc.) that is a major part of what gives Drupal so much flexibility.
Enabling Modules Within Your Drupal Site
The core capabilities of Drupal are actually quite minimal, serving primarily to provide the glue by which the various modules work together. What this means in practice is that almost any Drupal site is primarily then the sum of its extensions - by changing which extensions are enabled, you can create a wide range of potential websites.
Drupal extensions are written (typically) in PHP, though they may also include SQL code for communicating with the database. Most of them work with the Drupal API, a published command language that lets developers access specific content relative to the context of the page (and block) that the user is viewing at the time. For the most part, however, unless you are specifically involved in creating extensions, the chances are good to excellent that you will not need to write any PHP yourself - though if you do become a Drupal addict, the temptation to get under the hood will likely eventually strike.
Out of the box, Drupal ships with a number of modules ... however, very few of them are actually enabled. Fortunately, enabling modules is very simple - go to the Administer section, then in the Site Building menu, select Modules. This will show each of the modules that are currently enabled for your Drupal site. There are a few that may not be enabled that you may want to turn on, for specific functionality:
- Aggregator. This lets you read RSS feeds from external sites and display them as content. It also lets you aggregate feeds, combining two or more feeds. In order for this to work, you will also have to enable cron to call the $drupal_root/cron.php page periodically. A good introduction to cron can be found at http://www.sitepoint.com/article/introducing-cron/, while the specific cron command to invoke will look something like:
/usr/bin/wget -O - -q http://EXAMPLE.COM/cron.php
- Blog. This sets up a specific blogging content type, and also provides hooks for other routines to list and display information about the blogs and blog users.
- Blog API. This is one of the more useful modules because it sets up the necessary services so that you can post to a Drupal blog from a remote blog editor. This means that you don't have to use the Drupal interfaces to blog content.
- Book. It's possible to create collaborative documents (the Page content type) in Drupal. You can think of a page as being something like a Wiki page - multiple people can edit it. The Book interface provides a way of tying these pages together into a larger overall book.
- Forum. This sets up the necessary back end code to enable Drupal forums. Drupal forums are minimalistic - perhaps too much so - but because they are integrated into the rest of the Drupal system this advantage can outweigh their functionality. You may also want to augment this with the Advanced Forum module, which will give you many more of the features associated with higher end forums.
- Menu. This controls the menuing system, and should usually be enabled.
- Poll. This provides a poll content type used to ask questions of your user base. Polls can be silly, but they are also useful in actively run sites to determine community intent.
- Search. This implements a reasonably sophisticated indexed search system within your Drupal site, and should usually be enabled.
- Taxonomy. Taxonomy is perhaps one of the most powerful of the modules, though similarly one of the more difficult to understand. It lets you create categories within Drupal and assign specific terms within those categories to specific content nodes. Taxonomy can create an additional (or alternative) navigational system, but it can also be used to organize content. Taxonomy will be covered in a future article.
- Tracker. This is a rudimentary sorting system for tracking new content, though most of its functionality has been superceded by the Views module.
- Upload. This rather necessary module lets you upload content to the site. It is used extensively by Drupal, and access can be controlled by the Administer/Users/Access Control section.
With these enabled, your Drupal site will have what amounts to the "standard" configuration, supporting forums, blogs, and wiki-like books, among other things. While this is a good starting point for any site, it is worth taking the time to show how you can add in additional modules.
One area where Drupal's out of the box configuration is somewhat weak is in the arena of images. It's possible, with the Upload module, to attach images as files to nodes, but there is no provision to actually display them. This is where the Image module comes into play. The main Drupal site has a modules section that includes the "approved" Drupal modules - those that have been specifically made available through Drupal itself. The modules are broken up by category at http://www.drupal.org/project/modules and by name at http://www.drupal.org/project/modules/name. If you're willing to wait a while for the full download, pulling in the list by name is usually the fastest way to pull up content, though the Drupal module site itself could really use a two-pane table of contents. The default mode for displaying these modules is to show everything for all versions, but if you create a free account you can also filter the content to just show the listing for one or another ve-rsion. Remember that regardless of which version you choose, you have to choose modules that work for that version (i.e., have a major version number the same as the version of the Drupal instance itself).
If you have a GUI access into your web host, the easiest way of adding modules is to download the modules, unpackage them, then copy the resulting folders to the modules folder. However, in many cases you may be limited to just an SSH connection to your site. In this case two more Drupal scripts may prove enormously useful to you - getmodule and batchmodles. The getmodule script retrieves and unpacks modules and themes, making it possible to quickly add these resources to your underlying distribution and is shown in Listing 2. The same routine can be used for both modules and themes.
./getmodule url_to_module # For instance, to load in the image module, cd to the modules directory and run: ./getmodule http://ftp.drupal.org/files/projects/image-5.x-1.9.tar.gz
and should be copied into the modules and themes directories.
#!/bin/sh #getmodule bash script mkdir -f downloads cd downloads wget $1 . gunzip *.gz tar xf *.tar rm *.tar mv * .. rm -fR * cd ..
Listing 2. The getmodule script.
With more sophisticated sites you may find yourself adding a number of modules at once. In this case, it is easier to create a separate file with one module URL on each line, then pass this file into the batchmodules script, given in Listing 3.
#!/bin/bash # batchmodules script while read module do ./getmodule $module done < $1
Listing 3. The batchmodules script
In this case, if the URLs are given in a file called newmodules.txt, you'd call this routine as:
Once you've added a new module, you still have to enable it. This involves going back to the module page and checking the modules in question. Note that in comes cases a single module package may actually expose several distinct modules.
You should also, once you save the newly enabled modules, check the Administration Site Configuration page. In many cases, you will need to perform some additional configuration of modules in order to get them to work properly with your particular website - including setting security configurations, enabling specific functionality, or pointing to (and creating) folders that may not be part of the initial build.
While the out-of-the-box configuration is pretty good for setting up a simple community forum, there are a large number of additional modules that can turn a fairly humdrum site into a remarkable one. Indeed, there are a number of modules (or module "families") that are considered so essential that they are typically used as the foundation for other modules. These optional but recommended modules include the following:
- Views. In SQL parlance a view is a saved SQL Query. This terminology carries over somewhat to the views module, which makes it possible to show a collection of content nodes that satisfy a given SQL query. In most cases, this query is generated through a formal GUI, which means that you can create views to do anything from getting a listing of all images uploaded by a given person to show all events falling between two dates, with the possibility of displaying this content as pages, blocks, RSS feeds or other formats. Views includes a number of other modules for extending the base views package to do things like join two views, create hierarchical views, create additional output types and tie in views with taxonomies. Views should be considered essential for any complex web development effort with Drupal.
- Panels. In a normal theme, layout is relatively fixed - you can control the default locations of blocks and on which pages they appear in the site, but you don't normally have much control beyond that. Panels give you both course and fine grain control over the location of components, and lets you override the existing layout for a given URL or URL pattern. You can create panels within panels, can control panels via arguments in the URL and can apply complex CSS and AJAX over these panels independent of the overall site's layout.
- CCK. The Content Construction Kit makes it possible to create new content types by adding specific properties. Each of these properties has two "faces", an interior editing face and that's typically used for setting the value of the control, and an exterior display face that shows the property in a certain format. CCK makes it possible to create any number of new content types, each of which are customized for a specific purpose. For instance, you could use CCK to build a user profile page, a job listing, an article with specific workflow states or an event listing, among many other possibilities.
- Taxonomy. The default taxonomy module makes categorization possible. However, there are a number of taxonomy extensions that build on this functionality in a variety of ways, from creating "tag clouds" to adding default or "other" states to a taxonomy to matching taxonomy states with various images.
- Image. The image module is the foundation for a number of image display and processing modules included with Drupal, and its a little hard to understand why this particular functionality isn't part of the core. If you do anything with images on your site, you will likely be using the image modules and one or more additional imaging tools.
- Filters. Drupal uses filters to read the body element in a node and replace certain text expressions with markup content. Beyond the default filters in the core set, Drupal's filters include the ability for authors to use Bulletin Board code (BBCode), Wiki code, node, image and view insertion elements, smileys, embedded video and audio and xml content, as well as custom regular expressions that you can use define specific additional functionality.
- Drupal Administration Menu. This DHTML menu can prove extraordinarily useful to Drupal developers, as it takes the administration side menu and turns ot into a multi-level drop-down menu that appears on the top of the screen as an overlay on the screen (and only visible to the administrator). Once you get heavily involved in putting together Drupal sites, you tend to jump from section to section in the Admin section, and this simple module can prove a real time saver.
While this is a good list, its also hardly representative. Every Drupal developer no doubt could add a few of their own favorites to this list, or may have some profound reservations about one or two of them on a site. These are generally useful, though, and often also provide you a convenient jump start to move from basic sites to serious ones.
Theming Your Drupal Site
The Garland theme is an example of a three column arrangement - a header area, fixed width left and right columns and a larger central column, and a footer ... though in the initial view, there's no content in the right hand column. The header contains the name of the site (which starts out as Drupal) and an icon (the raindrop guy, as Drup is Dutch for "drop"), a birdcrumb navigational control showing the location of the page relative to the rest of the site, a search control, and the primary links menu at the time, used for setting the primary location of items. The left column holds the primary navigational menu, including the all important administration section, and log-in and log-out entries. The center column is known as a "river of news" because the default view, when it has content, is to show titles, pictures and short summary content (what are called teasers) in order of descending post dates. The footer then contains copyright information or page count graphics.
Most people have a fairly intuitive understanding of what a theme is and does, though the level of customization via themes varies considerably from application to application. In Drupal, theming is more than just changing out a CSS page. Typically, a Drupal theme consists of a number of php pages that include both an HTML layout of the core site which divides the web page into different divisions, along with PHP code that identifies these divisions programmatically and CSS code that them provides the visual presentation layer.
The effect of this is that while there are usually standard zones that remain constant from theme to theme, it is also possible for themes to add additional zones, or to move zones from one region (say a column on the left side of the page) to another (a column on the right hand side, for instance). For this reasons, Drupal themes are extremely malleable. Since content is in turn added to these particular zones, it also means that one theme may implement the primary menu at the top of the page, while another may run it vertically down one side of the page, or perhaps not even show it altogether. Not surprisingly, you can add blocks to given zones fairly easily within the Admin/Site Building/Blocks section.
In the same Admin/Site Building Section is the Themes menu-item, which lets set the current theme as well as indicate which themes are enabled if users can change a given theme themselves. Drupal comes with a half-dozen distinct themes (along with a few variations), and changing themes usually just involves clicking on the desired theme and clicking the OK button. The theme will change immediately thereafter.
The Drupal folder includes a child folder called Themes which contains all of the themes available for the site. You add themes in exactly the same manner as adding modules (and you can use the getmodule command within the themes module itself), with themes located at http://www.drupal.org/project/themes. Again, as with modules, themes are version specific - most Drupal 5 themes will not work in Drupal 6 and vice versa, so you should set the version before selecting the relevant content
Most sites fall into either table or tableless types, where the former obviously use HTML tables and the latter rely upon CSS to fix the position of elements. Additionally, sites layouts are frequently indicated as being either fixed, meaning that the column widths and position are static, or fluid, meaning that the layout changes size whenever the screen width is increased or decreased. Drupal 5 has more than 220 themes defined, while Drupal 6 has about 60 (though these numbers may change by the time you read this article), and as with modules, your choice of theme should generally be dictated by your particular requirements.
One of my personal favorite themes is the LiteJazz theme, which is a fluid, CSS-based format that has a nice color balance, makes effective use of the primary and secondary menus, and has a number of zones or divisions to allow for fine grain layouts. The Zen theme is a good starter kit if you are looking at creating your own themes (ultimately recommended, but get some experience with the way that Drupal works first). Newswire is good for news-centric sites (and reminds me a lot of the older O'Reilly layout), while themes such as Tendu, Sky, Pixture and others tend to reflect the rounded edge, minimalist designed themes that seem to be considered the model aesthetic in this day and age.
About Drupal URLs
One of the more useful aspects about Drupal is its intuitive URL system. Drupal works in part because it is a very RESTful system - it's designed around the concept that URLs should have a strong correlation with resources and that there should be as little "RPC"-like characteristics within the URLs as possible. To that end, most web pages are specified by a single query parameter (named "q") that points to respective resources. For instance, the first node page that's defined in the system would be qiven as mysite?q=node/1, the second would be mysite?q=node/2 and so forth.
However, this system is also considerably more powerful than may appear on the surface because the query URL can pass considerably more sophisticated information. For instance, if you wanted to add a new blog post, the URL for that post would be ?q=node/add/blog , while editing that same post (if it were the third node listed) would be given as ?q=node/3/edit. This notation is carried further in the case of adnimistration pages - the module page is given as ?q=admin/build/modules, while the page for reviewing the content that a given user has created is ?q=admin/content/nodes.
This capability is augmented in Drupal by the Path module (part of the core Drupal module set). Path lets users assign their own URLs to various pages, so that you can create specialized entries based upon your own URL scheme. Views are able to parse these paths as well, which means that if you create a page with the URL members that lists all of the members in a given grouping, then you can also create a URL members/jane_doe that would specifically bring up a members page for that one person using a filtered view, with jane_doe being passed as a parameter.Similarly, you can use the Pathauto extension module in order to use the title of an article (or some shortened form thereof) to automatically assign a title.
Moreover, these path aliases do not eliminate the normal node numbering URL which is assigned as a permanent (and non-collisional) URL for the resource. Thus, the page members/jane_doe would still have a permanent URI assigned the moment that the page itself is instantiated once (for instance, if this was node 125, then the page would also have the URL node/125). This makes it far easier to create archival entries, and to create permalinks.
Taking the Next Step
Drupal has a reputation for being fairly complex and difficult to learn, though this tends to be true for most flexible systems. It's not a completely unfair statement - while creating an out of box site is reasonably simple (and can usually be accomplished in as little as an hour) creating a full community employing a hundred or more modules can be a fairly significant undertaking. On the other hand, one of the real strengths of Drupal is that you can "evolve" the site ... adding a certain amount of new functionality until you have something that you feel comfortable with, then expanding upon that over time. Additionally, it is possible to build a distributed Drupal site that can actually span multiple systems with the alias and redirect capabilities.
In general while proficiency with PHP can prove useful on occasion, it is not a prerequisite for successfully building a Drupal site. Indeed, one of the aspects that people like so much about Drupal is how seldom it does become necessary to dig into the innards. In one site that I built and maintained over the years, I can think of perhaps four times where I wrote PHP code, and none of that was in mission critical areas ... and in two of those instances, I later tore out the functionality because a module existed that did the job better than my hack job. Indeed, perhaps the biggest challenge with Drupal is staying on top of the new modules as they are published to the Drupal site.
Drupal also tends to suffer the same problems that most open source projects do - because Drupal is community based, its documentation tends to be inconsistent, some of it brilliant, some of it execrable. Sometimes the modules function as advertised, sometimes they have dependency problems that a good testing regime would fix, though in general the Drupal organization is very careful to label a module as being recommended (as opposed to under development) when it has run comprehensive tests on it. Moreover, Drupal does not necessarily have the flash and sexiness of commercial products. On the other hand, for sheer breadth of functionality, it easily outclasses both commercial offerings such as Microsoft Sharepoint as well as more focused blogging CMS systems such as Six Apart's MovableType, in great part because it was conceived from the ground up as a framework for building communities, rather than being a special purpose tool for building forums or blogs or acting as a repository.
Drupal is an open source community project for building communities. As such, Drupal enthusiasts are just that - quite enthusiastic about their technology and dedicated to making it work for their needs. The system is a test bed for trying out new ideas in the social networking space, and it's not unusual for a Drupal module providing an integration support for a new service (such as twitter or xmpp or Facebook APIs) to appear within a few months of these technologies reaching their own critical mass. As such, Drupal can integrate well with many other social networking applications, and while it usually doesn't do any one thing as well as the dedicated hosts, its ability to act as an integrator and middleman makes it well positioned to bridge other communities.
For that reason, among many others, I feel confident in recommending Drupal as the foundation for a support or community generating site for companies and organizations alike. It has a good-sized, growing developer base, it's open source foundation is attractive in a time of cost-cutting, its community model translates into a wide variety of well-tested modules and components, it scales well, and overall it can be used and deployed without specialist (programmer) knowledge, something that really doesn't exist outside of Drupal (Sharepoint comes perhaps closest, but Sharepoint doesn't have the depth of functionality, in my opinion). It has drawbacks (the use of PHP arguably being one of them, as well as the inconsistent state of documentation), so it is not a perfect solution, and it may not be appropriate for those companies or organizations that feel they need to have extensive commercial indemnity and customer support (something that I suspect will change as the Drupal community itself grows).
Indeed, companies like Rain City Studios in Vancouver have established strong backgrounds as commercial Drupal developers, and Warner Brothers and Disney have both begun using Drupal as the foundation for their own community development processes. Recently, Google and O'Reilly media awarded Angela Byron (aka Webchick) the Open Source Best Contributor Award at OSCON 2008 for her extensive work in promoting the Drupal community (and Angela is the lead author for the recently released Using Drupal, published by O'Reilly). What this tells me is that Drupal has gained some serious adherents in both the business and open source communities, and only affirms its growing popularity.
For more information on Drupal, check out the Drupal website at http://www.drupal.org. This article is the first in a series about the design and deployment of websites using Drupal.