Symfony 1.2 currently uses Doctrine 1.0. Doctrine 1.1 was released in March. Symfony 1.3 will support Doctrine 1.1, but won’t be released until November.

Since I’m starting a new project, I wanted to try to use the latest version of Doctrine. I’ll be honest, I don’t have a great reason for doing this other then the pain I went through migrating an old project (with lots of custom model stuff) from Propel 1.2 to Propel 1.3. I understand this is an apples to oranges comparison, however its the only motivation I’ve got. Feel free to stop reading now.

Overall the Symfony developers have made it extremely easy to use Doctrine 1.1 with Symfony 1.2. However, given this is an unsupported configuration, they don’t back-port any patches related to Doctrine 1.1 from the Symfony 1.3 branch to sf 1.2. In this post I will try to catalog the changes and provide a back-port patch you can use to integrate Doctrine 1.1 into your sf 1.2 projects.

Related Postings

Here are some pages/tickets/changesets related to Doctrine 1.1 with Symfony. If I’m missing something, please leave me a comment below and I’ll update this ASAP!

Installing Doctrine 1.1

To get started using Doctrine 1.1, you’ll need to download it. Jonathan Wage provided instructions here which I’ll reproduce below.

From your Symfony project’s root folder:

Now change the location of the Doctrine lib path by editing your ProjectConfiguration::setup() method to look similar to:

public function setup()
{
  sfConfig::set('sfDoctrinePlugin_doctrine_lib_path', sfConfig::get('sf_lib_dir') . '/vendor/doctrine/Doctrine.php');
}

Patch Symfony Library

Now you need to patch the Symfony library with the back-ported changes related to Doctrine from the Symfony 1.3 branch. This patch is very simple, and currently only effects one file.

Navigate to your Symfony lib directory. Depending on how you started your project, this is probably the lib/symfony directory in your project.

Now rebuild your model forms. From your project’s root directory:

Patch sfDoctrineGuardPlugin

If you use the sfDoctrineGuardPlugin you will need to apply another patch.

From your project’s root directory:

Finished!

You should now be able to use Doctrine 1.1 with Symfony 1.2. I haven’t run into any problems using it, however I’ve just gotten started with my new project and haven’t done much of anything yet! If you have troubles let me know.

For anyone on Gentoo, I have a symfony ebuild in my Gentoo Overlay that will install Symfony 1.2 with Doctrine 1.1 support for you.

I’ll try to keep this post updated if I come across anything else that needs to change when using Doctrine 1.1 with Symfony 1.2.

The reCAPTCHA client API provides a reload javascript method that will grab a new set of words for the user to decode. It was easy enough to display a small error message above the reCAPTCHA div and call this method when the user responds incorrectly.

In a typical setup, as described in the reCAPTCHA client API, the standard theme can display an error message when the user responds incorrectly. This is done by appending an error URL parameter to the challenge. The error message I was adding via javascript was showing up above the reCAPTCHA module rather than just above the text box. I wanted to display the error message included in the standard reCAPTCHA theme.

Though I’m sure there are several ways to accomplish my goal, I settled on a very easy, but very unsupported solution (read: HACK):

The message the standard template displays just above the input textbox is controlled by a class set on the recaptcha_widget_div element. A class of recaptcha_nothad_incorrect_sol causes “Type the two words:” or “Type what you hear:” to be displayed while a recaptcha_had_incorrect_sol class causes “Incorrect. Try again.” to be displayed. So to display the default error message all you need to do is change the class of the recaptcha_widget_div element.

Trying to mix this with the reCAPTCHA reload method doesn’t work as you might expect. The reload method causes an AJAX request to be sent to the reCAPTCHA server. When the response arrives, the reCAPTCHA module is updated. If you modify the class before the response arrives, your updated class will be overwritten. To fix this, you can override the default response callback Recaptcha.finish_reload.

So my final solution (hack) looked something like this (please note, the page in question was already loading the prototype library so I used it):

if(typeof Recaptcha.old_finish_reload === 'undefined') {
   Recaptcha.old_finish_reload = Recaptcha.finish_reload;
   Recaptcha.finish_reload = function(a, b, c, d) {
      Recaptcha.old_finish_reload(a, b, c, d);
      $('recaptcha_widget_div').removeClassName('recaptcha_nothad_incorrect_sol');
      $('recaptcha_widget_div').addClassName('recaptcha_had_incorrect_sol');
   };
}
Recaptcha.reload();