[development] Staging content to production servers

[Dave Cohen]

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