[development] Solving the dev->staging->live problem

[Victor Kane]

This whole thread is exceptionally profound and of great interest to
those who spend their days actually using Drupal with clients and
getting sites done.

I think it is correct to avoid a purely database driven analysis of
the problem, and that both the problem and the solution should be
expressed in Drupal terms, that is, Drupal building blocks, like
users, nodes, comments, menus, blocks or panels, that is, different
kinds of entities, their listers and containers.

But the more profound the discussion goes, the more it resembles a
reverse engineering of Drupal. And any approach to X-Ray a Drupal
instance in order to dissect and reassemble it elsewhere, in whole or
in part, unfortunately, is going to smack hard against design
decisions already made in Drupal.

Perhaps it would do well to focus attention on single points capable
of being improved upon: there have been many attempts, there have been
some satisfying solutions implemented, but there is no straightforward
way to export and import node content in Drupal. Forget about
"structural" nodes, for the moment (although that of course is
important, I mean just to simplify).

There is no straightforward way in Drupal to export and import a given
content type's nodes.

No off-the-shelf, simple way of doing it.

I can try to marshall the failed export-import module.
I can more successfully utilize the services module. But in this case
if there are some complications in the field types, I need to write my
own {node-type}.save service.

That is, I cannot export/import content in Drupal without writing PHP code.

I think that is one of the biggest weaknesses that confront us. Deploy
seeks to solve this, but falls down through no fault of its own over
the difficulty of exporting and cleanly importing CCK content type
definitions.

The solution probably exists in terms of extracting all objectively
structural information architecture decisions (panels, menus, blocks)
into text-based version-controllable definitions, together with
configuration elements: currently "serializable" via the Installation
Profile Generators: http://drupal.org/node/180078.

I think a beginning would be to ensure that for Drupal 7 there existed
an export/import facility for node types; and that CCK, Views, Panels
and what-have-you work on improving their individual import/export.

Anything on a grander scale might smack hard against existing Drupal
design decisions.

Victor Kane
http://awebfactory.com.ar

On Sun, Aug 10, 2008 at 5:15 AM, Adrian Rossouw <adrian at bryght.com> wrote:
>
> On 10 Aug 2008, at 9:18 AM, Greg Dunlap wrote:
>
>>
>> This whole problem would be much simpler if every "thing" had a GUID. Get
>> that in place, and building a system to do deployment in the way described
>> above actually becomes a realistic proposition. As Sam implied I've been
>> conceptualizing a solution based on this premise, but its been hard finding
>> time to really work on it. Hopefully soon.
>
> We could create an object table pretty simply, and just keep that
> maintained,  with the object type, object area (ie: production, staging,
> etc)
> and reference id. And could then just write drivers for each of the object
> types.
>
> Most of the 'drivers' would be really simple, ie; just wrapping node_load
> and node_save or drupal_execute.
>
> We could make it a lot simpler to support the object table by writing a very
> simple fapi submit handler that gets added onto forms that
> need to be indexed in the oid table :
>
> $form['#submit']['drupal_object_register'] = array('node', 'nid', 'area');
>  // just tells it to use $form_values['nid'] and $form_values['area'] when
> sticking it in the table.
>
> We would also be able to handle versioning, although the idea of tracking
> node revisions like this on a busy site with
> revision tracking could get difficult. Add a datestamp on there, and you
> could have the proper order to import objects too.
>