Update for Sunday, July 15, 2007

I’ve been slacking off a lot on writing entires to this thing, so I think I’m going to start picking it up a bit and spending about a half hour at the end of each day writing down what I did during the day. I hope this provides a little insight into what’s going on in Web Services on a day-to-day basis. I fully encourage comments from anyone on how we could be doing these things better or what else you’d like to hear about.

PHP Upgrade to Production

Today marked the first upgrade of PHP in production that we’ve done in a really long time. This one was upgrading PHP 5.1.2 to PHP 5.2.3. There’s really nothing spectacular about this upgrade, except for a pile of security updates. We’re going to be doing many more regular upgrades of PHP than in the past. This updates is a little out of synch of this new philosophy, but we’ll be upgrading to the next-more-recent point version of PHP in the future. Currently PHP 5.2.3 is the most recent version.

This means that if PHP 5.2.4 is released tomorrow, we’ll be waiting until the release of PHP 5.2.5 to upgrade to PHP 5.2.4. If PHP 5.3.0 is released tomorrow, we’ll be waiting until the release of PHP 5.3.1 to upgrade to 5.3.0. The official releases of PHP are typically fully stable by the time the next point release is announced. We want to maintain a balance between keeping the version of PHP current for security purposes with maintaining application stability. We also test the code in development for a week prior to the upgrade to production.

Other than security fixes, PHP 5.2.3 (and the 5.2 branch in general) contains an improved version of the date and time objects, which are now built into the core of the language where they used to require a separate PEAR module. The JSON functionality, used to serialize objects for use in JavaScript, is also built into the language core now. The final big update is really only exciting for hardcore PHP geeks, but the default behavior for an object being printed or echoed is now to call it’s built-in __toString() function.

This last update means that we can do this:


$addrlist = new AddressList();

$addrlist->add(“Ian McBride”, “imcbride@middlebury.edu”);

print $addrlist;


Instead of this:


$addrlist = new AddressList();

$addrlist->add(“Ian McBride”, “imcbride@middlebury.edu”);

print $addrlist->__toString();


I’m sure you can see where saving those 13 keystrokes is well worth this massive change to application behavior. Quick note: if the first code block were executed in PHP versions prior to 5.2 the interpreter would print out the Object ID of the AddressList object rather than the return value of the __toString() function.

PHP 4 End of Life

It was recently announced on http://www.php.net that PHP 4 will end its life at the end of this year, meaning that security updates will no longer be issued for the product. For those who don’t know, PHP 4 is the version of PHP currently used on CAT for stuff like the Online Box Office, College Store, and Events Calendar as well as several pro bono hosted sites. While we certainly don’t have the most recent version of PHP 4 installed on CAT, so security updates are something of a moot point anyhow, this should still concern us as it highlights once again our need to remove ourselves from that environment.

Because of the instability of CAT on a weekly basis, the Events Calendar is already targeted for migration to FUSION and PHP 5 as soon as I can get to it. The other applications on this server that we’re responsible for mostly include Business Services applications that may change in nature when the new Point of Sale system is acquired for that functional area. There are also a whole host of web forms on the server that Travis is in the process of migrating to the XML Forms framework on FUSION. If all goes well, we should have major services off CAT by the end of the year, at which point the abandonment of PHP 4 will not concern us.

The impending release of PHP 6 on the other hand….

SharePoint versus MCMS

I answered two CMS related support tickets today as well. The first was a Faculty member who is also an Editor (can make and approve their own changes) to a department site on the CMS. They were asking why a student worker couldn’t add images to the site’s Resource Gallery.

Due to auditing requirements, students working on the CMS are all Authors (can make changes, but not approve them), except for a very small group directly supervised by Tim Etchells. This is to keep students from being able to directly affect the production web site. Unfortunately, while MCMS lets us have Authors able to edit but not approve content, if we give that same person the ability to add multimedia items to the Resource Gallery we have to also give them access to delete multimedia items. This opens the exact issue we’re trying to avoid by making the student an Author: they can now adverseley affect the production site.

Once we’re able to move the CMS content into SharePoint, we will no longer have this issue because the permissions structure of SharePoint is much more granular. Not only can we set permissions at the document level, rather than the container level, but we can set exactly what actions are enabled for a group of users, so we can let students drop their content into the Resource Gallery, but prevent them from deleting any content. SharePoint also provides a multi-stage deletion control system that gives Editor-level users access to a Recycle Bin from which they can restore items without contacting Site Administrators. The Site Admins can set how long items remain in this Recycle Bin after which they’re dumped into another Recycle Bin at the Admin level and then eventually purged.

