I've noticed what I think are becoming clearer segregators between the Drupal, Habari, and WordPress platforms; some details that differentiate the products more in my mind than they had before.

Drupal is constructed to let users build sites entirely from its UI. Much effort is made to make it unnecessary even to write any HTML code, yet still allow users to configure the type and quantity of data fields assigned to their content. Users can set options to determine the layout and formatting of output.

As a result of Drupal's user-configurability though, any little things that fall outside of what the system can do for you are often crazily more complex to apply than other systems. For example, if you want to apply any special formatting to a field of data that is entered on a node, you must write theme functions or alter a template's output of that field. This is often a more complex task than what would be required to output the same data in other systems, which is explicitly what Drupal is trying to avoid in the first place.

WordPress is constructed to have a fairly fixed set of data, in comparison to Drupal's field flexibility. By doing so, it can confine the user to a very strict set of data to output via a finite set of specific PHP functions - aka "Template Tags". This is a benefit to people producing WordPress themes because it gives them the flexibility to design HTML and CSS code, and then insert the functions for data output into predefined spaces in their templates.

WordPress is different from Drupal in that it assumes you will want to edit the template code to change the output, rather than configure the organization and display of data from inside the software. As a result, WordPress' code must stay simple to appeal to users who wouldn't otherwise grasp database design, and so would likely never have the level of data configurability that Drupal offers.

Habari is constructed to have a reasonably fixed set of data, more like WordPress than Drupal. A key difference though, is that Habari doesn't confine itself to simple tags for the benefit of non-coders. By leveraging an assumption of some coding ability, or at worst, the ability to cut and paste existing working code snippets that produce effective output, more dynamic data can be extruded and manipulated from the initial basic offerings.

Unlike Drupal, Habari is not designed to allow users to change the layout or presentation of the data on the page. Like WordPress, Habari assumes that a theme designer will want more control over the layout of output than could be provided by a generic UI. Still, in many cases, Habari requires that theme developers have a more developed coding skill to make use of the tools that it provides.

This session intends to create a simple news site using Panels 2 and Nodequeue. The idea is that the news comes into the site in blogging fashion faster than a "river or news" style would be able to keep it effectively on the home page. Instead of that kind of display, the idea is to display new news in panel areas as only titles in major sections that lead you to an expanded display. To accomplish this, you can employ the Panels and Nodequeue modules.

Panels give you more control over varied content views, and give tyou the ability to style the content. They let each pane know about data on the page that appears elsewhere.

Nodequeue lets the editor control the publishing order of new nodes. The editor can also control the length of the content, and pairs the content with the taxonomy for organizing its display.

A "queue" is basically a line, like "when you stand in line". You can use this feature in the nodequeue to push things at the front of a queue off of the end so that you can cycle the newest nodes onto the page. This allows the node to manage itself instead of having to "unpublish" expired items to get them to disappear from display.

Assigning taxonomy terms to new nodes will allow them to appear in different queues, and therefore in different areas of the site. To do this, you need to adjust how to display you Drupal home page, because usually you have the page.tpl, and the main content of the page is just the main content. To get around this, you set the main content to be a set of panels.

As a result, you can choose to display a nodequeue in any particular panel using whatever criteria you want.

The basic idea of this session seems to be how to get over the difficulties of Drupal shops working together. The general consensus in the room is that most Drupal shops are 10-15 members. Working with other groups is not just about collaborating on a client project, but also collaborating with groups that are responsible for published modules.

One of the primary blocks for shops working together is communication between collaborators. By keeping the communication channels open, things like duplicated module work can be avoided. Keeping the plans open in spite of competitive differences that might otherwise prevent collaboration.

This can be accomplished by blogging what you're doing to an internal back-channel. Do research before you start coding, and document what you all need to do so that the scope of work for each person is clear.

Also, if you're working on a module that others might use, be sure that you publish a path to completion or a list of things you might do in the future so that others who use your work know the direction you're heading in.

Using the correct tools, like blogs, offer unexpected benefits to collaborative efforts. Traditional tools like CVS can also obviously allow you to collaborate better with other groups.

Maintaining modules that you develop in congress to prevent them from languishing in client projects is one way to benefit from collaborating with other Drupal shops. By maintaining the modules together, you could re-use those modules later in future projects.

