DrupalConDC Exportables discussion continued in a birds of a feather

Dmitri: Not all things are a multiple. Can't have more than one setting for user registration.

Updating an install profile is a huge pain.

HeyRocker's talk just finished, his solution is to have a [central] site that pushes to others.

Dmitri: We don't have a core import-export API

Does your stuff work with deployment, patterns, context and spaces? If there was one in core people would standardize on it.

All these projects are at a 40-50% overlap. "More."

It would be great to see the people who are championing them to draw a Venn diagram of this.

Why does patterns use FormAPI? No other choice!

Need something between Schema API and what the form that creates it (like CCK is) [not sure I heard that right]

Six months from now Drupal 7 hits code freeze, and you can't do anything with it. If we all wait 3-4 more years....

DataAPI can't come in 6 months. Maybe it could.

Young: There's a hook_variables patch in the queue that says, gather all your defaults. That's interesting.
Exportables

We don't want to clutter the contrib module space with meta modules. If we adopt a name

We have dozens of feature modules we wil

Using content copy -- you actually have to fake a form -- and we're back to formAPI

Patterns is a good code-running framework, but if you change the setting, it becomes different.

Views has a default in code.

It's not import-export -- it's just export -- for the default view, it

That's how it knows what is overridden and what isn't.

The import step never really happens. Every view in the database is

Idea of Patterns is you don't have to know code to create one.

The problem with putting a node in code - what do you know what the node ID is

Young: for the time being, let's talk about

The patch we are looking for --

That makes import-export a lot easier

Bluriest line is how to deal with menu items.

they are data, and have an ID number.

So if I use Patterns on three different sites, that have different

That isn't a problem, it is a problem

I don't care about data, I care about configuration.

Repeatable configuration is the key

HeyRocker has come up with a way-- he just threw in a GUID so he has an external identification number, and then he can move stuff around and do all the matching and make everything work.

(So Kathleen should just add this to DBScripts.)

So what needs to be exportable:

Views is exportable, has a unique name, that's a fairly high bar-- but they can, and they can use the same API.

And menus can have an action to create them (in a feature-wrapped module)

It doesn't have to pick if it's generic enough.

hook to pull them in
hook to alter them

nothing super-complex

Blocks: blocks can be

Resolution