DrupalConDC A Paradigm for Reusable Drupal Features

Ian leads off.

They did a very good job explaining why we want to be able to store features, and not have to do all the configuration every time we need to do a similar task (a blog section, a newsroom section, etc.)

Then went to Robert for the demo.
Everything that can be described as a feature and can be have its creation automated can be described by:
scripted or exportable

imagecache, blocks, views are all exportable.

(Some made possible by the context module.)

Think of how many blogs we created from 2003 to 2009, much of it repetitive work.
Not anymore.
There's still more to do to make it easier.

Move to turning on a feature, rather than turning on a module that needs to be configured.

The most recent sites we've been building we just turn on features.

Our blog content type:
Have a subtitle, we think that encourages good writing.
Then blog tags.

Now he's making a view. Published. Node type blog.

Stuff we have to do every time we make a blog.

Now to show you, even though it won't be relevant right now, Spaces adds a couple more filters: Make sure node is in current space.

So you can have each group be a space, and only show the blogs in that space, and tell it to show all results if there is no space.

Now we go over to admin/build/context

(There's a lot fo configuration here, heh.)

Can make a site space

Defined the context.

Said where the blocks should appear

Features are modules
myblog.info, myblog.module

We did all that work in the UI to get that feature set up, but you can export CCK definitions and such...

At the moment there isn't a great way with vocabulary and CCK to export it and define it in code-- the distinction between scripted and defined (exportable)... scripted is much more difficult.

In their system currently, had to make field definition, vocabulary by hand-written code.

Then paste in views export and such.

Spaces have administration for groups, users, lots more.

Robert done, on to the third and last, Young:

Why do we want our site building in code (rather than the database)?

Database useful for first site you build.

Code is reusable. Code is distributable. Code can be kept under version control (more sanely than databases!).

Check for pressroom content type, make sure it doesn't exist already, and the ncreate it.

Add CCK fields to it.

Scripting sucks.

1. Scripts are a pain to debug (who has written or tried to write an installer profile?)
2. Scripts are a pain to maintain (if you are a module maintainer, you know your update scripts are the last thing you want to do... and then someone grobs the CVS dev version...).
3. Scripts are not easily extensible (tend not to have hooks, loose coupling of looking at what else is installed and can be used).

Different models for getting things from the database into modules-- Earl Miles, MerlinOfChaos, in CTools calls this Exportables. I used to call it NDO for Normal, Default, Overridden.

[the I here is Young, usually when taking notes i transcribe]

• exportables provide definitions, not scripts-- they provide a structured array
• exportables are easy to maintain
• exportables are overridable and extensible

There's a framework for this in Views right now. You can diff a view from the exported one to the default one you created earlier to see what the client did to your view!

Who has exportables: Views, Panels 2, Context UI, imagecache.

Who doesn't? Node and CCK
Taxonomy (this should be easy to write though! Vocabularies and terms are saved pretty straightforwardly as arrays or objects, I forget)
Filter
Menu
Triggers
Your module?

CTools has an API in progress for exportables.

String identifiers -- string is good, numeric is bad
good: taxonomy_term (view), thembnail (imagecache preset)
bad: 5 (vocabulary)

1. API functions for cellecting all items
2. node_get_types(), imagecache_presets()
3. structured array [or something, missed it]

get everything defined, all default items
probably throw in a drupal_alter to let other modules mess with them.

Do not put drupal_alter at the end of this function, your users will not be happy with you, having some other module override their UI changes! So have it act on

ImageCache

Then a way to export your definition
define the form
the item that wants to be exported
the structure of what you gathered

featuremaker module?

Imagine a module that would automatically package any of your site's features into a module for you to download and share.

Flag does not have exportables yet (neither does nodequeue).

If you are a developer, add exportables to your module.

If you're not, pester the hell out of developers in their issue queue.

http://www.developmentseed.org/tags/spaces
http://svn3.cvsdude.com/devseed/sandbox/drupal-6/myblog

Twitter #spaces

Modules:
Context
Spaces
Chaos tools (interesting code for developers)

Why spaces?

To manage features per-group, or per-language, or per-taxonomy term.

Part of why they tend to use the word "features" rather than "sections"

Drupal is a feature manager. What is different about Spaces is it lets you turn features on and off per feature, per slice.

It would have been very easy to write in the dependencies in the .info file, so that should be part of featuremaker.module

Are there issues in the core issue queue to get taxonomy and other Drupal core things to take advantage of exportables.

Young: I'm not sure, probably not, I hope to see about putting a field

So far Earl Miles has been pushing the idea, now some of us need to run with it.

Current production sites-- would you consider this ready for prime time?

Goal by end of code sprint is RC1 release.

We want all of this to be open source very soon.

Resolution