60 minutes

Overview

Drupal 6 includes a simple lazy-loader for page callback functions. Drupal 7 will feature a completely automated introspective code registry, allowing Drupal to skip the most time consuming part of a page request: The bootstrap. But how can you structure your modules to take full advantage of this new world?

Join Larry Garfield (Crell) and chx (chx) to discuss and develop a set of best practices for module design to take optimal advantage of the registry. Expect some discussion of OOP practices as well, since it's Larry and chx. :-)

Agenda

* What the code registry is and why it is. (Larry and chx)
* What the code registry is not. (Larry and chx)
* OK, so how do we use it? (discussion)
* Draw up recommended guidelines to be included in the handbooks.

Goals

You should come away from this session knowing how to speed up your modules dramatically through a simple cut and paste operation. We also intend to have a publishable set of guidelines for all module developers to help them do the same.

Resources

Past discussion and issues:

http://drupal.org/node/146172 (Drupal 6 page callbacks)
http://www.garfieldtech.com/blog/benchmark-page-split
http://drupal.org/node/221964 (the registry issue)
http://www.garfieldtech.com/drupal-7-registry

Overview

This session will discuss how Drupal finds and renders pages. In other words, how a Drupal path (like node/4) is used to deliver a page to your screen. This will be a high level discussion, but with some reference to implementation details.

Agenda

• Overview of the menu system architecture
• The flow from request to page rendering in Drupal 6
• Page rendering in Drupal 7
• Alternative page renderers - e.g. XML and JSON
• What we've enabled, what's left to do

Goals

This session should give the participant an overview of how these central Drupal systems work in Drupal 6, and how they may change in Drupal 7. We will focus on how page rendering may change, and what other advances those changes enable.

Resources

It would be helpful to have a basic familiarity with how pages are defined using Drupal 6 hook_menu, and what a Drupal path is.

Overview

The navigation menu, breadcrumb links, primary links, etc are important for users to be able to navigate your site. Is the way they work in Drupal 6 optimal for usability? Are there better default behaviors we could build for Drupal 7? Could we better accommodate non-standard browsers (e.g. screenreaders)

Agenda

* Fixes up to now (e.g. http://drupal.org/node/270917)
* Default markup
* Your suggestions and input!

Goals

This session will focus on Drupal core, not on contributed modules which can alter or enhance the built-in menus and taxonomy.

By identifying usability problems and possible fixes, this session will hopefully result in some fixes being identified to be addressed in core.

Resources

You should have used a Drupal 6 installation and thought about how you navigate using menus and taxonomy, and how you arrange or assign menu links and taxonomy terms.

If possible, think about "scalable menu parent choosers" and hierarchical select widgets. See: http://drupal.org/node/191360

Usability testing at the University of Minnesota and University of Baltimore suggested that new Drupal users would benefit from more example content in default installations. There are also technical limitations to install profiles which have prevented their widespread adoption in contrib.

This workshop will examine the existing 'default' installation profile, the 'minimum' installation profile (if it's committed by then), and discuss additions to these and other possible profiles for core (single user blog etc.)

The session will also discuss the current limitations of install profiles for developers, and look at alternative mechanisms ('packages', 'install profiles as modules').

Resources:
More defaults in the default install profile: http://groups.drupal.org/node/11691
RFC:Installation profiles as modules: http://groups.drupal.org/node/11548

Overview

The menu API underwent major changes between Drupal 5 and Drupal 6. Now that it's been in use and modules have been updated, do you see areas of the API that need improvement? Bugs that are showing up? Performance concerns?

Agenda

• Introductions
• Developer experience (DX): could it be easier to program menus?
• Dynamic tabs
• Breadcrumb handling
• Allowed depth of the links tree
• What do other components of the Drupal framework need from the menu systems: e.g. semantic web, alternative renders, etc.
• Time permitting - Drupal 6 coding questions.

Goals

By the end, we hope to have identified specific features there there is a consensus around, and ideally have an implementation plan.

Resources

This will be a detailed, code-level discussion. You should be familiar with the menu hooks and page-serving mechanisms for Drupal 6 ahead of time.

Overview

This session will focus on strategic tips and tricks for creating visually stunning and highly functional Drupal sites in collaboration with creative partners and colleagues. We will discuss various dos and don’ts associated with designing for Drupal and building custom Drupal themes.

Agenda

* What best practices should you follow when designing for Drupal or building Drupal themes?
* How to communicate with in-house and external design teams when building sites in Drupal
* What’s a good process workflow for building Drupal themes?
* What things can you do to make your life easier when developing Drupal sites? What things will make your life more difficult?

Goals

The goal of this session will be to help people involved in Drupal theme development and/or creating designs for Drupal sites understand the unique challenges of the system and learn how to develop a good workflow and set of best practices that will enable them to create sites that work and look their very best.

Overview

Most Drupal security vulnerabilities are discovered via manual code reviews or by accident. This session will introduce two automated approaches to detecting Cross-Site Scripting (XSS) and SQL Injection (SQLi) security vulnerabilities and present progress to date in applying them to Drupal.

Dynamic Analysis, or "data tainting," involves tagging actual data within a running program received from untrusted sources as "tainted," propagating the taintedness to any data derived from tainted data, and detecting when tainted data is used in dangerous circumstances. For example, data tainting would detect when any data derived from unsanitized GET request parameters is outputted within HTML.

Static Analysis involves performing data-flow analysis directly on source code to detect when certain kinds of security vulnerabilities are possible. Like Dynamic Analysis it uses a data tainting model but instead of operating within a live running program on real data it studies all possible code paths within a program to identify potential problems.

Agenda

* Conceptual introduction to Dynamic Analysis and Static Analysis
* Advantages and disadvantages of each approach
* Current progress and results with Drupal
** System-wide data tainting using Taint PHP
** Using the Schema API for accurate database tainting
** Development of Taint Trace for easier debugging
** "Run-time static analysis" of Drupal Input Formats

Goals

Attendees will learn how Static and Dynamic Analysis can work to improve program security by automatically detecting XSS and SQLi vulnerabilities.

Resources

This session requires only basic PHP development skills. All Drupal module developers are qualified and encouraged to attend.

Overview

The session will introduce the Field API intended for Drupal core. The Field API supports "CCK fields in core" as a new central concept for organizing content as an eventual replacement for the Node API model.

Agenda

* Motivation for Fields in core
* Design goals for the Field API
* Current status of the Field API
* Fields on remote data and the semantic web

Goals

Attendees should leave this session understanding what the Field API is, how it will work, and how to use it to create custom content types programmatically.

Resources

Attendees should be familiar with node types and how to use CCK user interface to define custom content types with fields.

An update on the State of Drupal.

Overview

Using the Location and GMap modules, it is possible to quickly create sites with maps in Drupal. This BOF will address the ins and outs of using the Location and GMap modules to create a mapping mashup. This will be oriented towards end-users and will focus on configuring the modules and creating several maps using Views.

Agenda

• Installing GMap and Location--what you're getting and non-obvious details
• GMap and Location out of the box
• Generating custom maps
• Basic theming of map markers and bubbles

Goals

People should walk away from this session with an understanding of how to create a simple Drupal-based mapping site.

Resources

This BOF will use the Location and GMap modules; participants will not need to be familiar with the modules beforehand.

Location module:
http://drupal.org/project/location

GMap module:
http://drupal.org/project/gmap