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@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.