What a day! This one involved a busy morning followed by a productive afternoon. There was also a scheduled update of production today and, as you will see, an unscheduled update of production.

Fall Out from the PHP Upgrade

Yesterday I updated PHP in production after a couple weeks of testing. This included an update to almost all of our PEAR modules. PEAR is an extension repository for PHP that includes a lot of third party scripts that make working with PHP easier. We use PEAR_ldap to make the Directory work and PEAR_DB_DataObject as a database abstraction layer for forms and TouchNet-connected forms.

It was that last PEAR module that really caused problems. Because PHP had been updated so infrequently, we jumped a number of versions of this module and I hadn’t reviewed all of the change notes for all of the different versions. A significant update was made to this package that didn’t show up on the development server, but manifested itself in production.

Each database connection through DB_DataObject is generated by parsing a set of schema files that let the script know what the tables and columns are named and what data type each column is. One of the config files, known as the “link” file can be set up to make joins easier. We never use this because it’s a real pain to write out a custom config file any time you want to add a join. Much easier to just write out the SQL in the query when passing it to the database. Most of the MySQL scripts don’t even use joins. The XML Forms and TouchNet Forms all have only a single table, so joins aren’t necessary for their functionality.

So we never updated the “links” files in production.

And now they’re required.

This caused the production scripts to bomb out with a non-descript error message. The error could not be reproduced in development and the only way to print out the error message in production would have been to start printing the error message, which includes the connection string (i.e. the database username and password). We were told by at least one office that one of their forms was getting hammered, so this wasn’t an option.

After Googling around a bit, I finally landed on a forum post that had to be translated from German that told me what was happening in broken English. I uploaded the file and all was well. Then other forms started breaking, so I uploaded the “links” files for all of the MySQL databases. Now I have to remember to do this whenever the table schema changes for any of the MySQL databases, which happens very frequently for the Forms and TouchNet forms databases.

All in all, this has strengthened my opinion that we just need to move away from using PEAR packages. The PEAR_ldap package in particular is cumbersome and horrendously buggy. The PaGES project is moving away from including anything of the cacophony project, including files that rely on PEAR packages. Hopefully by the time I’m ready to deploy the next version of the Directory, these problems will be a thing of the past.

Athletics Recruiting

I’m nearly done figuring out where all of the information goes, but I need to do a better job of putting it in the correct order. For example, I figured out how to enter information for coaches before I figured out how to enter information for a general high school sport, but the coach questions have to come after the general sports questions.

There are also a lot of these questions which can have multiple answers, such as those regarding siblings, coaches, sports, summer clubs, etc. For these I’ll need to create a mechanism where the student can select to add a new record or go on to the next question. For example, let’s say they have two siblings: a brother and a sister.

1. Select “New Sibling”
2. Select “Brother”
3. Fill in information for brother (name, contact, school)
4. Select “New Sibling”
5. Select “Sister”
6. Fill in information for sister (name, contact, school)
7. Select “No more Siblings”

The process needs to allow the student to repeat it as many times as necessary for the number of siblings they have (or want) to enter into the form, but must also allow the student to move onto the next question at any time. This is very important when we get into multiple stage question groups. For example, for each sport the student is going to have to enter general information, coach information, and statistical information.

This is yet another kind of custom form functionality that I’ll need to develop for the Athletics questionnaire. I don’t think even KeySurvey, which we recently purchased, is able to do repeating branching logic like this. The challenge is to make it transparent to the end user while also coding it in a way that doesn’t break under the strain of added complexity.

Scheduled Production Upgrade
Noting very exciting on this point today. The Fall Family Weekend form mentioned in yesterday’s post was uploaded along with a push of the MCMS project to correct a spelling mistake on one of the error pages.