[development] Staging content to production servers
drupal at dave-cohen.com
Mon Jun 19 13:24:57 UTC 2006
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:
'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
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
More information about the development