fatvegan

We've just moved from CircleCI (which was excellent) to Codeship, because we couldn't afford the Github fees any more. It definitely wasn't as easy as CircleCI, and the UI isn't as tidy. But Codeship works pretty well so far. The Setup Commands for a Symfony app go something like this...

phpenv local 5.4
export SYMFONY_ENV=test
mysql  -u $MYSQL_USER -p$MYSQL_PASSWORD -e "CREATE DATABASE test"
unzip -p app/Resources/Tests/test.sql.zip | mysql -u $MYSQL_USER -p$MYSQL_PASSWORD test
echo "xdebug.max_nesting_level = 250" >> $HOME/.phpenv/versions/5.4/etc/php.ini
echo "memory_limit = 512M" >> $HOME/.phpenv/versions/5.4/etc/php.ini
cp app/config/parameters.yml.dist app/config/parameters.yml
sed -i "s/database_user:.*/database_user: $MYSQL_USER/;s/database_password:.*/database_password: $MYSQL_PASSWORD/" app/config/parameters_test.yml

composer install --prefer-source --no-interaction
app/console doctrine:migrations:migrate --env=test --no-interaction

I've just set up my latest Symfony project on CircleCI and it's working really well. CircleCI is very good, and the staff are amazingly helpful (even though I haven't given them any money yet). I spent a morning trying to set up Travis, without any luck. Seems to be some issue with private repos owned by organisations.

If you're trying to do your parameters the new Symfony 2.3 way, it takes a little extra work. And if your tests need the database, it takes a tiny bit more.

circle.yml

machine:
  php:
    version: 5.4.21
dependencies:
  override:
    - composer install --prefer-source --no-interaction
    - cp app/config/parameters_test.circle.yml app/config/parameters_test.yml
    - app/console doctrine:database:drop --env=test --no-interaction --force
    - app/console doctrine:database:create --env=test --no-interaction
    - app/console doctrine:migrations:migrate --env=test --no-interaction

app/config/parameters_test.circle.yml

parameters:
  database_name: circle_test
  database_user: ubuntu
  database_password: null

Using environment variables didn't work that well for me, because I've got a local testing environment as well. So keeping two versions (local and CircleCI) of the testing parameters file seemed to work better. I'll still probably use environment variables for production, although that would be something else that didn't get tested.

We've recently set up cPanel on VPS to host our big Symfony2 project. We were developing locally on a MAMP setup which was really fast. For production, we moved initially to a FastCGI shared host which was fairly fast as well. But to get PHP 5.3 we needed to make a few messy fiddles we weren't that happy and they didn't have APC. So we finally moved to a VPS so we could have PHP 5.3 with mod_php and whatever other guff we needed.

However, the system was incredibly slow. Between 50% and 30% of the speed of our local development server (which wasn't anything flash). We tried a bunch of combinations of memcache and APC configurations and then tried a few different Symfony2 options but nothing made much difference. In the end it turned out to be the open_basedir option that is normally on with cPanel accounts. This disables fstat caching, and Symfony2 does a LOT of fstat calls. Turning off open_basedir solved the issue and reduced page generation times from about 1500ms to 600ms. Which may not be an option for everyone.

See https://bugs.php.net/bug.php?id=52312.

I spent a while trying to customise the FOSUserBundle reset form. It uses a repeated field for the password, which can't really be tweaked from Twig. I finally figured it out using a Twig base form template. It's a little bit crap.

{% block fos_user_resetting_widget %}
  {{ form_row(form.new.first, {'label':'Password'}) }}
  {{ form_row(form.new.second, {'label':'Confirm Password'}) }}
  {{ form_rest(form) }}
{% endblock %}

More info: Symfony2 Twig Form Theming

Symfony2 will automatically add validation to entity fields ensuring that values match the database type. For instance, If you try to set an alpha character on a DECIMAL column you will get "This value is not valid" along with other constraint violations. If you manually add a Type Constraint you'll end up with a largely duplicate assertion. However, if you want to set the message on the default constraint, you can't do it in the entity itself. You have to do it in the form class.

$builder->add('amount', 'money', array(
  'label' => 'Default Price', 
  'invalid_message' => 'Price must be a number'
));

I couldn't find that documented anywhere, but it works.

We're using Symfony2's class table inheritance and I was trying to work out how to select only some subclasses using Doctrine2. It turned out to be pretty easy.

SELECT e FROM MyCustomBundle:ParentEntity e WHERE e NOT INSTANCE OF MyCustomBundle:ExcludedChildEntity

In the discriminator map in the super class you refer to the full qualified namespace and class name (\My\CustomBundle\Entity\ExcludedChildEntity) but in the DQL it works with Symfony2's shorthand.

$builder = $repository->createQueryBuilder('entity')
                      ->where('entity NOT INSTANCE OF MyCustomBundle:ParentEntity');