Brands have a way of happenFake Brands Image by Chuck Coker

In The Rhetoric of Fiction, the late Wayne C. Booth discusses a concept of the "implied author."

The implied author, according to Booth, is a "second self" from the actual historical person who wrote the work in question, not the flesh-and-blood being but a hypothetical entity that includes "not only the extractable meanings [of the text] but also the moral and emotional content of each bit of action and suffering of all the characters" (73). To rely solely on extratextual sources that will verify an author’s "intention" is at least problematic, if not a "fallacy." The implied author, though, is a construct prompted by the text itself. The implied author, Booth asserts, is responsible for the "norms" and "values" that seem to be expressed in the work but cannot necessarily be attributed to a narrator and should not be attributed to the historical author.

So you're building a Drupal Feature! Woohoo! Okay, so…. What to include? What to leave out? How to structure the thing so it doesn't conflict with other Features? How to avoid known issues? Where to start?

When, in theory at least, you can make an entire site into one big Feature, these questions become extremely important.

If you're using Features simply to help facilitate your own site-building workflows, this may be something you can pretty much ignore. When dealing with Features you've made for yourself, you may remember your thinking, you may follow your own logic, you may be using Features as a blobby deployment system for all kinds of stuff glommed together. Whatever works. It's all good.

The State of Drupal keynote that Dries Buytaert gives at every DrupalCon this time focused on Drupal's role in CMS market disrup

Drupal's adoption as been doubling with every release. Imagine the community doubling in 2010 with Drupal 7!

"Drupal mud." Each major part of Drupal core overlaps several other parts. Every change in one component cascades throughout.

Object Oriented Drupal. Clean. Each class contained. With this structure, Drupal core can evolve more quickly.

Half dozen of the other

Has it been six years already? I'm astounded. Drupal in 2004 was really really really different. It's been quite a ride. And it's getting better and more fun and more interesting with every passing moment. And that's because of the stellar contributions of the dozens of core developers on Drupal 7 (and 6 and 5 and 4.7 and 4.6 and 4.5), the leadership of people and companies in the Drupal community, and all the people who contribute back — whether it's out of the notion of "giving back" or out of the self-interest of inviting the rest of the community to help them on their project.

Many Drupal themers will be daunted by the changes in Drupal 7. But we're excited about the new power.

With fields now in core, if you weren't CCK-prolific, you have more theme components to account for by default.

RDFa is here to stay. Robots will love it. You should just stay out of the way.

Regions contain the content area, sidebars, footer, etc.

Every major release has introduced significant changes to the core API. There's no backwards compatibility between major Drupal releases; you can't run Drupal 7 modules on a Drupal 6 site, for example. In fact, if you tried you'd likely end up with the white screen of death. This willingness to let go of past thinking and old code has allowed Drupal to be as awesome as it is today.

For theming, fortunately, the changes have usually been rather incremental — a short checklist of minor changes to themes to get them working in the newer Drupal. And none was as radical or challenging as the change from Drupal 4.5's xtemplate theming engine to the phpTemplate engine that emerged around Drupal 4.6 and became part of Drupal 4.7's core. That "upgrade" actually required total reimplementation. You simply could not just tweak an xtemplate-powered theme into a phpTemplate-powered theme. Thankfully, since then it's been a much easier road for theme upgrades.

That is, until now.