Lorem Ipsum is fun and all, but there's nothing quite like real content when you need to duplicate a problem that a client is experiencing with their website.
(Not that our websites ever have problems! That could never, ever happen! But let's just say it did.)
Frameworks like
Symfony include handy features to deploy new code to a staging or production site. Specifically, the project:deploy task, which is a simple wrapper around rsync that gets the job done.
This is a great thing. But what about the other half of the equation- deploying content... or pulling the production site's content back down to your own box for some seriously realistic testing?
This is where
sfSyncContentPlugin comes into the picture. With this handy plugin, you can just type this:
./symfony project:sync-content frontend dev from staging@staging
... And down comes the content from the staging server, beginning with the current state of the database and optionally followed by data folders, such as your uploads folder, search indexes and other data kept in the filesystem rather than the database.
You can also push content in the other direction. For instance, the day you launch the production site, you might do this to push content from staging up to production:
./symfony project:sync-content frontend staging to prod@production
(The seemingly redundant business with the '@' signs is there because Symfony distinguishes environments from servers. In practice ours tend to be the same, but your setup may vary.)
sfSyncContentPlugin isn't for every Symfony developer... just the 95% of you who use MySQL and, for now at least, only have one database in your project that should be synced. But as I said, that's the vast majority of Symfony projects. So we suspect this plugin will be as useful to others as it has been to us. We welcome code contributions intended to accommodate other databases, sites with multiple databases and so on.
You can pick up sfSyncContentPlugin here.
A quick aside to hardcore Symfony developers: we've been using this plugin internally for quite some time, but it was a bit of a hack until recently. Our code was parsing config/databases.yml manually, struggling to duplicate what Symfony already does. Fortunately I recently discovered the sfDatabaseManager class, which fetches everything you need to know about the database in exactly the same way Symfony does, because it
is Symfony. I recommend using it in any similar tasks you might be writing. Take a look at our source to see how it's put to work, in particular the sfSyncContentTools class.
