April 2010

Drupalcon notes: Getting Started with Drupal(con)

  • Overall introduction. What drupal is, who's using it. Extensibility, roles
  • Drupal as a community
  • Drupal jargon: nodes, CCK = 'fields' in D7, Views, themes, menus, taxonomy, menus, permissions, roles, hooks, cron, druplipet
  • How does drupal work?  Description of the stack, starting with OS -> web server -> PHP/database -> Drupal -> core subsystem -> cor modules -> contrib modules -> theme system -> HTML -> CSS/Javascript
  • Discussion of CCK and taxonomy

Drupalcon notes: How Drupal Works: An Architect's Overview by Jeff Eaton

  • 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

Drupalcon notes: 20 APIs Every Drupal Developer Should Know

Presented by the technical lead from Trellon.

APIs let your code interface with other codes - core or contrib.
if you write code, other developers will want to interfact with yours. If you think in terms of Apis, your code quality improves.

Which APIs should you know?

Drupalcon notes: Objectifying PHP

(No, PHP, your ass doesn't look fat in that. Honest.)

all tags: 

Not as we planned

I am having to be far more careful at drupalcon than I'd hoped. Instead of doing a full-blown free-for-all, I'm having to be choosy about what I do -- and I'm choosing to go to sessions. I came down with something nasty either in Huntsville or in Minnesota, and it was in full swing by the time I landed in San Francisco. What had originally been just an angry tickle in the back of my throat was so bad I couldn't swallow solids or liquids without pain.

all tags: 

Drupalcon notes: the Chaos tool suite

Collection of tools. Intended to be zero-dependency. One step above core, in Earl's view.

all tags: 

Drupalcon notes: Facebook Applications in Drupal

Notes:  http://dave-cohen.com/

Facebook Application Development Platform

Facebook has done some basic verification on the users, with email addresses or CAPTCHA, so you're somewhat more assured of reaching real people. Obviously, you can tap into these users' social networks.

Dev platform was created in 2007. Allows anyone to add features to facebook.com. Early apps were aggressively viral; this has calmed down recently. Today it supports

all tags: 

Drupalcon notes: CCK to Fields - Getting There From Here

Flexinode was available from 2004-2007, versions 4.4-4.7. It introduced the idea of custom content types. Problem: it didn't work at all in Views. Was rewritten to scale better. CCK, the successor, lived from 2007-2010, in versions 4.7 to 6.x.

Early on, it was table-segregated by type of data: text, integer, etc. Didn't last long. Now: if the same field exists in multiple content types, it all goes in the same table.

all tags: 

Drupalcon notes: Theming with Skinr

Themer Pain Points

  • Lack of mockups = no big picture planning
  • Lack of time = sloppy CSS
  • Crazy selectors = less reusable code
  • After completion = not much flexibility, low shelf life

You're doing it wrong if...

  • You're not styling default Drupal elements
  • You're excessively targeting IDs
  • You're writing super specific CSS
  • You're creating a new .tpl file for each little change
  • You're not structuring markup in a way that is flexible

Skinr lets you

  • Create your own reusable style definitions in the theme layer
  • Lets you creat your own CSS classes and forget about drupal
  • Makes your styles point-and-click

Where it shines:

  • Contrib themes
all tags: 

Drupalcon notes: Best Practices in Contrib Development and Support

For new, improving, and prospective module maintainers.

What's expected

You're not forced to do anything. However, if you post it, you're endorsing it. At that point, you have some responsibility. You'll need to work with the security team on fixing vulnerabilities, and support your code. Clearly communicating your intentions to your users is good, too. Poorly maintained projects give us a bad name.

Best practices: Community Management

How to enlist help:

all tags: