Upgrading to Symfony 1.1 and Propel 1.3

As stated in the Introduction, bits of the tutorial that are now out-of-date have been greyed out and superceded by what's written here.

Install in test environment

Symfony 1.1

This is straightforward: simply follow the instructions in the Symfony documentation. There are 2 basic steps:

installation: I installed using PEAR, though a disadvantage of this is that PEAR leaves an awful lot of work files hanging around in /tmp and elsewhere, which have to be deleted later. With 1.1, $sf_symfony_data_dir (/usr/lib/php/data/symfony/) is no longer used; the upgrade process deletes most of the files, but some directories still have to be deleted.
upgrading the project: I suppose you could do this manually, but it's much simpler to just follow the instructions and use the script Symfony provides, symfony project:upgrade1.1. The only change that affected me was the moving of the default routing definitions

Then you just have to call up a page or two to check it all still works. One change not mentioned in the instructions is that the new way of handling Forms means that the Form helper is no longer included by default; if you want to use it, you have to add: <?php use_helper('Form') ?>

Propel 1.3

This is also relatively straightforward, but there's a bit more to it:

install Propel 1.3 plugin. Simply follow the instructions, this time in the Cookbook. Note that add-on plugins are installed in plugins/ in your app, not in the Symfony-supplied /usr/lib/php/symfony/plugins/, so if you have more than one app, you will have to install the plugins for each one. In the case of Propel, 1.2 is still in /usr/lib/php/symfony/plugins/ but is overridden by 1.3; in the next version of Symfony, 1.3 will be included instead of 1.2.
in config/databases.yml, the syntax for Sqlite files is now:
```
      dsn: sqlite:/path/to/file
```
config/propel.ini is similar
there were a number of issues when it came to rebuilding the model for each database:
- in one of my flights tables, there is a column called 'y' (and one called 'x'); for some reason, when creating the schema.xml, symfony propel:build-model changed this to '0', so I had to edit the generated schema, and rerun from that
- in the ballads database, with 2 tables for the titles and the verses, I had foreign keys for the column 'nv' in both. This worked fine in 1.2, but 1.3 seems to interpret this as a 1:1 relationship, and it doesn't allow foreign keys going both ways. I kept it in the children table, but had to remove it from titles. This means that ChildrenPeer::doSelectJoinTitles() is created but TitlesPeer::doSelectJoinChildren() isn't. This in turn means that the text search action criteria now has to include a join:
```
    else {
      $c->addJoin(TitlesPeer::NV, ChildrenPeer::NV);
      $c->add(ChildrenPeer::WORDS, '%'.$this->getRequestParameter('term').'%', Criteria::LIKE);
      $this->titles = TitlesPeer::doSelect($c);
    }
```

the direct calls to Creole methods have to be changed to PDO methods:

ballads' preExecute() function now reads:

  public function preExecute()
  {
    $connection = Propel::getConnection('ballads');
    $stmt = $connection->prepare("set names utf8");
    $stmt->execute();
  }

and the JSON actions in flights all have to be changed too. For example, executeFerries2json() now reads:

  public function executeFerries2json()
  {
    $from = $this->getRequestParameter('from');
    $con = Propel::getConnection('flights');
    $stmt = $con->prepare("SELECT toport as port, latitude, longitude, ferries.co as co, ferrycos.name as coname, web, comments FROM ferries, ports, ferrycos WHERE toport = ports.name and ferries.co = ferrycos.co and fromport = ? union SELECT fromport as port, latitude, longitude, ferries.co as co, ferrycos.name as coname, web, comments FROM ferries, ports, ferrycos WHERE fromport = ports.name and ferries.co = ferrycos.co and toport = ? ORDER BY port, coname ASC");
    $stmt->bindValue(1, $from);
    $stmt->bindValue(2, $from);
    $stmt->execute();
    while($row = $stmt->fetch()) {
       $rows[] = $row;
    }
    $this->getResponse()->setContent("loadFerries(".json_encode($rows).")");
    return sfView::NONE;
  }

Deployment

Having made all these changes and tested everything out, now it has to be deployed on the actual website. Again, there are 2 different things to install: Symfony itself, and the application together with the new Sqlite3 database files. As supplied, Symfony is some 9MB in size, of which more than half is Propel (1.2). As we no longer use that, there's no point installing it on the live site.

Symfony is well structured, and we can upload both it and our changed app without problem to a different directory name, and then just change the configuration file to point to this instead of the old one. Specifically, the main controller index.php has to be changed, as does config/ProjectConfiguration.class.php. So, we copy Symfony to, for example, newsymf, and the app to, for example, newapp. We then change newapp/config/ProjectConfiguration.class.php to load sfCoreAutoload from newsymf. We then create a new index.php which uses newapp/config/ProjectConfiguration.class.php. If other configuration files, such as databases.yml, use absolute rather than relative addresses, they will have to be changed too. Then, when everything is uploaded and ready to go, we simply swap out the existing index.php and upload the new index.php, and it should all work. If it doesn't, well, just swap back the old index.php so users can access the old system while you sort out the problem.

Peter Robins, his website