How-To php WebApps

Symfony Has a Swift Plugin for Sending Gmail

It’s easy to send emails using your gmail account with the Swift Plugin.
Here’s some sample code below

$to          = '';

$htmlMessage = "OH HAI!";
$textMessage = "*OH HAI!*";

$connection = new Swift_Connection_SMTP(

$connection->setUsername(sfConfig::get('app_email_username')); # gmail email
$connection->setPassword(sfConfig::get('app_email_password')); # gmail password

$mailer = new Swift($connection);
$message = new Swift_Message("Your subject goes here. OH HAI!");
$message->attach(new Swift_Message_Part($htmlMessage, 'text/html'));
$message->attach(new Swift_Message_Part($textMessage, 'text/plain'));
// Send,
// try and catch
try {
  if (!$mailer->send($message, $to, sfConfig::get('app_email_username'))) {
    throw new Exception('mailer error');
} catch (Exception $e) {
      "Caught swift send error exception:\n" .  
      $e->getMessage(). " ".
      $e->getFile() . ": Line ".
      $e->getLine() . "\n", $e->getTraceAsString(), "\n"
How-To php WebApps

sfGuardPlugin: The Extra Documentation

Hey Folks,

The Symfony project has a section called sfGuardPlugin Extra Documentation.

It’s worth a read, especially the part about using the sfGuardUserProfile calls.

The docs haven’t been updated since March, so if something isn’t working, please refer to my previous blog post on installing the sfGuardPlugin.

I’d like to state that personally, there isn’t really the right way to do this. Sometimes you already have a table that has a username and password. You can skip using the sfGuardAuth password tables by doing the following:

    algorithm_callable: md5
    success_signin_url: @homepage
    profile_class: sfGuardUserProfile
    profile_field_name: account_id
    check_password_callable: [Account, checkPassword]

The important line here is check_password_callable, where you are telling symfony to use the Account table and to use your own checkPassword method.

How-To php WebApps

Installing sfGuardPlugin in symfony 1.1 — A Guide for the Perplexed

Like the verbally creative barfly, who is a dead ringer for a 21+ Juno, that you picked up during last call on a Friday night, symfony 1.1 starts to grow on you. Nevermind your friends, who found Erlang in some higher-scale, hipster, hippy hang out. They tell you it’s time to leave symfony 1.1. You’re perversely drawn to this framework and don’t mind racking up the future therapy bills.

God is dead, and so everything is permitted, unless you can install something like symfony 1.1’s sfGuardPlugin to add logins and login protection to web pages. Like the initiation rites into the Eleusinian mysteries or the Freemasons, not everything is articulated on how to do the install. But below, for the first time, it is.

Note: I use psymfony as an alias which really just means ‘php symfony’.

  • psymfony generate:app backend

Now you can start following the guide written on the symfony website. Below is just from my shell’s history log:

  • psymfony plugin:install sfGuardPlugin
  • psymfony propel:build-model
  • psymfony propel:build-sql
  • psymfony propel:insert-sql — this didn’t work for me so I ended up just doing: mysql -uusername -p < data/sql/plugins.sfGuardPlugin.lib.model.schema.sql
  • follow the instructions in the guide above for fixtures
  • psymfony propel:data-load frontend
  • psymfony propel:data-load backend
  • vim apps/frontend/config/settings.yml
  • vim apps/backend/config/settings.yml
  • psymfony cc

But you’re not done yet. Are you running into a propel connection error? Then you might have to edit some yaml files based on this blog post.

In my case, I ended up having to edit config/databases.yaml by adding the following below:

     class:          sfPropelDatabase
       phptype: mysql
       host: localhost
       database: dev_starster
       username: writes
       password: some_wicked_sick_password
       dsn:          mysql://writes@localhost/dev_starster
       datasource: propel

Are we out of the woods yet?

Unfortunately, symfony 1.1 has a signout bug, where sessions are not entirely cleared. Thanks to this blog post, I was able to hack something together.

In apps/yourapp/modules/sfGuardAuth/actions/actions.class.php write:

public function executeSignout()
if (sfConfig::get('sf_environment') != 'test')

You might have to link the sf_guard_user table to an account table, if you want the account table to do the authorization instead. If so edit apps/modulename/config/app.yml by adding something that looks like this:

    algorithm_callable: md5
    success_signin_url: @homepage
    profile_class: sfGuardUserProfile
    profile_field_name: account_id
    check_password_callable: [Account, checkPassword]

In the lib/model/Account.php you should add code that looks like this:

  public static function checkPassword($username, $password) {
  	$c = new Criteria();
  	$c->add(AccountPeer::EMAIL, $username);
  	$c->add(AccountPeer::PASSWORD, md5($password));
  	$rac = AccountPeer::doSelect($c);
  	//print_r($rac) ; die();
  	if ($rac == TRUE) {
  		return TRUE;
  	} else {
  		return FALSE;

Here is a list of links that made getting the plugin working possible:

php TechBiz WebApps

Does Core Developer Think Symfony 1.1 Alienates PHP Developers?

Have you ever coded in a framework and then woke up one day to find that all your code broke when you upgraded? That’s exactly what happened when symfony 1.1 was released without backwards compatibility. A core symfony developer, François Zaninotto, shares his thoughts about the non-launch of symfony 1.1.

A couple key phrases, that he uses to describe the symfony core developers attitude to us mortals, are pretty disturbing:

  • If you just used symfony for one project, and left if afterwards because it lacked some feature that you needed, then you don’t deserve to be informed that this new release does have this feature.
  • Symfony 1.1 is so good, that it should not be left in everybody’s hands. Think of it as a forbidden manuscript of the middle ages, that only a few copyists ever read and got a fair picture of.
  • …there is no “First Project tutorial” at all for symfony 1.1.

Caveat: Do not use symfony 1.1 unless you want to pour through source code.

Problem: You’re working on symfony 1.1 and it doesn’t work as advertised.

Solution: You have to pad your estimates on symfony based projects by at least a hundredfold. A form that should have taken me no more than an hour at Dogster ended up taking 4 days! Read this blog for important symfony 1.1 updates.

So does François think that PHP developers are being alienated? It’s strongly suggested through his use of irony, and analogy of symfony to a medieval text, but does he say abandon symfony?

Not at all. Rather his frustration noted in a follow up blog post has to do with the fact that he cares a great deal about symfony. If you were thinking about leaving symfony, François is enough reason to stay.

How-To php WebApps

Symfony 1.1 Validation — Gotchas

1. sfValidatorAnd requires a patch to work with Propel.

Get the patch here.

Read the trac ticket for more details.

2. A huge difference between 1.0 and 1.1 in form validation deals with error handling.

1.0 puts the error handling right in the action. In 1.1 you use code in a lib/forms file that looks like this for validation / error handling and corresponds usually to the object being validated. In the example below the code is in lib/forms/AccountForm.class.php

    'username' => new sfValidatorString(array('max_length' => 30))

3. sfForm::setDefaults doesn’t work quite right with CSRF values.
you’ll need to patch up code based on this google groups post.

The documentation right now for 1.1 isn’t updated. E.G. The chapter on forms for the 1.1 documentation as of 12 August 2008 will lead you down the wrong path.

To keep up to date on what’s going on with symfony, I totally consider doing the following mandatory and not optional:

  • Join the google group, symfony-users
  • Join the irc channel in #symfony any time you’ve got a question that needs asking
  • Since the docs might be off, it’s best to just read the source.