(Semi-)automatic MODx migrations using Phing

MODx is a very popular PHP/MySQL content management system – no surprise when you look at its flexibility, light weight and ease of use. However, as any MODx developer will attest, it is not without its quirks.

One of those problems is the lack of (automated) support for maintaining separate development and staging or production environments, and migrations between those environments. MODx saves content, templates and code snippets in its database, without versioning. Even though the Revolution branch (MODx has recently launched the first release candidate) aims to solve this by introducing the Transport Package concept, many developers will still need to support installations that run on MODx Evolution.

The code featured in this blog post is a mix of a Phing task that is executed on the development machine, and a small script that is uploaded to the staging or production machine. The task uses the MODx manager log to detect the changes made since a particular date. It then tries to match those changes to the database on the staging/production machines, and collates the changes to a SQL file.

In my case, I usually can’t access a production database from my development machine – this is where the updserver script comes in. It returns mysqldump-style output to the Phing task, and should be uploaded to your staging / production machine and installed in the same directory MODx resides in.

The syntax of the task call in the build file is as follows:

<?xml version="1.0"?>
<project name="MODx update" default="update">
        <target name="update">
            <taskdef name="modxchanged" classname="ModxChangedTask"/>
                hostname="localhost" username="root"
                password="test123" database="modx123"
                remoteurl="http://localhost/modx/" remotekey="test123"
                prefix="" timestamp="${timestamp}"/>

In this example, MODx is installed on localhost/modx/. The remote key is the same as the remote database password.

Running the task should result in an SQL file that can be executed on the staging/production machine, and output similar to the following:

MODx update > update:
Searching changes from 1970-01-01:
===== Templates =======================================
===== Documents =======================================
[ 10] Test                          2010-03-24 19:58:41 [NEW]
===== Chunks ==========================================
===== Snippets ========================================

The code in this post is very much a work-in-progress, so there are a few caveats / unimplemented features:

  • Does not correctly handle conflicting/shared id’s
  • Does not process deleted items
  • Checking (and manually adjusting) the generated SQL file is always a good idea

Any comments or questions are highly appreciated! You can also e-mail me directly at info AT touchdownconsulting.nl!

DOWNLOAD (modx-migration-286.tgz)

Michiel Rook

Michiel Rook is an experienced, passionate & pragmatic freelance coach, developer & speaker from the Netherlands. He loves helping teams and companies to develop better software and significantly improve their delivery process. When he’s not thinking about continuous deployment, DevOps or event sourcing he enjoys music, cars, sports and movies.

2 thoughts on “(Semi-)automatic MODx migrations using Phing

  • November 29, 2011 at 4:03 pm

    Hi Michiel,

    Did you continue working on this script ? Do you also have the same kind of script for Revo (or do you use VersionX or Transport mechanism)?


  • March 4, 2012 at 11:04 am

    Hi Jean,

    The script should still work for Evolution setups, haven’t gotten around to update it to work with Revo yet – but the Transport mechanism might be a better solution anyway 🙂



Leave a Reply

Your email address will not be published.