Hmm, so it makes sense to document pre-assignments default values fot standard fiels should be set using render tags to solve this.
On 20 Aug., 19:37, akor <[email protected]> wrote: > All, > > please keep in mind, that pre-assignments and default values get lost > with this method. > > Best, > -alex > > On Aug 20, 9:03 am, "[email protected]" > > > > <[email protected]> wrote: > > Yep, that's right. As long as the two projects have the same GUIDs the > > import will overwrite/update the content classes, so at some point you > > will need to take a copy of your production project back onto your dev > > box. If the projects have different GUIDs, then it will create new > > templates... which can start to cause complications where it isn't > > clear which template is which. > > > Changing an element name isn't a problem as RedDot uses GUIDs to > > identify the elements and adding new elements will also move across. > > IIRC some things don't move with it, like pre-assignments, but that's > > what documentation is for right? ;) > > > On 20 Aug 2009, at 00:33, markus giesen wrote: > > > > Hey Paul, so did I get this right? > > > You are saying that > > > 1. Create parent page with list > > > 2. Create & Connect pages (based on different templates a,b,c) > > > 3. Export parent page with childpages > > > > 4. Import this page within your staging/whatever system > > > 5. Content class changes will be adopted?? > > > > Is that correct? > > > Or does RedDot create new content classes and you have to replace the > > > old ones? > > > > If your way works that would be great, I'm just wondering what happens > > > when you change an element name or add one? > > > > On 19 Aug., 16:41, "[email protected]" > > > <[email protected]> wrote: > > >> That assumes that your dev project has the same content. In my > > >> experience Dev projects slowly devolve into "Test page 1", "Test page > > >> 2" ;) > > > >> The easier way to migrate just the changes you want is to create a > > >> blank page in your DEV project called Export. This page needs to have > > >> a list on it so you can create instances of any content classes you > > >> want to migrate. Once you've attached everything, make sure it's all > > >> released, select the Export page and from the right hand menu export > > >> this page and it's children. > > > >> Importing this into your production system will import all the new > > >> content classes without you having to worry too much about the > > >> project > > >> itself. Once the import is complete, you can delete the imported > > >> pages > > >> from your site structure. > > > >> Paul > > > >> On 19 Aug 2009, at 07:17, markus giesen wrote: > > > >>> Well you can still store all assets and project related files in the > > >>> database (NOT recommended) > > >>> And just replace the Database on Live with the one from DEV > > > >>> You still would need to change the publishing target and other > > >>> stuff. > > > >>> There are no proper/clean one-click button solutions to deploy a > > >>> project. > > > >>> On 19 Aug., 08:16, "[email protected]" > > >>> <[email protected]> wrote: > > >>>> I have a RedDot CMS development where lot of website developement > > >>>> actually happens. Are there any automated process to push the > > >>>> changes > > >>>> which are done in development to go to production CMS ? I know > > >>>> export > > >>>> of reddot project is one of the option, but business complaints > > >>>> that > > >>>> it is not easy for them. > > >>>> In our environment CMS development & CMS production are physically > > >>>> separate servers(CMS & DB) > > > >>>> regards, > > >>>> Anand --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en -~----------~----~----~----~------~----~------~--~---
