How can I copy CMS pages from a development site t

Question

I've been integrating Django CMS to a Django project that has been in production already for over a year. As part of my development activities, I've converted to CMS pages those pages that used to be static content before I added Django CMS. My development database now contains pages that I would like to copy to the live site rather than require that project staff recreate these pages on the live site.

I have searched the Django CMS documentation but did not find a command for this. I've also searched the issues on github, the questions on SO and the Django CMS google groups. The only thing I've found is this discussion from 3 years ago. The discussion mentions using dumpdata to dump the cms models. I've tried it. The dump contains information about the pages (for instance, who created the page and when) but it does not contain the contents of the pages.

The live site has data that must be preserved. So I cannot perform a database level dump on the development site and restore on the live site, as this would erase or overwrite data that already exists on the live site.

I'm using Django 1.7 and Django CMS 3.1.0.

Answer 1

The discussion you refer to predates the 3.x series. Perhaps doing a dumpdata for the models associated with the cms application was the way to go 3 years ago, but, as you discovered, it does not work now.

I actually recommend trying the following steps on a mirror of your live site first so that any surprises can be taken care of ahead of the real operation. If you run into trouble on the mirror, you can take your time figuring the problem. Once you are ready to modify your live site, before you do anything, you should backup your database. Better safe than sorry. Also, the codebase on the site should be updated to reflect your development version before you try moving data around.

You can use these steps:

1. Inspect your INSTALLED_APPS setting and make a list of those apps that are CMS plugins and of the applications these plugins depend on. You may need to consult the installation instructions of some of the plugins to recall what depends on what.

   Once you have the list you can issue a dumpdata command on your development site with cms and the applications you identified. For my site, I have to do:

   python manage.py dumpdata --natural-foreign cms filer \
     cmsplugin_filer_file cmsplugin_filer_folder cmsplugin_filer_link \
     cmsplugin_filer_image cmsplugin_filer_teaser cmsplugin_filer_video  \
     easy_thumbnails djangocms_text_ckeditor > data.json
   

2. If you also have created custom permission settings for Django CMS, you may need to edit data.json to remove some or all of the custom settings. In my case I had a cms.PageUserGroup instance that I had created on my dev site. It referred to a group that does not exist on the live site and so I had to remove this instance from the data.json dump. Otherwise, the loaddata command in the next step failed with an integrity error.

3. You then copy data.json to your live site and issue python manage.py loaddata data.json.

4. If you have any files you've added to your media directory on your development site to create your CMS pages, you also need to copy them over to your live site.

I've used the procedure above to move data from my development site to a live site, with no discernible problem.

Caveats

1. The procedure above is meant to be a one time deal. It won't work if you continue making changes to your development pages and then try to migrate them over to your live site.

2. I've mentioned issues with permissions in the steps above. You are least likely to run into permission issues if you have CMS_PERMISSIONS set to False. If set to True, then you may have to edit your dump like instructed above before loading it on the live site. If you've done heavy customization of the permission scheme and have a whole bunch of PageUserGroup instances and a bunch of pages with special permissions, etc., then you are likely to run into major difficulties. I don't know a solution short of undoing all this customization, or editing the dump by hand to make it match your live site. The problem is due to the fact that the procedure above does not dump the authentication models (of django.contrib.auth). If you are in a situation where you can safely load them on the live site, then adding them to the dump would probably do the trick. However, when you have a live site that has been in production and where the authentication data has changed over time, you cannot just load the authentication models from the development site as this would overwrite some of the records (e.g. "admin"'s password would change to the one stored in the development database).

3. The method above does not move any of the pages' history. It is recorded with reversion. If you wanted to move the page's history, you'd have to add reversion to the list of apps to dump but I'm pretty sure it could have undesirable side-effects: it could also affect the data that reversion records for other apps that use it in the project. (In effect it would change or erase history of other apps.)