Scott’s Technical Blog

I’ve had a ongoing problem with PHP crashing under Symfony and Doctrine in a number of environments. The crash is random and appears and disappears like acne on the face of 16-year-old boy. The best solution I’ve found is upgrading to PHP 5.3. It seems to be faster and more stable for complex OO designs than any of the 5.2 variants.

Compiling and installing PHP 5.3 on unix had it’s own set of challenges, but it was, by and large, straightforward. Once you’ve got the configuration right, it seems to compile without any major headaches.

Getting PHP 5.3 to work under windows in another story altogether. I’d given up on XAMPP and switched to WAMPSERVER with PHP 5.2.8. It installs fairly cleanly and has a nicer interface than XAMPP. However, when I went to install PHP 5.3.0RC1 under WAMPSERVER, the walls of Jerico came tumbling down. What a nightmare. My partner burned a day trying to get it work and I burned another. No love. It simply crashed Apache on startup.

There are a bazillion Wamp installations out there (see http://en.wikipedia.org/wiki/Comparison_of_WAMPs). Looking through the list, I found one called PAMPA that already has 5.3.0RC1 installed. Glory be!

Doing an initial install of PAMPA is amazingly easy. You simply unzip it and run the EXE. All of the directories are relative and it fires up like a champ. The problem is that PAMPA is designed primarily for CD/DVD installations so it shuts off anything that might conflict and runs on odd ports.

To get it to behave like a more standard installation, follow the instructions below.

Change the following in the pampa.ini file:

1. Enable InnoDB if you plan to use it.
2. Change the Listen=85 to Listen=80.
3. Change the port=3307 to port=3306

Change this stuff in php.ini:

1. Find mysqli.default_port = 3307 and change it to 3306 (the mysql port again)
2. Uncomment extension=php_pdo_mysql.dll if you are using PDO
3. DO NOT uncomment php_pdo.dll. PDO is build into 5.3.0. There is no external DLL.

Change this in my.ini:

1. Change 3307 to 3306 (yet again)

In the depth of PhpMyAdmin:

1. Find pampa\PAMPA\apache.32\htdocs\phpMyAdmin\libraries\config.default.php
2. Change 3307 to 3306 (yep, again. finding this one took me hours)

To create a virtual host do this:

1. Add a hosts file entry (e.g. 127.0.0.1  localhost.mywebsite)
2. Add the stuff below to the top of httpd.conf

NameVirtualHost *

<VirtualHost *>
Servername localhost
</VirtualHost>

<VirtualHost *>
<Directory “location/of/files/for/web”>
AllowOverride All
Options Indexes
Order deny,allow
</Directory>
ServerAdmin an@email.address
DocumentRoot “location/of/files/for/web”
ServerName localhost.mywebsite
ServerAlias localhost.mywebsite
ErrorLog logs/localhost.mywebsite.log
CustomLog logs/localhost.mywebsite common
AddType application/x-httpd-php .php
</VirtualHost>

If you have already run PAMPA and make the changes, stop it and then run the task manager and verify that mysql really stopped. Often, it’s still running and may cause a conflict when you start PAMPA again. Kill it with the task manager or reboot if its running.

Changes to configuration that don’t involve MySql you can initiate by simply clicking on the P icon in the system tray and hitting restart.

Note that PAMPA does NOT install a CLI version of PHP. You’ll have to install PHP yourself if you use it from the command line (like I do).

That should do it. The nice thing about PAMPA is that you can zip it up and upload it somewhere and someone else can use the configuration by simply unzipping it and running the pampa.exe file. It’s pretty cool.

I am using the Symfony framework for my second project major now and now consider myself proficient, if not an expert. The first project was for iChange.com and the guys on my team had enough experience that I leaned on them for the esoterica that is not included in the ‘book’. On my current project (LittleYell.com), I am working with a Symfony neophite and thus largely flying solo when it comes to figuring out the hard stuff.

For those of you in the PHP world that have never used a framework, it’s time to start. It’s not appropriate for very small projects, but as soon as you are developing a real site, it’s pointless to try to invent all of the programmatic patterns you’ll find already completed in an existing framework. By all means, check out CakePHP, Zend, CodeIgniter and all of the bazillion’s of others (http://www.phpframeworks.com/), but I recommend you use one of them rather than write yet another one of your own.

Symfony was an easy choice for my first project because I had two engineers working for me that were experienced with the framework. I talked to lots of folks (including friends at Yahoo) who were using it and did a little diligence and liked what I saw. Reading the documentation on the site was also a compelling factor in my choice. It is very well written with clear examples of how to use the framework’s elements.

When you get deeper into Symfony, you’ll find that while the ‘book’ is very clear, you’ll find it very difficult as soon as the problem you are trying to solve is not included there. The API documentation is very hard to navigate and search and very thin. Most of the time, when I’m solving a hard problem, I start by searching the web for examples, and then start looking through the Symfony code itself looking for an answer.

I would describe the Symfony code as very well written and pretty poorly documented. Had my partner Jeff and I written it, there would have been less reliance on option arrays and better leveraging of the PHP class architecture. Too many functions and classes rely on magic methods that obfuscate the underlying processes. I described it once as looking at PHP assembly language.

You can get a simple web site going with Symfony pretty quickly, but don’t expect to write a full featured, high production, website without going through the steep learning curve. Symfony is trying to solve a lot of disparate problems and thus, it is very complex.

The first project (at iChange.com) was done using Propel which was the only stable choice for a Symfony ORM at the time. Propel works great, but it has two flaws. The first is that it is VERY difficult to subclass the classes in the model. If you have a ‘user’ table with a ‘User’ class in the model and want to create a UserGuest subclass, you’ll have to go through a lot of gyrations to make it happen. The separation of Propel’s data and factory classes is at the heart of this problem.

The second problem with Propel is that complex queries are VERY hard to write. A query that takes a few minutes to test in PHPMyAdmin make take hours to code using Propel. When you get it done, it will be hard to read and understand as well.

Doctrine, which we are using on our LittleYell.com project, mostly solves these problems. You can specify subclasses of model classes when making queries and Doctrine will happily hydrate into your subclass. The DQL syntax at the heart of Doctrine is fairly easy to read and creating fairly complex queries is certainly easier than in Propel.

Doctrine is still somewhere between the leading edge and the bleeding edge as far as stability, but I’m guessing that over the next year it will be the superior ORM. I’ve had some scary problems hydrating into objects using complex queries that have crashed PHP and Apache. Doctrine really wants you to hydrate into arrays which is efficient, but not very good OO practice. I solved the problem by creating my own lightweight container objects to hold data.

I still have one query that is crashing PHP that gives me some concern. I’ve worked around it, but I’m full of anxiety waiting for it to occur somewhere else where just the right conditions for the bug to appear. I’ve done some searches on Symfony Doctrine crashes and found enough posts to make me think I’m not the only one having this problem.

An interesting note is that PHP programmers like to believe that any crash of the PHP system is the fault of the xAMP stack. Not so. It’s fairly easy to write a PHP program to crash PHP.EXE (try function x() { x(); }, for example). If you have two software programs and one crashes PHP and the other does not, folks will use the one that doesn’t.

We aren’t far enough along for me to say whether Doctrine or Propel is the better choice. We are betting on the future and better structure and picked Doctrine. You might pick differently.

In conclusion, if you are doing a PHP project that will occupy you for a few months rather than a few days, use a framework. Despite the flaws mentioned above, I like Symfony and am glad I chose to use it. Over the next few days, I’ll try to post some solutions to some of the thornier problems I’ve faced.