Drupal ninja

Overview

Panels2 is a powerful system for organizing and marshaling drupal sites, but the API has a steep learning curve. This session is about breaking the API down into manageable pieces. So, if you've ever wanted to:

• 'Panelize' your modules, like what og_panels has done,
• Extend Panels by writing new plugins that add new pane types, new styles, new layouts, new contexts, etc.,
• Get an authoritative overview of all the ways your modules hook into and take advantage of the Panels API,
• Toss some of your Panels-implementing ideas out and get feedback on them right on the spot,

then this may be the session for you! We'll divide the 90 minutes into two parts:

In the first half, Sam Boyer (sdboyer) will provide a fast-but-structured overview of how the Panels API works, and where your module can plug in.

In the second half, participants will be free to ask questions about techniques and approaches to implementing the Panels API; Sam (and/or other participants) will respond with comments & suggestions on how to bend Panels to your particular module's need.

Agenda

• Provide and quickly run through handouts that overview the Panels API. Lots of space for notes!
• Quick overview (with visuals) of how the Panels API handles editing and rendering.
• Overview of the general logic behind the Panels plugin system. We'll also cover panels-specific hooks.
• Open it up for questions.
• When we're down to 5 minutes, Sam will stop the action and record any questions that haven't yet been answered; we'll do our best to answer those questions in public & online later on.

Goals

Panels is a complicated beast; trying to cover the API in detail would be an exercise in futility. Instead, this session should provide participants with a framework for approach Panels in a productive way. Each half of the session should do that in a different way:

• The first half will provide a working understanding of Panels' various moving parts, and when and where you can hook in.
• The second half will provide concrete examples of how people are thinking of implementing Panels, and Sam's answers will suggest how to go about approaching each of those ideas.

Ideally, the combination of the two should provide all participants with a decent grounding in how to 'Panelize' drupal.

Resources

The only thing people need to bring is IDEAS! The second half will crash and burn if people don't bring big thoughts on how to implement Panels in new and different ways.

Important Note: this session is primarily geared towards developers writing modules that are or will be kept in the official Drupal CVS repository. If you have client-specific Panels needs that are unlikely to be genericized for use by the whole drupal community, please find another venue to raise those questions.

Overview

Drupal is increasingly making a place for itself among museums around the world. As a strong and flexible framework Drupal can be a good fit for these sorts of organizations.

This session will be a case study and lessons learned from two museum web sites Palantir has built using Druapl 5: The Indianapolis Museum of Art and the Art Institute of Chicago. Both sites offered a number of unique challenges but also the opportunity to share amazing and diverse content.

Agenda

* Bringing Drupal into a large, established web presence
* Designing a modern site that still has a strong artistic feel
* Bridging Drupal to legacy multimedia databases, such as museum collection databases
* Drupal as an application framework
* Existing open source museum tools

Goals

We hope to present both the challenges and rewards of integrating Drupal with large, established systems such as those of museums. We also hope to give some insight into how to bend Drupal farther than you ever thought possible.

Resources

Indianapolis Museum of Art: http://imamuseum.org/
IMA Drupal.org Showcase: http://drupal.org/node/188312
Art Institute of Chicago Collections: http://www.artic.edu/aic/collections/
AIC Drupal.org Showcase: http://drupal.org/node/279485

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

Drupal 7 will feature a newly rewritten database layer providing improved database abstraction, portability, and scalability features. This session will cover the thinking and architecture behind the new layer, with an eye toward understanding how it fits into the larger scheme of high-performance Drupal sites. There will be some discussion of code, as well as words of advice for others looking to revamp one of Drupal's core systems.

There will be some code in this session, but you should not need to be a hard-core coder to follow it. This session will also serve as a lead-in to this code track session, which is aimed more at programmers.

Agenda

* Database abstraction: Why it's hard and even an unsolvable problem.
* The old Drupal approach, and why it's not good.
* The new Drupal approach, and why it's awesome.
* Leveraging the database on your own deployments.
* Request for feedback on some of the more big-iron-targeted parts of the new feature set.
* Recommendations for other core developers on how to (not) revamp Drupal subsystems.

Goals

After attending this session, you should have a good idea of ways to leverage the new, modernized database system for your own sites as well as how to go about making major changes to Drupal's infrastructure.

Resources

Knowing the basics of SQL servers before attending would be a good idea, for context.

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

User experience (UX) can be defined as “the overall experience and satisfaction a user has when using a product or system.” A product’s UX affects a user’s interest, ability, and enjoyment when using a product. If a product’s UX sucks, people will not use it if they have a choice or hate using it if they do not.

Well, programmers are people, too. When creating a software product like Drupal that is intended to be used by other developers, the UX includes the experience of those developers as they write code for the product.

Since developers face different kinds of issues than the end users of the product, it is useful to consider Development Experience (DX) distinctly from UX. DX might be defined as “the overall experience, satisfaction, and efficiency a software developer has when using a software development platform.”

In this workshop, we'll brainstorm about ways that Drupal's Developer Experience can be improved.

Agenda

* Why Developer Experience matters
* Open discussion of how Drupal's DX can be improved.

Suggestions I'll bring the workshop include using defined names instead of anonymous constants, abandoning anonymous arrays in favor of typed data structures, and replacing form submit handlers with API functions. Please bring your own!

Goals

We'll come up with a list of proposed coding style directions or improvements for Drupal 7+ and contrib modules that will make Drupal a much more enjoyable and efficient platform for which to develop.

Resources

Anyone familiar with Drupal development is qualified and encouraged to attend. In many ways the less experienced you are, the better, as you will not already be indoctrinated into The Drupal Way of doing things.

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.