Unfortunately, IDs get baked in to various places. For example, let's say my staging content includes a vocabulary and a Views module view to display the content of that vocabulary. The view is exportable as PHP, but if you look closely, you'll find the PHP includes something like: array ( 'tablename' => 'term_data', 'field' => 'vid', 'operator' => 'AND', 'options' => '', 'value' => array ( 0 => '7', ), Note the "7". That's the vocabulary's ID on the staging server. If, on the production server, the vid for that vocabulary is NOT 7, the view will not work as desired. I've found it convenient to hardcode IDs in various places of my own code. So I've grown fond of the notion that some important IDs will remain the same from staging to testing to production. I'm not saying it can't be done without hardcoding the IDs. But it's quite a challenge. -Dave On Monday 19 June 2006 05:12, Adrian Rossouw wrote:
On 18 Jun 2006, at 10:03 PM, Bèr Kessels wrote:
With my first drafst for fixtures I simply solved this by NOT using any IDs. Because fixtures are pure PHP, we can let Drupal create the IDs. No need for any hardcoded ID, if you design the architecture of the import- export of staging code well enough, IMO.
I agree with the idea of imports / exports.
Shipping the defaults as php as opposed to sql makes a lot more sense.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com