Of course there’s the ticket in Symfony’s Trac with the files attached to it, but the attached php class is the wrong one. In order to use it, you had to apply the attached patch manually (which I guess caused some confusion).

However, I ran the unit test for the improved sfDateValidator against Symfony 1.0.14, and it still works very well. So, here’s the new download link:

Download the improved sfDateValidator for Symfony 1.0

You might want to head over to the old post on Symfoniac for a quick usage example.

I recommended downloading, or writing, a small validator which checked if the value of the checkbox is zero or one. But there’s a much simpler solution to this problem.

If you use a numerical value for your radiobuttons/checkboxes, simply call the sfNumberValidator with zero as an minmum and one as an maximum.

tos:
  sfNumberValidator:
    min: 0
    max: 1

If you use strings, such as ‘male’ or ‘female’ for a gender radiobutton, the sfStringValidator is the right choice:

sfStringValidator:
  values: ['male', 'female']
  value_error: Invalid value

SQL dump

The old database used a latin1 encoding for the database fields and utf-8 as the server and client connection encoding. With these settings, even trying to get a correctly encoded database dump from phpMyAdmin is a bad idea.

Using mysqldump with an explicitly specified character-set is much better:

mysqldump … –default-character-set=latin1 –skip-set-charset dbname > dump.sql

MySQL to PostgreSQL with JSON

After realizing that changing a MySQL dump to a valid PostgreSQL dump might take some time, Django’s ability to import and export database fixtures in JSON was a great alternative.

There were, however, a few corrections needed in order to import the data in PostgreSQL:

1. Date fields
   “0000-00-00 00:00:00″ might be valid MySQL datetime value, but it ain’t so in PostgreSQL. To import the data it is needed to replace such dates with valid ones like “1970-01-01 00:00:01″.
2. Boolean fields
   MySQL doesn’t support real boolean fields and instead uses tinyint. PostgreSQL, on the other hand, supports real boolean fields and doesn’t accept “0″ or “1″ as valid boolean values. Replacing “0″ with “”alse” and “1″ with “true” will help in this case.

How do you keep your model and database in sync?

A) You build your database in some other tools (e.g. phpMyAdmin) and run propel-build-schema followed by propel-build-model.

B) You write a schema.yml/xml file and run propel-build-all to generate the model, create and insert the sql.

Please state your opinion (or maybe a even better way) in the comments below.

The biggest advantage of using Git is that you can switch between various branches very easily and nearly instantly - even offline. However, Git’s SVN support isn’t perfect, so there’re also some drawbacks.

The method described here is perfect for testing your project with an older or even a newer version of Symfony.

Installation

If you installed Git over MacPorts, make sure you enabled SVN support:

port -v install git-core +svn

Clone the Symfony repository

The following command will clone the whole symfony SVN repository with all its revisions (over 7000), tags and branches in a folder called symfony.git. This takes some time, so better do something else. You can, however, always cancel and resume the checkout at a later time.

git svn clone -s http://svn.symfony-project.com/ symfony.git

Since all the stuff you just downloaded is taking up quite some space on your hard drive, you might want to run git gc to cleanup unnecessary files and optimize the repository (also takes its time but size went from over 200MB to just 50MB for me).

git gc

In Git, HEAD is always set to the branch where the last commit was made, this could lead to problems. Set it to the 1.0 branch for now:

git reset --hard 1.0

Externals

Of course, the SVN implementation in Git isn’t perfect. It mostly shows when using svn:externals which Git doesn’t support yet and therefore repositories must be fetched manually. In Symfony’s case this is pake and lime.

git svn clone http://svn.symfony-project.com/tools/pake/tags/RELEASE_1_1_5/lib/pake lib/vendor/pake
git svn clone http://svn.symfony-project.com/tools/lime/tags/RELEASE_1_0_4/lib lib/vendor/lime

Finishing up

Create a symlink that links to the Symfony command in our Git repository:

sudo ln -s /Users/arthur/Webdev/symfony.git/data/bin/symfony /usr/bin/symfony_dev

and checkout the latest stable version of Symfony:

git checkout tags/RELEASE_1_0_11

A few branches, like dwhittle, might have a slightly different directory structure. In this case, just adjust your symlink and eventually check out pake and/or lime again - most Symfony branches and tags do have the same layout though.

Remember to run git svn rebase (similar to svn update) once in a while.

git svn rebase

Connections

Let’s start by defining our database connections: open up the file config/databases.yml and create at least two connections with different names (like „database” and „database1”).

all:
  database:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://ptest:ptest@localhost/ptest 

database1:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://ptest:ptest@localhost/ptest2

Schema

In the config/propel.ini configuration file, go to the the sixth line and edit the „propel.database.url” setting so that it matches the first database connection.

propel.database.url = mysql://ptest:ptest@localhost/ptest

Now we can execute the propel-build-schema command.

The next little problem is that the schema generator always assumes that a connection is named „propel” but since we’ve named it „database”, we need to open the just generated schema file and rename the connection (second line).

Before we go on and generate the second schema, we first need to rename the current one or otherwise symfony would just overwrite it.

mv config/schema.yml config/1_schema.yml

(Note: schema files must end with „schema.yml”)

Second schema

The procedure to generate the schema for the second connection is basically the same as for the first one:

1. Edit the „propel.database.url” setting in propel.ini.
2. Execute propel-build-schema.
3. Open the schema and change the connection name from „propel” to „database1”.
4. Rename the generated schema.yml to 2_schema.yml.

Finally, we can execute the propel-build-model command and are ready to use our databases.

<script>
var RecaptchaOptions = {
   theme: 'clean'
};
</script>

For further reference check the API documentation. ReCaptcha’s like the one Facebook uses in their sign-up, can be created by using the ‘custom’ theme setting.

Just released a new version of the sfReCaptchaPlugin. The updated version 1.0.3 includes the recaptcha-php-lib 1.10, which mainly fixes some minor XHTML bugs.

Please note that the plugin does not work with the current symfony 1.1 branch. A update will be available after the first beta release.

If you’re using a previous version of the plugin, you can update to the latest version by executing:

symfony plugin-upgrade http://plugins.symfony-project.com/sfReCaptchaPlugin