A couple of days ago, I wanted a barbecue.  Having lived for three years in an apartment in Arizona, I have been completely unable to own a barbecue, under penalty of flogging by the Fire Marshal.  Now, having moved to Florida to an apartment that allows them, I wanted a barbecue.

So, I went to get one.

Walmart was the destination of choice.  The barbecue I found and wanted was the Char-Broil 2-burner.  Walmart had exactly one.  It was the floor display model, but I still wanted it.

So, I grabbed the barbecue, and wheeled it over to the checkout counter near the gardening section.  I was politely informed that the barbecue, being the floor model, would need to be approved for sale by the manager.  The checker called to ask, and another associate (image simulated) to check out the grill.  The grill, I was informed, was in perfect working order.  I was also informed, at about the same time, that the manager would not approve the grill to be sold.  The associates put the grill back on the display floor.

Then I took it.

No, I didn’t steal it.  I just waited for them to be busy with other customers, walked up to it, and wheeled it away.  This time, I headed in the direction of the front of the store, and the main checkout area.  Specifically, I angled toward self-checkout.

The grill had a big sticker on it, complete with barcode.  I peeled it off as I went, got to the self-check, scanned the code, and swiped my card.  It was mine.

Pause.

“Hold for Assistance”, the screen read.  The associate monitoring the self-check started walking my way… and all she wanted was to verify my ID against the name on my card, because the grill was a large line-item on the receipt.

And the grill was mine.

Walmart, your rules do not apply to those people willing to use your own systems against you.  I’m not talking about laws.  Just your rules.  Enjoy.

July 7th, 2008 by Mack Staples | No Comments »

This is a much condensed version of the original post.

Usually, processing form data means getting either POST or GET data from a form, and trying to figure out, in code, what you have, and then do something with it.  This can be easy or complicated, depending on how much is being passed in.  Email address only? Easy.  Checkboxes, optional fields, and so on, all together?  Pain.  Often, a lot of form processing is done with stacks of “if” statements.  This sucks.  Here is a better way:

From now on, I want you to name all of your “real” form elements (ones that have data that could change, so not buttons) using the name you would have given then, plus an array name, that they will all share.

So,

<input type="text" name="username" id="username" />

becomes

<input type="text" name="formdata[username]" id="username" />

Why?  Instead of having one array ($_POST), you’ll now have two ($_POST and ‘formdata’, within $_POST).  Your buttons and other “static” form elements will still live in $_POST, but everything containing data that needs handling will be in the ‘formdata’ array, which you can access as $_POST[formdata].

Why does this rock?  I find I have to go through all of the data in a form, even if I know what and how much is coming in, and that the amount wont change.  For example, it’s a good idea to clean all user input.  Since users can change any form value, this needs handled.  Why bother with a ton of ‘if’ statements when we can just iterate through the ‘formdata’ array?

  foreach ($_POST['formdata'] as $key => $value)
    $_POST['formdata'][$key] = makesafe($value);

Cautionary note: this definitely seems ideal for updating data in a database and saving time, doesn’t it?  Maybe something like (let’s assume “$user_id” is the current user’s account, and we determined that earlier somehow) :

  foreach ($_POST['formdata'] as $key => $value)
    mysql_query("UPDATE info_table SET $key = '$value' WHERE index = $user_id");

This is a bad thing.  Why?  SQL injection.  At the very least, clean all input, including the field names, if you think something like the above statement is a good idea.  If you don’t, don’t say I didn’t warn you if you get owned.

June 16th, 2008 by Mack Staples | No Comments »

During the Spring Semester of 2007, I worked as the lead developer on the UAT Rogue Forums.  The project was designed and lead by Jordan Womack, a UAT Master’s Student.  Under him, the Rogue Forums was created as an alternative to UAT’s intranet forums; general opinion of the intranet forums was quite low.

We used and modified phpBB.  My portion of the project was to re-skin the bulletin board system, act as lead moderator, prevent non-UAT students from registering, and implement the post voting system.  phpBB version 3, RC5 was used and updated to subsequent release candidates.

Two php files were added to the core of phpBB3, one core file was modified, and additional tables were created in the database.  Currently this project only works with phpBB3 on a MySQL database, but I hope to make it database-independent.  Below is a snippet of code from the new files.

<?php
	$sql = 'INSERT INTO ' . VOTES_TABLE . ' ' . $db->sql_build_array('INSERT', array(
		'post_id'		=> (int) $post_id,
		'user_id'		=> $user->data['user_id'],
		'adjust'		=> 1,
		'vote_time'		=> time(),
		'voter_ip'		=> $user->ip)
	);
?>

A working example of these modifications in a live phpBB3 environment can be seen at The Rogue Forums.  Please contact me for a login, as account creation is limited to UAT students only.  The new files associated with this project are linked below.

pbpBB voting system files

May 23rd, 2008 by Mack Staples | No Comments »