Revo Migration

What’s the status on migration tools for moving Evolution sites to Revolution?

Is there anything I can play with yet?

The work quite well, but I’m not sure how to use them. Jason will chime in a few hours or so when he wakes up.

(Test runs on the MODx site itself with over 2000 docs took around 20 seconds, produced a 17MB log file and the site almost worked without a hitch. A couple of OLD snippets needed to be updated, but that’s about it!)

Thats great news Ryan! I think the sites will need some work are those who used lots of snippets other than ditto, wayfinder etc. But I believe once beta is out, developers will take time to port their code to revo, which will make the things pretty easy for average sites.

Um . . . can a person (me, for example), acquire these migration tools?

If you pester Jason enough I would think so; they could probably use some documentation for Confluence, too.

Please see http://modxcms.com/forums/index.php/topic,12445.msg82679.html#msg82679

Thanks, I remember that as being kind of experimental. Is there a new version of modTranslate095?

I’m also a little hazy on how to use this.

Use it an 0.9.6 install (after copying in the new modTranslate05?) and then do an upgrade to Revo?

We should probably have a set of steps somewhere describing the full process.

Well, it’s obviously been a while since I’ve even looked at this, but no, there is no new version yet. I’ll do some work on it in relation to all the latest Revolution developments soon and start a wiki page about it.

Eventually, the setup process will include an option to execute processes that use this class when running an "upgrade from MODx Evolution/0.9.x", but we’re not quite there yet. Once beta is declared and we have our baseline for release, more progress will be made on this.

In the meantime, you’ll have to install a clean revo, then import the data and copy the dependent files manually that you want to include in the translation. Again, all this does is translate tags from old format to new format, with a little but of scripting, you could use this to translate any string or character database field you want to work with. The script currently works on files and/or tables represented by xPDO classes. It’s fairly accurate, though be careful with PHP includes and scripts in snippets/plugins/modules as they can contain syntax that mimic certain legacy tags, e.g. $array[($index-1)] would be translated to $array[[++$index-1]] as a side-effect. Similar issues with js content if you have any MODx tags nestled in there. CDATA tags may also cause some inaccuracies, though generally will not.

I see a couple of other issues. One is the assets/snippets->components change which will effect a lot of paths. The other is that, IIRC, some DB field names and structures are different for Revo so I don’t think a straight import of an 0.9.6 SQL dump will work (I hope I’m wrong about this).

Quote from: BobRay at Feb 05, 2009, 05:34 PM

I see a couple of other issues. One is the assets/snippets->components change which will effect a lot of paths.

That has nothing to do with converting tags or upgrading the core data and is not in the scope of anything that will be automated. People depending on specific components will have to rely on component-specific migration tools/guides to deal with any changes other than their use of legacy tags. assets/snippets or components or whatever is arbitrary IMO; the paths that people choose to store their components in are up to them and may depend on any number of determining factors. That’s important in keeping MODx flexible. Also remember that MODX_ASSETS_PATH will represent a dynamic location for multi-site installations to share common assets, while $modx->config[’assets_path’] will represent context-specific assets locations.

That said, a majority of the less complex components (i.e. ones that didn’t introduce their own parsing and templating methods) will work after simply being run through the tag conversion process.

Quote from: BobRay at Feb 05, 2009, 05:34 PM

The other is that, IIRC, some DB field names and structures are different for Revo so I don’t think a straight import of an 0.9.6 SQL dump will work (I hope I’m wrong about this).

If you dump data from the specific tables you want content from (site_content, site_htmlsnippets, site_plugins, site_snippets, etc.) and make sure to use complete and extended inserts for the dump format, everything should be importable. You just may need to doctor some of the data.

In the end, there will be a simple xPDO model for the source database structure (i.e. 0.9.6) with different class names which will be used to read data from the legacy tables and either create a transport package that can be installed containing the legacy data in vehicles constructed with the new Revo classes, or written to and saved to the Revo classes/tables in real-time (using two separate databases or two sets of tables with different table prefixes).