Fun Note: MCMS never purges data. At all. Once the item is deleted by the admin it’s added to a special place in the database referred to as the “Archive Folder”. There’s no way to get at this data through the API, meaning that you have to violate the MCMS license to delete the data permanently. Consequently, our MCMS database has continued to grow exponentially since implementation.

The ability to set document-level permissions in SharePoint will also help us out with the next support request I closed today. Faculty profiles can be spread accross multiple departments if they teach courses in many disciplines. In order for a Faculty member to add multimedia content to a profile, they have to place this content is a bin where all of the Academic Coordinators have full permissions. With SharePoint, we can just set document level permissions on the posting and related documents and let the Academic Coordinators responsible for the content deal with it.

SharePoint Team Sites

On a less positive SharePoint front, I discovered two problems with the SharePoint Team Site today. First, the custom search box that I had implemented as part of the new design last week doesn’t work correctly. It shows no results for any search, even though search is working correctly. I’ve switched back to the default search box for now until this problem is corrected.

The second issue I discovered is that there is only one RSS feed for each list. This means that you can’t have different feeds for different views in the list. This was brought up because Mike wanted to have a feed for just Banner updates delivered through the Change Log. To do this with the SharePoint list, however, you need to apply filtering on the client end. Coincidently, there was a blog post about this very issue from one of the SharePoint developers today. They recommend using a CQWP to display the custom feed, but that requires writing custom XSLT for your feed unless you want the default view, which is just the title of the item. Interestingly, if you want to get email alerts from a list, you can do that on a per-view basis, so that might be a solution for people not wedded to RSS.

Fall Family Weekend Registration Form

Now that this form has been ported to FUSION, all of the alumni forms have been moved off of CAT. This should help us retire those forms. Heather Cahill had asked us to do so as many of the forms are still linked to through Google and they’ve had a series of registration’s come in for events that were offered years ago. The new XML Forms Framework is much better at handling the on/off nature of these forms.

I’d still like to investigate a better way of handling these items. This was originally part of the Alumni Online Community but was pushed back to the old web forms model because our payment gateway is difficult to integrate with. Each of these takes me 1-2 hours to fully implement correctly and their presence sometimes interferes with features of critical forms like the Giving form. We really need to find a self-service model for this area.

Online Box Office Yearly Maintenance

I discovered today that there’s yet another flaw in the Online Box Office user interface. Debbie Anderson asked for the events from last year to be removed from the database. After asking Chris how we did this in the past, I dumped the database to a backup file and then tried to use the “Delete this Event” option in the admin interface. This dumps you on the image upload page with a bad request and doesn’t remove the event. Now I see why Debbie was asking me to do this.

A quick “delete from events” solved that problem, but with yet another wart on the face of the Online Box Office application. This is one of Tyler’s old development projects. To be fair to him, it has run fairly well considering the business logic it has to bend to. “We’re setting aside this many tickets for online use and this many for in-store use, but adding them together will get you more tickets than we actually have, so we have to limit the number provided to…”, etc. I’ll reiterate my desire that this application reside within the College Book Store, or whatever we brand the combined online Business presence for the College, and tickets be sold just like any other item through that system.

Athletics Recruiting

I’m continuing work on the schema for this questionnaire. Hopefully, when we’ve fully tied each of the questions we want to ask to a field in Banner we’ll all be on common ground when thinking about the implementation of this project. I don’t have a whole lot to say about this right now, but check back for more updates this week as I’ll be working closely with Heidi to square away some of the weirder questions.

One interesting point came up in that we want to tie a recruit’s coach to the High School for which they coach. Coaches are stored in the relations table (SYRRFRL) with siblings and parents. Siblings and parents have college’s associated with them in this table in some columns I proposed named SYRRFRL_SBGI_CODE and SYRRFRL_SBGI_DESC which store the six digit identification number and 30 character school name of the college.

High schools also have SBGI codes! Now, should we shove the coach’s high school code in there and force the application to understand the context of the data in the column? That seems like really bad practice, but the alternative is having separate columns for high schools and colleges and then we get into the case where the coach’s high school isn’t the high school they attended, it’s the high school they work for. Meanwhile the parents and siblings SBGI codes refer to intsitutions which they attended. And what do we do about transfer students?

This project is particularly tricky because of the sheer volume of questions we’re asking of the user. I’m up to thirteen pages of questions and haven’t even got to the sports-specific, athletics-related, extracurriculars, or test score questions yet!

Leave a Reply

Your email address will not be published. Required fields are marked *