During the development of a website, it may be necessary to convert paragraphs from older designs to newer ones. Usually this is because you've invested a fair amount in a structure just to find out the specs have changed. Or maybe you've been building in the samples provided by Magnolia and now want to move existing content to a framework of your own.
It is possible to migrate an existing site from an older schema to a newer one without ugly exports, xslt translations, and imports. Here's the process:
1. Collect info for your migration. Essentially just pull together all the old paragraph templates you've been using and list out all it's attributes (title, text, image, etc., ...). Then match up all those old paragraphs and attributes to the new paragraphs and attributes.
2. Create a template separate from the rest of the website. This template will be used on a page that's only run once and then deleted for each paragraph migration. Having said that, this page does not need to be decorated up like a final page for public view. Keep it simple.
An example can be found attached to Changing paragraph template associations. In addition to changing paragraph names, other NodeData object can be processed in the while( i.hasNext() ) {...} loop. Just do them all before the ending paragraph.save() call.
I would also encourage good, verbose diagnostic messages to help in debugging if necessary.
3. Once the migration template is setup, backup your repository. If something is mistyped and you get an error halfway through, you don't want your repository in a funky half migrated state.
My advice for this is to just mirror the whole webapp to another folder out of the way. Should stuff not work out right, you can easily stop tomcat, copy the repository or anything else you need back and start tomcat again before the next try.
Obviously because of the possibility that you are going to stop and start tomcat, this should be done on a test/dev server, not the main production server.
4. Create a page based on your migration template and open it to view. If you've setup some decent reporting, take a look at the output and the logs to be sure things went as expected.
5. Delete this page or update your template for the next migration. Refresh your backups and view the migration page again. Check the output and your logs, repeat as necessary.
Notes: The other way to handle the migration is to implement it in a taglib. The benefit of taglibs is you can break down the job, encapsulating descrete functions that are performed over and over. Maybe even setup the whole migration in one taglib shot. There are a number of good references on the web for composing a good taglib.
I've noticed that attempting to change the template name from inside a template does not work at all. It generates a stack trace with little to no useful information. In the same manner, attempting to change the paragraph name from inside a paragraph template does not work either with the same result. Best bet with the template names is to just do it from AdminCentral.
In its previous incarnation on JspWiki, this page was last edited on Feb 9, 2007 10:27:30 AM by DSmithAtCornell