In my first attended session at Druaplcon 2008, speaker Chad Phillips started out with the basics of Drupal features including forms and the idea of separating presentation from content with themes.

Obviously, if you're going to be developing in Drupal, you're going to want a place to do the coding. Setting up an AMP (Apache + MySQL + PHP) stack locally is a quick way to set up a development environment that can be modified without mangling your production site. Versions of AMP stacks are available or Windows, Mac, and Linux as WAMP, MAMP, and various basic linux installs. The usefulness of phpMyAdmin on the local site is not to be overlooked.

For coding, a programmer's editor is really required equipment. When choosing an editor, choose one with debugging support and one that lets you code closer to the machine, so that you can edit things directly on the server if need be.

Using code conventions is important because in makes code reading common across developers. Increases security because its more obvious where errors are if the code is organized correctly. Makes it possible to commit changes to core code.

Where to get Drupal help when you can't figure it out: One place is the Drupal.org site itself. Get support with specific common topics at /support and /handbook.

Drupal also has support via IRC. Use #drupal for general topics, #drupal-dev for discussing specific development topics, #drupal-support for questions starting with "How do I...?", and #drupal-themes for help in building themes.

The Drupal Dojo has screencast videos to provide training to users. Check out drupaldojo.com

Drupal's own API Module helps with code documentation and PHP documentation by creating references from the PHPDoc comments in the code. This is an interesting module in deference to PHPDocumentor, which pulls the same kind of information, but this integrates it into actual Drupal output. Using this module locally allows you to develop locally without requiring access to the internet, so you can develop on a plane and still access the API documentation. Running the API module with locally installed modules will also bring in all of the documentation from those modules, which you normally aren't able to get from the Drupal.org's own public API reference.

The Devel module is a helpful development module that allows you to completely clear the Drupal cache on demand. It can present to you a list of variables in the variables table, and let you change the value of those variables. It can capture emails that Drupal tries to send, and store them in the log without sending them, which is really useful if you've got a local site running for development and don't want to email your clients while you're testing. The devel module can output all o the queries that run for a single request, showing all of the replaced values and the duration of query execution. When it displays the queries, it can filter them to show only the ones that take longer than a certain amount of time, so that you can optimize them to increase page load speed.

The devel module is what you can use to display a call stack and backtrace in an error which is rather helpful for sorting out really hairy issues. There are quite a few useful features in the devel module for development, and it may be worthwhile to look into whether you're doing actual development or just building a site. The devel module has additional features if you're using Drupal 6, including theme editing.

The Content module allows you to create a bunch of sample content without having to create nodes that have Beastie Boys' lyrics.

A Coder module helps you code to coding standards and can assist in upgrading your module code between versions of Drupal. Another session will cover this module in more detail, so this one wasn't covered at length, but sounds interesting.

The Simpletest module will automate unit testing by executing test classes that you write to test your modules. Another session will go into detail on this module as well, and I'm thinking of attending that one later.

Chad offers these tips: Learn how to use CVS by reading the CVS handbook at drupal.org. I'm not sure how learning about Drupal's CVS structure is useful for you own Drupal development, and would actually prefer to keep my code in Subversion because, in my opinion, it is superior to CVS. Chad didn't really detail why you need to know this, but I suppose it would be handy if you were going to contribute to Drupal or contributed modules directly, since everything in Drupal is still using CVS. Knowing Subversion basically gives you the knowledge you need to use CVS, so better to learn the better tech and then use CVS only when it's necessary, I feel.

One thing he does cite as an advantage in reviewing Drupal via CVS is being able to see intended changes in future versions of Drupal and its modules. A diligent eye would be required to keep track of this kind of thing.

One thing Chad says about Subversion is that Drupal has many man-hours invested in using CVS as a tool, and that there are project management features that are integrated into Drupal as modules. Since these all depend on CVS, changing Drupal repos over to Subversion wouldn't be as simple as switching just the repo, but also all of the dependent modules that publish API deocumentation and such from the Drupal.org site. Very time-intensive.

Cool tip: Copy the first two lines from Drupal's main index.php to a new file, and add anything you want after that to test its working in Drupal with the full functionality it provides. It allows you to test easily without running everything and producing page output. You don't get all of the nice themes on output (unless you call them), but you do have access to things like the database and any active module. Great idea for debugging a tricky snippet of code.

Chad finishes up with some basic debugging information, using exit() and print_r() for testing.