An extension that provides a partial solution to the conundrum of moving builds between servers.

Ensembles and SQL dumps are great when you are moving a build one-way (development to production) as a one-time event. But what happens when your site is live, with people generating content, but you need to add sections and pages? So far the only workflow has been to build these locally, then recreate manually on production. Slow.

I investigated several more elegant options before falling back to this approach:

This extension (after you make the necessary update to the MySQL class) will log every structural change you make to Symphony (sections, fields, pages) but ignores content changes (authors, entries and data).

This means that you can export these queries and apply them to another build to bring it up to date, without touching the content.

I’ve briefly described our workflow in the README, to which this extension is very well suited.

Please note the warning and disclaimer in the README. I’m not to be held responsible if this extension does something nasty to your database — caution and backups are king :-)

Many thanks to Richard for taking my concept further and adding the options to the System > Preferences file.

Amazing work, this makes the process of pushing changes from a local build to a live environment so much easier@

Great! Thank you very much for sharing!

Nick, the README doesn’t say that you need the ASDC extension. Maybe you should add this.

Are there any other dependencies?

Thanks michael-e, I’ve updated the README. No other dependencies.

Thank you very much for this nick, it’s the one thing I’ve wanted from Ruby on Rails most. Thanks for putting in the work, it’s going to be very useful. :)

I didn’t know RoR had something similar. Perhaps there are takings that can be included in this extension. Could you provide some info/links for the RoR functionality please?

Sweet! Will be trying this out imminently. Thanks, Nick.

Here’s a description of what I believe Throlkim is talking about.

Aye, that’s spot on hoopy.
Essentially, you alter the db through migrations rather than the command-line/phpMyAdmin etc. When you move a whole install to another server, all you have to do is type rake db:migrate, and it iterates through every migration and builds your database. Or applies changes.

It’s pretty sweet!

Thanks Nick!

If anyone (Alistair?) has any ideas about getting this to work without a proprietary modification to the core, I’m all ears.

I considered a delegate inside the query method but this would be massively inefficient. The number of database queries Symphony would use would triple:

  • the original query
  • the query to look for extensions subscribed to a SqlQuery delegate
  • the query to log the SQL string in the chronological log

As it stands I currently double the number of queries, by firing an INSERT on each structural database query. This is fine in production environments, but I strongly recommend this doesn’t go anywhere near production.

By the way, thanks hoopy and Throlkim — the link is really interesting. I’m glad we’re able to do in Symphony what the cool kids are doing with RoR ;-)

I wonder if it’d be a worthwhile addition to have an admin panel extension that could sum up the changes to be made and a button to process the SQL. Might make the process even smoother!

Ruby on Rails is very cool, but Symphony has so far stopped me from learning it - it’s just too easy to make a site.

(and the community here is awesome!)

Thanks for putting this out there, Nick. Would be pretty cool if Symphony handled migrations similar to RoR, i.e., let you move up and down through DB structural changes.

I’ve been testing this out on a, relatively simple, project and it seems to work beautifully. Nice work, Nick.

Only bug I’ve come across is that my text input field validator seems to break, I’ve posted more detail on the Github issue tracker.

Thanks for this extension.

I haven’ tried it yet, and I’m wondering if it can be used to synchronize two development installations with the staging installation?

Perhaps. What is your exact workflow?

Unfortunately if you have two separate development versions, then you will undoubtedly run into concurrency versions. At Airlock we use a local server in the office for development — everyone connects to this one database but has an individual local copy of the source files (through SVN). So long as everyone has this extension installed, all changes are logged centrally and can then be pushed to a staging server.

However if two developers work entirely independently then this extension will not solve any problems. Since Symphony IDs are stored in Data Sources and Events, if both developers create a new section independently they could end up with different sections but of the same ID. When it comes to running both of their SQL logs on staging, things will be out of sync.

Thanks for the clarification. I thought about two entirely independend developers. So I’m going to use the setup with a central database for the different installations.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details