sfPropelSyncContentPlugin - 0.2.0

A Symfony sync command for content (databases, uploads, etc)

You are currently browsing
the website for symfony 1

Visit the Symfony2 website

« Back to the Plugins Home


Forgot your password?
Create an account



advanced search
Information Readme Releases Changelog Contribute
Show source | Show as Markdown


Symfony makes it easy to sync code between your development, staging and production servers. But what about content? Deploying content to other servers typically does not happen on the same schedule as the deployment of code. And Symfony's rsync support doesn't address the issue of copying databases. So if you're like me, you're sick and tired of copying database dumps around during the early stages of deploying a site. sfPropelSyncContentPlugin to the rescue!


Your project must use Propel. This is simply because the code currently assumes the Propel entry in database.yml is the one you want, and I haven't done any work to parse and properly handle settings for other databases. It wouldn't be hard to patch this to make the plugin more universal (hint, hint).

Your project must use MySQL. This is because the code relies heavily on the mysqldump and mysql commands. This would be harder to patch unless your preferred database offers equivalent commands.

Your hosts must have the mysqldump and mysql commands in the PATH.

Both the source and the destination should be running some flavor of Unix (MacOS X should be fine, but watch out for mysql and mysqldump not being in the command line path, you may have to fix that; Linux, of course, works great).


With this plugin installed, you can synchronize your local database with the remote database on the staging server with the following command:

symfony propel-sync-content frontend dev from prod@staging

This downloads the database FROM the staging server, using the "prod" environment settings, and writes its contents to the database associated with the local Symfony project using the "dev" environment settings. We accept no responsibility for the consequences of failure to understand the words "FROM" and "TO" or use the correct environment settings.

You can also move your data in the opposite direction:

symfony propel-sync-content frontend dev to prod@staging

This copies the database from the local project (using dev settings) TO the staging site (using prod settings).

You can also copy to and from production servers, etc., etc.- if it's listed in config/properties.ini, you can sync content with it:

symfony propel-sync-content frontend dev to prod@production

You can also specify files and directories to be copied over via rsync at the same time. Here's a snippet of our apps/frontend/config/app.yml:

    # The database is content, of course, but what else?
      # Almost always

      * "web/uploads"
      # If you use sfLucene

      * "data/index"

About Those Pesky Password Prompts

This task will ask for your ssh password... a lot. That's not a bug. However, you can make it go away by following (and understanding) this HOWTO:


Obviously this is a security risk in the event the laptop you are syncing from should be stolen. You must IMMEDIATELY remove the entry for your machine from authorized_keys on the remote server in that situation.


  • Version 0.2 changes the syntax a bit to require an environment name for the remote Symfony site as well. This adds flexibility and helps to prevent the accidental use of inappropriate database settings.


This plugin borrows a few nifty functions from sfLucenePlugin, the license of which is included in our LICENSE file.


"Why do I have to specify an application?" The content settings live in app.yml, and initializing the Symfony environment without an application appears to be difficult at least in 1.0. Pass frontend or whatever your main application is.

"Why do I have to specify an environment?" This one is a feature: different sections of app.yml can come into play depending on the environment. Even more important, databases.yml can also have separate dev and prod environment sections accessing entirely different databases, one reason why I now require that you explicitly specify the environment for the remote site as well.

"Why doesn't it work in 1.1 or 1.2?" I have no idea whether it works in 1.1 or 1.2. Try it. Send me patches that don't break 1.0 (unless a branch is truly necessary due to major architectural changes).

Additional Disclaimer

This is a power tool, for grownups only. We accept NO responsibility for the consequences of using this tool. If you are not backing up your databases, and you fail to understand the meaning of "from" or "to," don't come crying to us. Seriously.

That said: it's very useful. Enjoy. (:


Tom Boutell, tom@punkave.com P'unk Avenue LLC, www.punkave.com

Released under the MIT license. See the LICENSE file for details.