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.