With the amount of plugins published in the symfony site, many great plugins get lost in the maze. With this series of posts, we would like to bring some attention to plugins we use every day or that we think are essential for any symfony developer.

sfSyncContentPlugin

Deploying symfony applications is always a key part of developing and maintaining websites that run on symfony. It is always a recommended practice to do development on a local environment or dedicated development server. It is also recommended to have a QA/staging server that is as close as possible to your production server. Using this well proven method you can spot problems and bugs before everybody else sees or experiences them, you know, those bugs that “only” happen in production, don’t tell me that it never happened to you, I won’t believe you.

Anyway, making changes in a live site is not only not recommended, it should never be done!

When developing and testing symfony applications, a lot of times you need to have a copy of the live data. Or you may have a staging server where you make changes before pushing them to a live site in a production server. symfony already provides a way to deploy code changes to a remote server, but what about uploaded and data files? And database content?

Since we discovered and started using it, we can’t live without the sfSyncContentPlugin plugin by Tom Boutell and Alex Gilbert, also developers of Apostrophe CMS. This plugin helps with all the tasks and needs described above. Using it is quite simple. All you need to do is define your servers in config/properties.ini like this:

[qa]
  host=qa.example.com
  port=22
  user=user
  dir=/var/www/mysite

[prod]
  host=www.example.com
  port=22
  user=user
  dir=/var/www/mysite

[staging]
  host=staging.example.com
  port=22
  user=user
  dir=/var/www/mysite

Make sure to use SSH keys to authenticate to your remote servers, so you don’t get asked again and again for passwords. Then just run the following symfony tasks:

# Migrate files and DB from development to qa
./symfony project:sync-content frontend dev to qa@qa

# Migrate files and DB to production (always make a backup of production before doing this!)
./symfony project:sync-content frontend dev to prod@prod

# Migrate files and DB from QA into development
./symfony project:sync-content frontend dev from prod@prod

Files and DB content are copied accordingly, almost magically. It saves so much time, but please make sure you understand and check the order that you apply in the symfony task. With the power this plugin provides, is very easy, by mistake, to overwrite production data, so again, always make a backup!

You probably have read about all the buzz surrounding Doctrine these days. Its support for migrations (the ability to upgrade/downgrade the database schema) is pretty awesome. However, migrating to Doctrine from Propel 1.4 can be challenging on a large scale project. Don’t fret, it turns out that there is a cool little plugin that provides migrations for those that are locked in the Propel world. As described in the plugin page, the sfPropelMigrationsLightPlugin allows to “Easily change the database structure without losing any data.”

The main difference between Doctrine’s migrations and sfPropelMigrationsLightPlugin is that you have to write the code to alter your tables, where as Doctrine can generate these by looking at the differences in the local schema file and the DB. The plugin page describes the use which is fairly simple: create the migration class, add the code to the up() and down() methods and finally run the migrate task (ie. symfony migrate frontend 42)

Automating the deployment process is an important part of delivering software and avoiding problems. This plugin surely helps in this regard and we recommend its use if you are using Propel. And remember to always backup before you migrate anything!

Symfony’s forms are very powerful and big time-savers. Also, thanks for the integration with an ORM like Doctrine or Propel, managing dates is quite easy. But by default, symfony displays date fields as regular select lists where you pick the date (month, day, year, hour, minute)

It is actually quite easy to enhance this functionality and display a friendlier way to pick a date. There are several options at your disposal:

sfFormExtraPlugin

The sfFormExtraPlugin plugin has numerous widgets to improve the appearance and functionality of form input fields. One of them is sfWidgetFormJQueryDate which displays a button next to your field. When clicking on it, a date picker calendar-style pops up.

Note: You will need to download the jquery theme to make it look pretty.

To use it, simply install the plugin and add the following to your form configure() method:

        $this->widgetSchema['publish_at']= new sfWidgetFormJQueryDate();

Also, make sure you load the jquery javascript files in view.yml:

  javascripts:
    - http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js
    - http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js

sfJQueryUIPlugin

The sfJQueryUIPlugin plugin is a nicer option. It displays a date picker when you click on the date input field, but it still allows you to modify it manually.

Installation is also quite easy. Install the plugin and add the following to your form configure method:

        $this->widgetSchema['publish_at']= new sfWidgetFormDateJQueryUI(array('change_month' => true, 'change_year'=> true));

Unobtrusive Datepicker

The Unobtrusive Datepicker by Massimiliano Arione is probably the nicer of the options, but also the less straightforward as there is no aparent plugin for it yet.

Follow the instructions on the site to get it working.

Any others?

Have you found any other solutions? Let us know and share it with us!