Propel is complaining about a table that doesn’t exist

When you change your mind about your schema, and rename or remove any of your tables from your schema.yml or xml files, you must manually remove all the related classes in the lib/ folder.

Symfony does not delete these unused files when you run a build, so they will stack up and cause Propel errors, for example when calling propel-dump-data.

Of course you can safely delete the lib/om and lib/map folders and run the build again, but you should manually delete the relevant files in /lib as there could be some user generated content in there also. These files are unlikely to cause any errors but might as well be deleted as part of your clean up since they are effectively useless if you have removed their referenced tables from the schema.

Help! Symfony is ignoring my settings in app.yml

Something that just cropped up today…

As your site grows, and you add more and more config to the app.yml file, be very careful not to re-declare the same named element. Symfony will not warn you, and there will be no errors – but the second (lower) instance will simple overwrite the first!

For example, if you have forgotten that you already have an element called profile hiding near the top of the file, and you add another one called profile at the bottom, with all your profile page settings – the lower one will destroy the one higher in the file.

This can be hard to spot if you have been meticulously coding and added a default value to all your sfConfig::get() calls because chances are when you are developing the site, all your defaults will be the same as the ones you have specified in app.yml.

The problem will become apparent when an end user tries to change the configuration and the change is ignored, because Symfony is simply using the default value rather than the one the user thinks they are setting.

Careful out there kids!

When the pager_navigation function does not create the correct link…

If you have used a route name in the call to this function, it will be parsed based on your routing.yml file, this means that if you don’t have a :page variable listed (and you probably don’t) the route will ignore the page argument that the pager function tries to add.

The easy solution is to add /* to the end of your routing rule, so that any other parameters are allowed.


  url:   /somewhere/:userid/*
  param: { module: myModule, action: myAction }
  url: etc

Now your routing functions will add any extra parameters as necessary.

Email validator bug

The problem

There is a bug in Symfony’s email validator which means that unless you use both modes (strict and non-strict) invalid email addresses are possible.

Time of writing we are at version 1.0.13 – this could well be (and probably will be) fixed in 1.1 but please let me know if you spot that this has been fixed beforehand.

Strict mode validation

This mode is intended to catch email addresses such as root@localhost, but unfortunately it does not check for valid email strings, so %, would be accepted, as well as many other illegal character combinations.

Non-strict mode

This mode checks that the email address contains legal characters, but does not check for internal addresses. This is fine for most cases, but it is worth restricting users from using your site to spam your local mail server.

Solution 1

Sapheriel suggests on his blog that one solution is to override the functionality of the class, and then restore it once an update has been released.

“The best way to achieve this with the least amount of intrusion is to copy sfEmailValidator.class.php into your project’s library folder, modify it, and delete it once a fix has been published”

This may suit many users

Solution 2

If you do not want to worry about something you may have to do in the future, you can also run the validator twice, for example in your validator.yml file:

  class: sfEmailValidator
    class: sfGuardUser
    column: email
    strict: true
    email_error: This email address is invalid
      msg: Please enter an email address
      email_error: This email address is invalid
      strict: false
      class: sfGuardUser
      column: email
      unique_error: This email is already in use

You could also write a custom validator which calls the email validator twice, however we have opted for this solution for now.

Thanks to June for the content.