The first way, and the easiest, is to simply unset the fields in your form class:

class SampleForm extends BaseSampleForm
{   
  public function configure()
  {
    unset(
      $this['created_at'],
      $this['updated_at']
    );
  }
}

If you want the values to display in your form as read-only:

class SampleForm extends BaseSampleForm
{   
  public function configure()
  {
    $this->widgetSchema['created_at']    = new sfWidgetFormInput(array(), array('readonly'=>'readonly'));
    $this->widgetSchema['updated_at']    = new sfWidgetFormInput(array(), array('readonly'=>'readonly'));
  }
}

class NewsletterForm extends BaseNewsletterForm
{
  public function configure()
  {
    $this->widgetSchema['file'] = new sfWidgetFormInputFileEditable(array(
      'file_src' => '/uploads/'.$this->getObject()->getfile(),
      'is_image'  => true,
      'edit_mode' => !$this->isNew(),
      //'template'  => '<div>%file%<br />%input%<br />%delete% %delete_label%</div>',
    ));
 
    $this->validatorSchema['file'] = new sfValidatorFile(array(
      'required' => false,
      'path' => sfConfig::get('sf_upload_dir')
    ));
 
    $this->validatorSchema['file_delete'] = new sfValidatorPass();
  }
}

If you want to override the file name generated for your uploaded file, add a ‘generateXXXFileName()’ method to your model’s class where XXX is the column name that contains the file name (in this example, our column is “file”, so the method name is ‘generateFileFilename’. It takes a single parameter, which is an instance of sfValidatedFile.

class Newsletter extends BaseNewsletter
{
  public function generateFileFileName($file)
  {
    return $file->getOriginalName();
  }
}

I wanted to ignore timestamp and permissions differences, which wasn’t possible using the default configuration due to the -a (which stands for ‘archive’ mode) parameter added to the rsync command. If you want to override the default settings, all you have to do is add a ‘parameters’ key to your properties.ini file. Here is an example:

  [staging]
    host=yourhostname
    port=22
    user=yourusername
    dir=your/path/to/your/app
    parameters='-rlDzC --force --delete --exclude-from=config/rsync_exclude.txt'

Keep in mind if you set your own custom parameters you won’t benefit from any of the default settings so you should include them yourself (like –force, –delete, and your rsycn_exclude file).

With the help of the sfPropelMigrationsLightPlugin plugin, one of my favorites, I have been rapidly making changes to my plugin schema and adding new data to the database over and over again while I mock things up.

Here is the workflow:

1. make changes to the plugin’s schema.yml file, in plugins/myPlugin/config/schema.yml
2. make changes to the plugin’s fixtures file, in plugins/myPlugin/data/fixtures/fixtures.yml
3. rebuild the model
4. rebuild the sql
5. copy the plugin’s sql to the migration sql source file
6. run the migration
7. load the fixtures

This gives me my new schema and populates it with whatever data I have in the fixtures.

Optionally, if I want to go back and make another change, I migrate down a version first, then run through the process above.

The trick is to make your migration run an external SQL file, and to use the plugin’s generated SQL as the source for that migration.

Here is my migration (remember this uses the sfMigrationsLightPlugin):

<?php
 
/**
 * Migrations between versions 033 and 034.
 */
class Migration034 extends sfMigration
{
  /**
   * Migrate up to version 034.
   */
  public function up()
  {
    $this->loadSql(dirname(__FILE__).'/034_stDataflow.sql');
  }
 
  /**
   * Migrate down to version 033.
   */
  public function down()
  {
    $this->executeSQL("SET FOREIGN_KEY_CHECKS = 0;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_import_map`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_profile_history`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_batch_import`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_batch`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_profile`;");
    $this->executeSQL("SET FOREIGN_KEY_CHECKS = 1;");
  }
}

Here’s how I run it, once I have completed my new schema.yml and fixtures.yml changes.

# if this is not the first time I'm going through this process, 
# I need to migrate back a step to remove my old plugin tables
./symfony migrate myapp:dev 33  #33 is my previous migration number
>> migrations migrated 1 step(s)
>> migrations current database version: 33
$ ./symfony propel-build-model
cp data/sql/plugins.stDataflowPlugin.lib.model.schema.sql data/migrations/034_stDataflow.sql
./symfony migrate npas:dev 34
>> migrations migrated 1 step(s)
>> migrations current database version: 34
./symfony propel-load-data npas dev plugins/stDataflowPlugin/data/fixtures/fixtures.yml
>> propel    load data from "plugins/stDataf...gin/data/fixtures/fixtures.yml"

It’s nothing novel, but a good example of using the tools to improve the workflow.

Jump to the By Format or By Version.

By Format:

• Getting Started:
  • Getting Started (1.4)
  • Getting Started (1.2)
  • My First Project (1.2)
  • My First Project (1.0)
• Tutorials (Jobeet / Askeet / Cookbook)
  • Jobeet (1.4, Propel)
  • Jobeet (1.4, Doctrine)
  • Jobeet (1.2, Propel)
  • Jobeet (1.2, Doctrine)
  • Askeet (1.0)
  • More with symfony / advanced tutorials (1.4)
  • Cookbook (1.2)
  • Cookbook (1.0)
• “The Book”:
  • The Definitive Guide to symfony (1.2)
  • The Definitive Guide to symfony (1.0)
• Reference Guide (configuration, events, tasks):
  • symfony Reference Guide (1.4)
  • symfony Reference Guide (1.2)
• Admin Generator:
  • Admin Generator (1.2)
  • Admin Generator (1.0)
• Forms:
  • symfony Forms in Action
  • symfony Forms (1.2)
• API:
  • API (1.4)
  • API (1.2)
  • API (1.0)
• Installing/Upgrading:
  • Upgrade (1.4)
  • Upgrade (1.2)
  • Installation (1.4)
  • Installation (1.2)
  • Installation (1.0)
• What’s New:
  • What’s New (1.4)
  • What’s New (1.2)
  • Deprecated (1.4)

By Version:

• Symfony 1.3/1.4
  • Getting Started (1.4)
  • What’s New (1.4)
  • Upgrade (1.4)
  • Deprecated (1.4)
  • Jobeet (1.4, Propel)
  • Jobeet (1.4, Doctrine)
  • symfony Reference Guide (1.4)
  • More with symfony / advanced tutorials (1.4)
  • API (1.4)
  • Installation (1.4)
• Symfony 1.2
  • Jobeet (1.2, Propel)
  • Jobeet (1.2, Doctrine)
  • symfony Reference Guide (1.2)
  • The Definitive Guide to symfony (1.2)
  • symfony Forms (1.2)
  • Cookbook (1.2)
  • API (1.2)
  • Getting Started (1.2)
  • What’s New (1.2)
  • My First Project (1.2)
  • Admin Generator (1.2)
  • Installation (1.2)
  • Upgrade (1.2)
• Symfony 1.0
  • The Definitive Guide to symfony (1.0)
  • Cookbook (1.0)
  • API (1.0)
  • My First Project (1.0)
  • Askeet (1.0)
  • Cookbook (1.0)
  • Admin Generator (1.0)
  • Installation (1.0)

Symfony Experts.

The site is very well designed and will prove to be a valuable resource for developers of all skill levels — experts can make some extra money sharing their expertise, and beginners (or experts encountering a new problem) can get quick and succinct answers to their questions.

From the about page:

Symfony Experts is problem-solving community for Symfony, ideal for users seeking quick, succinct answers they can’t find in any Symfony forums. Symfony Experts is also great for established Symfony developers who want to help problem-solve and be paid fairly for their efforts.

I highly recommend it.

>> doctrine Could not create database for c...o use near '-sb-test' at line 1

Turns out the issue is with the “-” in my test database name. Replacing the hyphens with underscores fixed the problem.

500 | Internal Server Error | Doctrine_Validator_Exception
 1 field had validation error:
 * 1 validator failed on file (type)

The short solution: when using a doctrine form class and $form->save(), set the path option in your sfValidatorFile validator and do not attempt to save/set the file column yourself. If you are curious why this is, continue reading.

What was particularly strange about this error is that the “file” column in my model was defined as a string, and I was certain I was setting this column by hand to the file name (a string) of the uploaded file. Hmm… this shouldn’t trigger an error, should it? This following is what did not work. I used the documentation for sfValidatorFile() found in the symfony Forms book.

// my form
class ArtistForm extends BaseArtistForm
{
  public function configure()
  {
    $this->widgetSchema['file'] = new sfWidgetFormInputFile();
    $this->validatorSchema['file'] = new sfValidatorFile(array(
      'required' => false, 'mime_types' => 'web_images'
    ));
  }
}
 
// my action ***did not work***
public function executeForm(sfWebRequest $request)
  {
    $this->form = new ArtistForm();
    if ($request->isMethod('post')) {
      $this->form->bind($request->getParameter('artist'), $request->getFiles('artist'));
      if ($this->form->isValid())
      {
        $file = $this->form->getValue('file');
        if ($file) {
          $filename = sha1($file->getOriginalName());
          $extension = $file->getExtension($file->getOriginalExtension());
          $file->save(sfConfig::get('sf_upload_dir').'/'.$filename.$extension);          
          $this->form->getObject()->setFile($filename.$extension);
        }
 
        $this->form->save();
      }
    }    
  }

Anytime I’d try to upload a file, I’d get the dreaded “Doctrine_Validator_Exception”, “validator failed on file (type)” message. After some serious googling, I came up with a few links (listed at the bottom of this post) that eventually led me to the solution. The issues boils down to this:

• When using the sfValidatorFile widget in your form, retrieving that value from your form returns an sfValidatedFile object
• Doctrine forms will automatically try to process and save uploaded files, so you do not need to do this manually in your action if you call $form->save() and your form contains an instance of sfValidatorFile
• The automatic save mechanism in your doctrine form will fail if you do not define a path in your sfValidatorFile validator. This is because if no path is defined in your validator, the validator returns an instance of sfValidatedFile and calling $form->save() will result in trying to update your doctrine object with this sfValidatorFile instance, resulting in an error.
• If a path is defined in your sfValidatorFile validator, the bound form value for your file input field is set to the full path to saved file rather than an sfValidatedFile instance, allowing your doctrine object to be saved.

Now, with a deeper understanding of how this is all put together, we can update our action:

// doctrine form class
class ArtistForm extends BaseArtistForm
{
  public function configure()
  {
    $this->widgetSchema['photo'] = new sfWidgetFormInputFile();
    $this->validatorSchema['photo'] = new sfValidatorFile(array(
      'required' => false, 'mime_types' => 'web_images',
      'path' => sfConfig::get('sf_upload_dir')
    ));
  }
}
 
// the action
  public function executeForm(sfWebRequest $request)
  {
    $this->form = new ArtistForm();
    if ($request->isMethod('post')) {
      $this->form->bind($request->getParameter('artist'), $request->getFiles('artist'));
      if ($this->form->isValid())
      {
        $this->form->save();
      }
    }    
  }

More about this issue in the forums and mailing list:

• http://forum.symfony-project.org/index.php/m/74831/
• http://groups.google.com/group/symfony-users/browse_thread/thread/668a44a52a775938/3d55c8bb40290dbe?show_docid=3d55c8bb40290dbe

Haven’t tried this but hope to, soon!

1. Checkout code from SVN into your ~/Sites folder. From the command line do:

svn co [path to repository] ~/Sites/[projectname] --username [username]

After the checkout, go into your new [projectname] directory and do a fix permissions:

./symfony fix-perms

2. Create a new virtual host in apache. You can skip this step but I find it makes things easier. My entry in my apache .conf file (on my mac its located at /etc/apache2/users/[username].conf where [username] is the username on my mac) looks like this:

<VirtualHost *:80>
	ServerName [projectname].local
	DocumentRoot /Users/[myusername]/Sites/[projectname]/web
</VirtualHost>

I also have add this new domain to my local hosts file at /etc/hosts:

127.0.0.1   [projectname].local

then i restart my webserver with a “sudo apachectl graceful”.

3. set up your local database. On my mac I use Sequel Pro to create the database. I run a..

./symfony propel-build-all

..to regenerate the sql and base model classes. Often I don’t like to commit auto-generated code to svn but rather just the source files from which the new code is generated (you can read the side bar “Best Practice: Checkin all the canonical stuff, and nothing else” with one view on this at http://www.ericsink.com/scm/scm_repositories.html).

Once that is done, normally I would insert the db schema into my new database, like this:

mysql -u root [dbname] < data/sql/lib.model.schema.sql

… but sometimes I want to use a lot of the same basic data from before, so I insert database dump that has actual content:

mysql -u root [dbname] < data/sql/latest.sql

4. configure the symfony project to use your new db. You’ll have to copy the config/databases.yml-dist to database.yml and add your own settings there. The databases.yml file is ignored in our repository, so that way the devs can keep different local configuration settings for our dev environment without having to create lots of different symfony environments (usually I keep them to just dev, stage, production) in the project.

5. load up http://[projectname].local/frontend_dev.php to see if things are working!