We took a break after day one of the Codeworks DC conference and went to the Brickskellar. The Brickskellar is a famous institution of beer in Washington DC, noted in the Guinness Book of World Records as been the place selling the greatest number of different beers of any drinking establishment on the planet earth. We met up with the group going there in the hotel lobby. We had originally scouted out the fine dining in Alexandria, of which there is plenty. We were thinking of Overwood, 219, The Flying Fish, or others, but on a whim we decided rather to join the conference folks down at The Brickskellar. We got the address from the hotel, entered it in the TomTom, and made it there before the main group did.

We had thousands of possible beers to choose from, but we were most attracted to the pumpkin beers from local microbreweries from the taps. We enjoyed a down home meal of mussels, beef, and a crab cake sandwich and fries. A few things to point out in the pics above: Not the skull foam in the beer glass, the chocolate cake, the double chocolate stout, the elephant tap, the cans in the wall, some familiar faces from the php community, and the trappist ale. So never mind the fine dining in DC, go for the soul food and beer.

I am back recently from Codeworks 2009 in Washington, DC. It was in Alexandria, Virginia actually, but close enough, its a big place and its the same thing. This is the first time I have been able to go to a conference  without being involved at all in its planning and organization. I know from experience that a lot of work is put into organizing and hosting a two day event with top-level speakers from all over. The DC Codeworks event was just one event in a series of dates in major cities across the us. Yep, php has gone rockstar. I am proud of the work I have done in the past but I found that by the time the conference came around I was too tired to absorb the lessons as I would like to. So while I am busy recompiling notes from the talks I attended, here are some photos from the conference I would like to share.

The conference was great, I learned stuff, I learned what I know, what I dont know, what I need to know, and more. I met a great group of people and traded lots of business cards.

Drupal Community Support Is Now Upside Down

Drupal creator Dries Buytaert has made some copryright changes that are now pissing off the web community. The new trademark policy, indroduced at the end of August 2009, now forbids the registration of domains like drupalSucks.com, and any site using Drupal in the name now must fork over $$$$$. WTF? Its a baffling move from such a well known member of the community, who has prospered from the concept of free software, sharing and free expression.

…it is a pretty impressive piece of software. But people should be free to criticize it in any way they see fit, including the registration of domain names that are less than flattering. (source).

Unfortunately, these greedy assertions in a community that functions because of the freedom of expression, sharing and openness usually only serve to anger people so much as to go out and register domains like drupalSucks.com which they use to spread the word about what a stupid idea this is.

Fallout is starting already. Free Drupal Hosting which, like the name sounds, provides free hosting for drupal sites, may not be willing to do so in the future.

There are draconian restrictions on the use of the word ‘drupal’, which would require us to give up a good part of our income, the truth is that the income from the ads is so low that we barely make enough to pay for hosting and bandwidth. We would not mind that but we refuse to make a loss on this service because of a silly trademark, with restrictions that – if they weren’t so sad – border on the hilarious. (source).

Creating a domain name that uses a preexisting name in the case of drupalSucks.org is covered under ‘Nominative Use‘, as an affirmative defense to trademark infringement. The Drupal community will be set to scream long and loud over this. And companies who market their services using Drupal, making sites with Drupal, and companies that write code in the Drupal framework are bound to think twice about whether they want to use it due to these new restrictions.

A variable can be a variable, did you know? Its something you may have learned in introductory PHP, like on p.32 of my copy of the Zend PHP Certification Study Guide. But while knowing data types is part of the job, its not always how you should code!

Here is an example of something I saw recently. Names have been changed to protect the innocent.

<?php
foreach ($fieldName as $field=>$type) {
$UserObject->setValueInDB($field, $$field);
}
?>

This is from a form submission script. There are a couple of transgressions I can think of, not least of all the reliance on the register_globals directive which is now off by default, and soon to be eliminated from a future release of PHP.

The variable variable part here is $$field, basically, what has been posted. The $fieldName value is a list of fields grabbed from the table, so you don’t trust $_POST. But what is the point in trusting the scalar equivalent of your posted value? You are getting farther away from certainty, not closer. A $_POST submission from an attacker could wipe out data because their $_POST array doesn’t have any keys that your table has. As well, if your $_POST array on your own page doesn’t have a $key=>$value that is also in $field=>type, well that value is going to get wiped out. In the case of a user profile edit page, a form page probably wont have all the fields that are posted. Especially if a developer doesn’t consider using table joins elsewhere.

One of the cardinal rules of programming is never trust user input. And I consider losing user data to be a deadly sin. But setting up a situation where you risk losing data in a field because of one additional field in the table for the user is downright dangerous.

One of the early-ish contributors to PHP, by virtue of being a C programmer, was no doubt familiar with the variable variable language construct, and appreciated its eloquence in CRUD scripts and elsewhere. You got your field names, so cycle through them in a looping construct and execute your value setting method.  He or she is forgiven for not realizing that eventually, with the blossoming of a thousand new web hosts and thousands more developers on the web, not only users had to be protected from themselves, but developers from themselves also. And so, as of release 4.2.0, register_globals was finally set to OFF by default. Many hosting companies have been slow to react, and even today set it to ON to support legacy software.

So while you have this spartan and eloquent structure, it relies on an obtuse language construct which in turn relies on data that is potentially not trustable. The solution to the above problem required a static array of field names that must not be overwritten. Of course, testing this once might reveal that data is being overwritten with empty values. Unintentionally. By design. Due to a deprecated directive and an obscure language construct.

Here is one of the little improvements upon a php script that makes it even more useful – at least appropriate for browser output. I make no claim to having invented this, its just a useful little script to pass on for debugging arrays in PHP.

function printR($arr, $label= null) {
if($label){
echo “<h2>$label</h2> \n “;
}
echo “\n\n<pre>\n”;
print_r($arr);
echo “\n</pre>\n\n”;
}