• Content & User Centric
• For those who are evaluating: Use it for what it's good for, don't try to shoehorn it into things it shouldn't do
• Modular: without the modules, it's just a set of APIs that listen for HTTP requests
• Event-driven: hooks instead of listeners
• Skinnable / themable - everything passes through the theme layer
• Organic: a bonus for a vibrant community but sometimes leads to code repetition -- there are some examples of this in the theme layer
• APIs - things that live inside the magical '/includes' folder. They're very separate from the modules that are visible to end users. You wouldn't turn off the 'user' or 'node' modules.
• API layer:
  • Menu API: routing (path 'x/y/z' requested, what module should build it?) menus, navigation, breadcrumb trails
  • Database Abstraction Layer - lets us make db queries. Separates us from whatever DB has been chosen. D7 is switching from a homegrown database abstraction layer to PDO, an industry standard.
  • Session handling - keeps track of individual users. Lets us say that we would rather store things in the db / memcache / somewhere else depending on site load
  • Output filtering - lets us scrub data for safety.
  • File Storage
  • Locale and Language
  • Theming (rendering)
  • Forms & Processing
  • Image Manipulation
  • Caching
  • Batch Processing (there are 3 separate queue systems in drupal)
  • Email handling
  • Modules (plugins)
  • Updates system
  • XML-RPC
  • Unicode Utilities

I'd like welcome.html!

(Or, how a page is generated in drupal)

• Server says, "I'll go get it!" and checks .htaccess
• I'll route the request (index.php) The menu system takes the request and checks to see which module wants to build welcome.html, and hands it off to that module. Also asks if there's any modules that want to help build it.
• If it's a node, the node module gets it, then it asks modules if they want to contribute things to it.
• What theme is currently active? The content will then be handed to the theme
• The theme layer turns it into HTML ("has anyone overridden me?")

The system does not pare down well for small requests. This is a problem for the future.

Hooks - events & listeners

• module_invoke_all() announces that something has happened.
• PHP keeps a cache of all named functions. We turned it into a seriously ghetto event listener system.
• Info Arrays: menus, schemas, batches. Any time Drupal gets info, it's going to build "a big-ass array." Downside: you can stick ANYthing in it ... whether or not it makes any sense.
• Callbacks - "if in one of those big-ass arrays, we stuck a function name in there somewhere" - defines the name of the PHP function we want to process or validate or pre-process this particular array
• Renderables (think XML as arrays) - in D7 we use renderable arrays to describe everything in a page.
• Alter hooks (modules modifying data) - lets you change any part of an array
• Nodes
• lists (filtered collections, not just Views!)
• Actions (vote, forward something, buy...)
• Structure (menus, breadcrumbs, etc.)
• Theme (layout & markup)

Who's your team?

• Architects plan the big picture.
• Builders configure and set up things.
• Developers code the custom bits.
• Designers turn ideas into html/css
• Themers turn designs into themes.
• Migration Mules tend to old data.