Site administrator

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

Google has shown us that search matters. Drupal's core search has strengths as well as weaknesses. What are they and how are the weaknesses being addressed? What new search options have emerged, and how does one evaluate them?

Agenda

* Core search in Drupal 7: What needs to be done?
* Minnesota Search Sprint: What got accomplished and where does it go from here?
* Xapian, Sphinx and ApacheSolr: With so many third-party options to choose from, how does one evaluate and decide?
* Search and Drupal.org: What special needs does Drupal.org have, and how can we improve things now and in the future?

Goals

Increase focus on improving core Drupal search. Increase awareness of alternative solutions. Increase awareness of different search features, such as faceted searching. Encourage more collaboration amongst developers.

Resources

* http://drupal.org/project/apachesolr
* http://drupal.org/project/xapian
* http://www.sphinxsearch.com/
* http://groups.drupal.org/node/4102 (Search group on g.d.o.)

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.

An update on the State of Drupal.

Overview:

Imagefield Gallery is a module that's been around since shortly before Drupalcon Boston. I created it with the intent of making gallery management for an existing site easy for single nodes. Since that time others have used it for their own sites, and have extended it to work with proprietary gallery types that have not been contributed back. I would like very much to introduce the drupal community at large to imagefield gallery and encourage them to help develop it in a direction that could be beneficial for ALL of drupal, not just a small subset.

As stated above, imagefield gallery's primary purpose is to create galleries on a node from an existing imagefield. The new 2.x version cleans up the admin, and is striving to squash some old bugs, and add new features. In development is the ability to do node references, as well as a new gallery type. Imagefield Gallery makes creating new gallery types pretty easy and straight-forward. These gallery types are re-usable in a large number of instances and allow the site administrator to customize gallery types per content type.

Agenda

• Current Capabilities
• What I'd like to see donated by the community
• What about D6?
• What could the future hold?

Goals

Ultimately the objective of this session is to introduce Drupal at large to the Imagefield Gallery module, and show them what it can do for them. With some help I believe imagefield gallery can fill a significant void in the current Drupal codescape and give Drupal a varied and significant gallery system upon which to draw.

Resources

Project Page:
http://drupal.org/project/imagefield_gallery

Development/News Blog:
http://www.worxco.com/blog-categories/imagefieldgallery

Overview

This session will show off the results of Drupal's Google Summer of Code 2008 projects. Students who make it to Drupalcon will be demoing their own projects, and we'll also show off projects from the students who can't be there.

Agenda
The following projects will be shown during the course of the session, as time permits.

• Apache Solr Improvements
• New Aggregator for Drupal core
• Bookings API
• Charts module Views integration
• Color module improvements
• Document Import Module
• Embed Widgets
• Revamped Help system
• Icon module
• Image manipulation GUI
• Memetracker
• New nodequeue sub-modules
• OAuth/Services module integration
• Open ID Attribute Exchange
• PluginManager
• Core search improvements
• Security scanner
• Usability Suite
• Validation API
• Version Control API / Project module integration
• Views datasources

Goals

This session will allow Summer of Code students to show off their hard work, and for the Drupal community to get a first-hand look at all the cool stuff that was produced over the summer. Summer of Code students typically make excellent employees as well, for those looking to hire. ;)

---

NOTE TO ORGANIZERS: I put down "90 minutes" because that'd be a much more comfortable time frame during which to show off 21 projects. But every other year we've managed to do it in 60, so if 90 minute slots are short, you can push the time allotment back.

This will just be an informal gathering of the women who make it to Drupalcon: the Drupalchix (also known as the "7% club" ;)).

We did this in Barcelona and Boston, and it was awesome. :D

Topics might include things like:
* What are our various backgrounds/experiences prior to coming to Drupal?
* What is it that we’re currently working on?
* What have our experiences in the community been like?
* What can we do to encourage more women in open source/Drupal specifically?

Overview

Adding a Display Name in the core of Drupal has been a hotly debated topic for at least the last 4 years. The addition of a Display Name impacts on many areas within the project. With Drupal 7 it seems the right time to put this much need feature in core. The only questions are how and who.

We need a face to face discussion to define a clear set of requirements that will feed into the code sprint on the August 31 to result in a Drupal 7 patch commit.

Agenda

• The history of the issue (see Resources below for material to read beforehand).
• The sticking points and how they can be overcome...
  • The non-uniqueness issue.
  • The auto-complete and search results issue.
  • The security issue.
• Defining a clear set of requirements and points of action.
• Who will in build the Drupal 7 patch in the code sprint.

Goals

A Display Name field and associated admin and user interfaces in core in Drupal 7.

Resources

Please ensure you are familiar with:

• The issue thread for Add a Display Name field to core in addition to Username
• The wiki page for Add a Display Name field to core in addition to Username