Sounds great. As per Ken's advice I've decided to create custom templates even if I strictly speaking didn't need to ( so I'm glad you think so aswell ) , I had felt it was a good idea. And I guess with views, there's always the export feature aswell. Thanks
On Fri, Jan 29, 2010 at 5:15 PM, Alex Barth <[email protected]>wrote: > > On Jan 29, 2010, at 11:53 AM, Ken Winters wrote: > > Where possible, do everything in code rather than the database. >> > > Right. Have a look at Features. It helps you export configuration to code > and manage it. It does this by relying on other module's export APIs. If > you're building a module with configuration options, take a look at > CTools/export API for making them exportable. Using CTools/export is best > practice for exporting ATM, IMO. > > http://drupal.org/project/features > http://drupal.org/project/ctools > > > Trying to merge two databases is a giant >> pain, but pushing new code and running update.php is fairly painless. >> >> If you do have to make database changes after the client has already >> entered data, you'll want to script it (often >> using an importer). >> >> - Ken Winters >> >> On Jan 29, 2010, at 11:47 AM, Stewart Birch wrote: >> >> Hello all >>> >>> very early on in my Drupal learning process but have been asked to come >>> up with a solution where the client will be entering content on the >>> production site and we may very well be making structural changes ( css etc >>> ) >>> on DEV and changes to the site setup ( for example a page name or >>> somesuch ) , is there a way to seperate the data entered for content types >>> from everything else so when deploying a site to production we can do so >>> without worrying about content being lost. >>> >>> Thanks >>> >>> Stewart >>> >>> >>> >>> >>> http://www.flickr.com/people/mrbirch >>> >> >> > Alex Barth > http://www.developmentseed.org/blog > tel (202) 250-3633 > > > > > -- http://www.flickr.com/people/mrbirch
