When I export my account from mahara.org to a leap2a file, and then try to import it into a clean Mahara 1.7 installation, I find that it creates all the pages, but some of the Pages are missing their blocks, or their block content.
The problem seems to be because it's processing the leap.xml file sequentially from top to bottom. The artefacts that cause problems are listed further down in the XML file than the View they are used in. When the View is processed, it can't find the artefacts, and so it drops their blocks.
Leap2a import should be fully backwards-compatible, and it should definitely work with Leap2a files from mahara.org itself, given how prominent a site that is. The solution would seem to be to come up with some way to make it less dependent upon the order that the items are in the XML file. Perhaps more cacheing, so that it doesn't have to map in the leap2a-IDs to real ones until the very end? Or maybe just cache the ones that have an ID that it isn't able to resolve?
I suspect this will not be a trivial issue to fix. The simplest thing we can do is to change our export format so that it puts artefacts first, but that won't solve for backwards compatibility. We should also take care that any solution is at least somewhat cross-platform compatible. So, for instance, parsing out all those that have a <mahara:artefactplugin> first, would probably be a bad idea because that's a Mahara extension to leap2a and won't solve this problem for leap2a's coming from other sources.
Which blocks were affected, Aaron? Just so we know what to watch out for testing.