Frameworks are great because other programmers can walk into the project and see exactly what the status of things is and how it should all work… and then start contributing almost immediately.

Frameworks can be bad when it takes a degree in computer science to figure out how to manipulate the thing into doing what you want because the behaviour you’re looking for was extended five layers back from some obscure object in a subdirrectory. PHP doesn’t have the IDE tools to handle that like Java and .Net do.

• Symfony – Learning curve like a backwards ski jump. Crippled by poor integration with two bad MVC systems — Propel’s crufty and backasswards and needs to drop down to Creole for m2m relationships… and don’t get me started on Criterions. Doctrine’s just incomplete and the integration isn’t going as well as planned because of the extensive refactoring. Requires too much code generation. Takes mucking around in configuration files for a month before you lay down any PHP code.
• Zend Framework – One step better, but it’s so disjointed until you get to the Zend_Controller interface. You essentially need to extend the core libraries and load your versions instead of the core. Each piece is nice by itself, but I wouldn’t call the current release 1.0 because it’s still disjointed. On top of that, you can’t do multi-layer templates without integrating a separate template system like Smarty or re-writing the View sytem. There’s proposals in the works for it, but come on — this is a basic templating feature, and you took us back to the bad old days of “require header.php; echo $content; require footer.php;”? I’d expect something a little more modern out of Zend.
• Cake – Still supports PHP4, so it’s OO is backwards.
• CodeIgniter – See Cake.

I want a framework that handles the configuration for me — it sets up a file structure with basic naming conventions, it provides decent templating functionality, it looks in the databases to find a model (and doesn’t have stupid one-database-per-app requirements) and inherits from that, and it provides configuration functionality that makes sense instead of endless arcane ini, yml and xml files.

Symfony almost gets it right, but it’s too complex and setting up a model and generating the code is a pain in the arse. Zend almost gets it right, but you still spend a week extending functionality and configuring things before you can build your application.

I just want to get in and start coding, and have the framework handle the rest for me instead of configuring, coddling, debugging and tweaking the framework… and then someday getting around to coding.

And while I’m dreaming, I’d like a pony.

Authentication and security are important for any application greater than a mere toy. It’s much better practice to implement something that’s standardized and depend on the security of lots of eyes and a decent user-base as opposed to depending on the obscurity of your own code to secure your app. I highly recommend using sfGuard.

First, the usual installation steps — in your project root directory, use

$ symfony plugin-install http://plugins.symfony-project.com/sfGuardPlugin
$     symfony propel-build-all
$     symfony propel-load-data (application name)

The last one is actually important, even if you don’t already have fixtures — you need to load the admin user so that you can log into your application and access these new features that you’re automagically adding. More below the jump.

In $app/config/settings.yml, you’re going to want to configure the proper plugin modules. For your frontend, you’re going to want to configure the Auth module and the RememberMe filter.

$frontend_app/config/settings.yml:

all:
  .settings:
    enabled_modules: [default, sfGuardAuth]

$frontend_app/config/filters.yml:

security: ~
  class: sfGuardBasicSecurityFilter

Now, we’re going to implement the same for the backend, but adding in the administration modules. I added the sfGuardAuth to the backend; the main tutorial intends for you to use the frontend module’s authentication process to authenticate to the backend, but this never made sense to me. In the application I’m working on, I actually have three applications that are all administered at different levels; the frontend is for users, the mid level one is for day to day administration, and there’s a backend for setup and administering very base details of the application itself. Since most people aren’t quite as crazy as I am, I’m just doing frontend and backend for the example.

$backend_app/config/settings.yml:

all:
  .settings:
    enabled_modules: [default, sfGuardAuth, sfGuardUser, sfGuardGroup, sfGuardPermission]

$backend_app/config/filters.yml:

security: ~
  class: sfGuardBasicSecurityFilter

Now let’s make the changes necessary to redirect users to the sfGuard pages instead of your login pages.

In $frontend_app/config/settings.yml:

.all:
  .actions:
    login_module:           sfGuardAuth
    login_action:           signin

    secure_module:          sfGuardAuth
    secure_action:          secure

We also need to change the parent class in myUser.class.php. There’s functionality that the User class needs to be able to talk to the database.

$frontend_app/lib/myUser.class.php:

class myUser extends sfGuardSecurityUser
{
}

Sometimes, I’ve seen the myUser.class.php change made for you by installing the plugin. Don’t depend on that. Also, the myUser change seems to be missing the closing ?> … bad plugin developers, no cookie. Ok, nevermind. All of them are. It’s on purpose. Bad blogger, no cookie.

sfGuard registers the following routes: sf_guard_signin, sf_guard_signout, sf_guard_password automatically unless you specifically tell it not to. If you don’t like the URLs it assigns by default, then set

Now, since I’m forgetful, I change the default for my pages to be secure… that’s in $app/config/security.yml, set is_secure: on… and then set things to be insecure in my module level files where desired. I suggest this route. Security is meant to be established by default.

Clear your cache, and you should be good to go. Unlike most Syfmony plugins, sfGuard’s wiki documentation is pretty good and goes into lots of detail on how to set defaults.

There’s CSS bugs in the admin panel. There’s problems with the editors — code only, becase the visual one doesn’t display. There’s problems with the javascript in the options screens. I had to crack open Firefox just to change the link format.

I know that WordPress doesn’t claim to support Safari, but fer chrissakes — it’s the third of the big3, and makes up about 5% of the traffic to my site. I’m glad that the themes I’m using at least support Safari.

Related: