Export to XML Script with self contained tar file?


(Tbaatar) #1

Hi,

I need to move across around 300 pages with child images and I was wondering how you go about creating self contained tar file with all the images like the export tool but using the export_to_xml.php script instead?

Thanks.


(David Schoen) #2

Something like:

# mkdir /tmp/my_export
# chown -R apache /tmp/my_export
# cd /tmp/my_export
# sudo -u apache php /var/www/matrix/scripts/import/export_to_xml.php /var/www/matrix 57:1 1 > export.xml
--------------------------------------
CREATING ASSET: text.txt
--------------------------------------
# tar cvzf ../my_export.tgz .
./
./export.xml
./export/
./export/Text_File/
./export/Text_File/57/
./export/Text_File/57/text.txt


(Tbaatar) #3

Hi David,

Thanks for the feedback.

I did pretty much everything the same however the exported file only gives me .xml file as opposed to .tgz.
Not sure if this makes any difference but I’m trying to export from Matrix 4.18.9.

In addition when importing the .XML file with all the text content into Matrix 5.4.X for News Item asset, it fails to create Body content and only creates the Summary content. Is this due to because the images that were referenced were missing?

In the end i just went with the export/import tool 30 times to move everything over.

The migration aspect of Matrix still seems very old and has not improved for the past 10-15 years. Are there any future plans to improve this?


(David Schoen) #4

Hi tbaatar, the tar is not generated by Matrix in my example it’s an explicit command and it’s worth noting that both the export and the tar depend on being within a directory that can be tarred up in its entirety with the way the commands are arranged. Nothing relevant to the tar generation above has changed since well before 3.16. The images would likely have been missing if you hadn’t created a directory and used cd to move in to it as per the example.

Internally Squiz uses Mirror and I think some Squiz clients have direct access as well. It’s the same kind of idea, but for cases like having to generate a tar to wrap up files and XML, the files are instead base64 encoded and inlined directly in side the XML. There’s also a lot of other reliability work and better feature support (preserving dates, both safe edit versions, tracking IDs between multiple installs for dev->uat->prod workflows, improved reliability, etc). I expect at some point we’ll be integrating that with core, but that’s not actively planned for yet.