I would like to transplant pages from one django-cms instance to another one. I would like to see an export functionality which makes a human readable file of each exported page. The page should include all plugins and sub-plugins. The import mechanism would take a set of such files and add the pages to the cms instance. Adding them under the root would be good enough. Writing code for putting the pages lower in the tree would be complicated, and the current main part of the work is the enormous amount of cutting and pasting.
Well unless your templates and placeholders, and extensions were the same
it would be pretty pointless.
You could do an import/export for the WYSIWYG editor quite easily just by
calling the entire contents of the SQL cell, but every other plugin would
need its own adaptation.
It's rare you have sites that you need to copy front end data between, so
seems a lot of work for a limited audience.
On Sep 11, 2012 9:08 AM, "Jacob Hallén" <160...@gmail.com> wrote:
> I would like to transplant pages from one django-cms instance to another
> one. I would like to see an export functionality which makes a human
> readable file of each exported page. The page should include all plugins
> and sub-plugins. The import mechanism would take a set of such files and
> add the pages to the cms instance. Adding them under the root would be good
> enough. Writing code for putting the pages lower in the tree would be
> complicated, and the current main part of the work is the enormous amount
> of cutting and pasting.
> Best regards
> Jacob Hallén
> --
> You received this message because you are subscribed to the Google Groups
> "django-cms" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-cms/-/h7-xOAJMwq8J.
> To post to this group, send email to django-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> django-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-cms?hl=en.
> It's rare you have sites that you need to copy front end data between, so
> seems a lot of work for a limited audience.
Sorry, but I disagree. It's so common that I've made my own management
command to do this (it works OK, not perfect, but OK).
MY use case is not copying a site over to another, but rather passing
data between the different devs' sandbox installs, and then up to the
production server when the site is ready for launch. I suspect this is
a pretty usual need.
I do it by calling dumpdata `appname` repeatedly for each cmsplugin
app, which is a list I have to maintain manually, so far, although
with my current setup, it should be pretty straightforward to make it
a separate setting in a non-obtrusive/DRY way. I call it in order, and
dump the files onto different fixture files. I also iterate over
ImagePlugins and FilePlugins to create compressed archives with the
content files
--
"The whole of Japan is pure invention. There is no such country, there are
no such people" --Oscar Wilde
|_|0|_|
|_|_|0|
|0|0|0|
(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.
I agree with Tomas here, and this is with a single-person operation. I do a lot of testing and experimenting on my laptop before I push things "live", which makes keeping content correct and accurate a challenge.
However, I'm also willing to recognize that I just may be behaving stupidly. Is there a better way to accomplish this? The upcoming draft/publish stuff sounds like it will help, as long as there is a way for me to see my changes when the rest of the world can't (a custom permission, perhaps?).
On Tuesday, September 11, 2012 10:05:25 PM UTC-6, Tomas Neme wrote:
> > It's rare you have sites that you need to copy front end data between, > so > > seems a lot of work for a limited audience.
> Sorry, but I disagree. It's so common that I've made my own management > command to do this (it works OK, not perfect, but OK).
> MY use case is not copying a site over to another, but rather passing > data between the different devs' sandbox installs, and then up to the > production server when the site is ready for launch. I suspect this is > a pretty usual need.
> I do it by calling dumpdata `appname` repeatedly for each cmsplugin > app, which is a list I have to maintain manually, so far, although > with my current setup, it should be pretty straightforward to make it > a separate setting in a non-obtrusive/DRY way. I call it in order, and > dump the files onto different fixture files. I also iterate over > ImagePlugins and FilePlugins to create compressed archives with the > content files
> -- > "The whole of Japan is pure invention. There is no such country, there are > no such people" --Oscar Wilde
> |_|0|_| > |_|_|0| > |0|0|0|
> (\__/) > (='.'=)This is Bunny. Copy and paste bunny > (")_(") to help him gain world domination.
Surely pg_dump will solve the issue of moving data between two sites that
are the same?
On Oct 1, 2012 5:42 AM, "Travis Jensen" <tra...@pivotmachine.com> wrote:
> I agree with Tomas here, and this is with a single-person operation. I do
> a lot of testing and experimenting on my laptop before I push things
> "live", which makes keeping content correct and accurate a challenge.
> However, I'm also willing to recognize that I just may be behaving
> stupidly. Is there a better way to accomplish this? The upcoming
> draft/publish stuff sounds like it will help, as long as there is a way for
> me to see my changes when the rest of the world can't (a custom permission,
> perhaps?).
> tj
> On Tuesday, September 11, 2012 10:05:25 PM UTC-6, Tomas Neme wrote:
>> > It's rare you have sites that you need to copy front end data between,
>> so
>> > seems a lot of work for a limited audience.
>> Sorry, but I disagree. It's so common that I've made my own management
>> command to do this (it works OK, not perfect, but OK).
>> MY use case is not copying a site over to another, but rather passing
>> data between the different devs' sandbox installs, and then up to the
>> production server when the site is ready for launch. I suspect this is
>> a pretty usual need.
>> I do it by calling dumpdata `appname` repeatedly for each cmsplugin
>> app, which is a list I have to maintain manually, so far, although
>> with my current setup, it should be pretty straightforward to make it
>> a separate setting in a non-obtrusive/DRY way. I call it in order, and
>> dump the files onto different fixture files. I also iterate over
>> ImagePlugins and FilePlugins to create compressed archives with the
>> content files
>> --
>> "The whole of Japan is pure invention. There is no such country, there
>> are
>> no such people" --Oscar Wilde
>> |_|0|_|
>> |_|_|0|
>> |0|0|0|
>> (\__/)
>> (='.'=)This is Bunny. Copy and paste bunny
>> (")_(") to help him gain world domination.
> --
> You received this message because you are subscribed to the Google Groups
> "django-cms" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-cms/-/gLm-j2Jkdw8J.
> To post to this group, send email to django-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> django-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-cms?hl=en.
As per Luke. If you're on Postgres invest time in learning pg_dump.
Heroku makes it fairly trivial with their pgbackups command which saves the pg_dump output to S3, but you can replicate with a little effort. I have a single command which backs up either production or staging and downloads it and loads it into my local database and overrides the User and Site data with local dev settings. Heroku is a simple one size fits all "heroku pgbackups:capture --expire", but if you have control over pg_dump you can leave out specific table data (such as User and Site).
On Monday, 1 October 2012 14:42:11 UTC+10, Travis Jensen wrote:
> I agree with Tomas here, and this is with a single-person operation. I do > a lot of testing and experimenting on my laptop before I push things > "live", which makes keeping content correct and accurate a challenge.
> However, I'm also willing to recognize that I just may be behaving > stupidly. Is there a better way to accomplish this? The upcoming > draft/publish stuff sounds like it will help, as long as there is a way for > me to see my changes when the rest of the world can't (a custom permission, > perhaps?).
> tj
> On Tuesday, September 11, 2012 10:05:25 PM UTC-6, Tomas Neme wrote:
>> > It's rare you have sites that you need to copy front end data between, >> so >> > seems a lot of work for a limited audience.
>> Sorry, but I disagree. It's so common that I've made my own management >> command to do this (it works OK, not perfect, but OK).
>> MY use case is not copying a site over to another, but rather passing >> data between the different devs' sandbox installs, and then up to the >> production server when the site is ready for launch. I suspect this is >> a pretty usual need.
>> I do it by calling dumpdata `appname` repeatedly for each cmsplugin >> app, which is a list I have to maintain manually, so far, although >> with my current setup, it should be pretty straightforward to make it >> a separate setting in a non-obtrusive/DRY way. I call it in order, and >> dump the files onto different fixture files. I also iterate over >> ImagePlugins and FilePlugins to create compressed archives with the >> content files
>> -- >> "The whole of Japan is pure invention. There is no such country, there >> are >> no such people" --Oscar Wilde
>> |_|0|_| >> |_|_|0| >> |0|0|0|
>> (\__/) >> (='.'=)This is Bunny. Copy and paste bunny >> (")_(") to help him gain world domination.
