Eat my monkeydust

The yaml file parser will attempt to parse all the values, rather than taking them as they are - which in most cases is a good thing, however you must remember to use quotes when the intended output is a string, and the parser may interpret the value otherwise:

default_culture:   en
// No problem, en is treated as a string 
// and /en/ is automatically added to links
 
default_culture: no
// Oops, no is translated by Symfony 
// the same way as false, 0 or off, giving it a boolean value!
 
default_culture: 'no'
// That's better, now you will have the intended results.

The same applies to any yml files that you may have “keywords” in, so try to always use quotes round everything that is not boolean, integer, etc.

This is a monster subject, and I spent a long time scratching my head over a few things yesterday, until I came across this site:

http://propel.jondh.me.uk/

It’s developed by a Symfony user, and allows you to type in sql statements using nested braces for prioritising. The form will then return a nicely formatted block of Propel code.

It’s not perfect, and it doesn’t cover everything just yet, but it’s great for getting some ideas about the structure and how to use various criteria - it’s also spot on if you are trying to learn Propel and already know how to structure SQL statements.

Discuss this tool and/or contribute on the Symfony Forum

Using a combination of tools like this, and taking a look at the generated files in lib/model/om should give you a good push, and a bit of a shortcut to more complex queries than you may be used to - rather than having to trawl the Propel documentation.

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.

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!

Trying to find out the length of a string and wondering why the values are often wrong?

UTF-8 characters can be multi-byte, and strlen() returns the length of the string in bytes, which means the string ååå would actually have a “length” of 6.

One solution is to use the multibyte function “mb_strlen” instead, you will need to have PHP compiled with this - but it seems to be a default in later versions.

E.g.

$value = "ÅØÆbob";
echo strlen($value);
// 9
 
echo mb_strlen($value, 'UTF-8');
// 6