1: A nonexistent PHP array key generates no error or warning. When trying to iterate over a nonexistent array key, a warning occurs. In other languages, both of these conditions throw an exception.

Try this code for example:

<?
$dictionary=array('one'=>'got one','two'=>'have two','four'=>'missing three?');
foreach (array_keys($dictionary) as $key)
{
	print "Key is:".$key.", value is:".$dictionary[$key]."\n";
}
print "Try undefined key three, no warning occurs:".$dictionary['three']."\n";
foreach ($dictionary['three'] as $value)
{
	print "Now we're iterating over a nonexistent key:";
	print "Key is: three, value is:".$dictionary['three']."\n";
}
?>

Running it results in this output:

php test.php
Key is:one, value is:got one
Key is:two, value is:have two
Key is:four, value is:missing three?
Try undefined key three, no warning occurs:

Warning: Invalid argument supplied for foreach() in /root/test.php on line 8

If it is vital to me to make sure I am aware of missing keys, I only have two choices. If I need a proactive solution, I have to use the array_key_exists() function to do existence checking before use. If I want a reactive solution, I write a log scanner, to pick up on these warnings. In every other OO language I have used, an exception was thrown for this condition, and my exception handling determined if the error was vital enough to have to exit immediately or not. This seems like a more efficient way to handle this condition. I would imaging PHP5 does not do this because of it’s need to be backward compatible with PHP4, but this is a guess.

It would be wonderful to have a -OO flag for PHP, which gives you the option to run PHP and expect more standard, stricter OO behavior in these instances.

2: Warnings cannot be “caught” like exceptions. Exceptions and warnings are distinctly separate beasts, and never the twain shall meet. Fine, I thought, maybe I could detect warnings similar to how we detect errors. But it seems like warnings cannot be detected when they happen. There is no PHP code I know of which can check if a warning had occurred in runtime. I tried to detect it using array error_get_last() but to no avail. if you know how, post your trick here.

3: In PHP, ‘true’ evaluates to an integer ‘1′. To get the boolean ‘true’ value from a ‘true’ statement, one needs to var_export() a true statement. Similarly, or maybe not, ‘false’ evaluates to no output. Here is an example:

<?
print "\nThe raw value of a true statement in PHP:".true;
print "\nThe raw value of a false statement in PHP:".false;
print "\nThe exported value of a true statement in PHP:".var_export(true,true);
print "\nThe exported value of a false statement in PHP:".var_export(false,true);
print "\n";
?>

And the output:

The raw value of a true statement in PHP:1
The raw value of a false statement in PHP:
The exported value of a true statement in PHP:true
The exported value of a false statement in PHP:false

This may not be noticeable to you in a standard expression. But if you’re doing funky stuff, like using the evaluated expression values as key references into the dictionary of a decision tree, for example, 1 does not equal ‘true’, and the difference matters quite a bit.

4: Long running processes with recursive circular references (such as Doctrine code) run out of memory. This is documented in many places, and the free() function works sometimes. A fix is coming in PHP 5.3. The foolproof solution for my code in production today (youch!) is to periodically restart the daemon. If you’re cringing right now, know that you’re not cringing alone.

There may be a part II to this article. Feel free to add your own PHP5 observations.

Gloria

Many of you are aware of my current total infatuation with Ruby, and that I’ve used PHP for about 6 years and at one point decided I hated PHP…until, I needed it for a quick one-off page and then realized that PHP had its place. Then again, I was totally frustrated with Ruby when making my moms bakery site and then turned to Drupal and Gallery (another fine PHP project), which saved my bacon and I got a website and photo gallery up in a weekend. So, PHP and I have had our moments but I’m not abandoning it!

Drupal powers some big sites, its not just for joe smoe’s blog. This is an interesting page about Is Drupal Right For You? and if you are wondering if its something that would even work for you.

I was excited to get my hands on a review copy of Pro Drupal Development. Its no secret that coders hate documentation and Drupal has one of the most complete online documentation I’ve seen for an Open Source project, but its almost too hard to find what you need amongst so much. The Pro Drupal Book is a godsend for the drupal programmer, new and experienced alike. I wish it was written a year ago!

The book starts off with a quick overview of how Drupal is structured and defines terms such as hooks, node and blocks in just 10 pages. Chapter 2 is a A step-by-step tutorial with making a module. That is a great idea to start off quickly writing code. It get the reader involved and hands on. I really tire of books that have to start off with the history of the internet, html and how things have evolved. Get to the code dangit!! Kudos to the Authors for that! Chapter 3 gets into module specific settings, like how to get your module to show up on the admin page and storing user settings that your module needs.

After you’ve had some experience with the code then the book goes into details on the specific parts of Drupal:

• Menu System
• Databases
• Users
• Nodes
• Themes
• Blocks
• Form API
• Filter System
• Searching and Indexing
• Files
• Taxonomy
• Caching
• Sessions
• JQuery
• Localization
• Using XML-RPC

Drupal is a pretty amazing framework, when I read the code I say “why didn’t I think of that?” … the module and hook system is genius.

Then some more general topics:

• Writing Secure code
• Development Best Practices
• Optimizing Drupal
• Installation Profiles

One of the chapters I skipped ahead to read was The Form API. In my years of PHP I’ve often tried to come up with a framework for doing forms and I wanted to see how they did it. This chapter follows a tutorial style as well. The Form API allows you to define fields, their label, their value, description. Some frameworks take the template approach, where you hammer out your HTML. Some are more configuration based like Drupal making a multi-dim array with keys and values. I can see advantages to both. There is a hook function for validation which allows you to write your validation checks.

PHP gets a bad wrap for security, partly because its pretty easy to learn PHP and newbies don’t always realize what they are doing. There is a chapter devoted to security and includes even some things I didn’t know about — encoding mail headers. The Form API is very secure,  one thing it does is check values that come from dropdowns were actually in the options and it wasn’t something that the hacker made up.

Developer Best Practices are great for the new developer, it talks about using cvs, tags, branches. It talks about how to create and apply patches (hint - you can contribute back to drupal). That is awesome. Alot of open source projects are like “HELP us, submit patches!” and the new user is left with uhhhhhh..how?

Caching is another interesting chapter. You will learn  how caching works and how Drupal Core uses it. There is a Cache API that has methods for module creators to make their modules faster.

JQuery … I am not sure if I like it or not, but its part of Drupal 5! I skipped ahead to this chapter to see what its all about. There is a javascript hook built into Drupal making it easy to add, thats pretty cool.

One thing I found lacking in the book is anything about Testing. There are few pages on debugging and some modules to help with testing, but I would like to see more. At least some talk about selenium, which is great for a site made with any framework/cms.

Over all, Thanks APress for another great book!

Your “AJAX” goals are simple: you want to communicate with your server, get a response back that you can use (or not), do something with that response (or not), and move on. As this is asynchronous, you want to do this without reloading your web page. Or, as a client once said to me, referring to certain animated gifs in the upper right-hand corner of certain browsers, without “making the world spin”. To this end, Yahoo! has supplied us one line of code:

var transaction =
YAHOO.util.Connect.asyncRequest(
method, uri, callback, postData);

or, same line with some data plugged in:

var transaction =
YAHOO.util.Connect.asyncRequest(
'POST',   'php/post.php', callback,"id=1&old_id=2");

When I was making the switch from synchronous to a-, it helped me to visualize a standard web form to see how form elements and attributes are translated to an AJAX request. It’s pretty obvious, but if you need an “aha!” moment, the above line is akin to the html form printed below (though unless you’re one of those people whose definition of interactivity is “The Monologue”, do refrain from creating forms with 2 hard-coded hidden inputs and nothing else! :)).

<form method="post" action="php/post.php">
<input type="hidden" name="id" value="1" />
<input type="hidden" name="old_id" value="2" />
<input type="submit">
</form>

So, excluding a reference to the callback for the moment (which is not addressed in this example), that form maps to the Connection Manager call quite simply: method, action (uri), data. Let’s look at the arguments required:

method: the method of the server request (POST, GET and others also available).

uri: the uri that’s receiving and processing the data you send (in our example, “php/post.php”). YUI’s examples use php, but, if you’re using the Connection Manager in a Rails app, it’s easy to adapt: your argument uri might read “/projects/update which would pass the data to the update method in projects_controller.rb, which would then be able to access the data through the params array, like so:

def update
@project = Project.find(params[:id])
end

In php you’d probably do some type of db query [assume input cleanup and some type of database abstraction layer, such as PEAR/DB_DataObject, here]

$project = DB_DataObject::factory('Projects');
$project->get($_POST['id']);

Callback: a reference to the callback object you are supplying. This is how everything is handled. More on that in a minute.

postData: the data itself in standard query-string format (”new=1&old=2″). NOTE: if you’re doing a GET transaction, your 4th argument would be false and your second argument would include the url and query string, like so:

“php/post.php?new=1&old=2".

So, what’s this callback?. In a synchronous transaction, you have the luxury of redrawing the page to process your data (and yes, nothing says luxury like a nice, slow, page reload…). In an asynchronous transaction you need to essentially “sneak” your data back into the page without reloading it. This is where your callback object comes in. It helps you get your data “in the door”, so to speak, so your page or application can change in a way that feels seamless to the user but often returns a visible result (changing a div, displaying some text, etc.) and if not a visible result at least a meaningful one (setting the value of a hidden form element, for example). Your callback is responsible for executing actions based on the data retrieved (or the failure to retrieve data) from the uri. In a standard synchronous form this action might be “generate an HTML table that displays your database results”. Or, “Print a message saying there are no results”. Of course, you can do anything you want with your data, that’s just an example of a fairly common scenario.

Once you’ve sent your data to the uri for processing, you need to wait for your response — without, of course, appearing to wait (save for the ubiquitous web 2.0 spinner you know you’re dying to try!). And, of course you want to know if your transaction failed. If you don’t watch for these things — “success” and “failure” in technical terms — you’re not going to be able to make an appropriate decision about what to do next in your app. So you feed your AJAX request a callback object: an object that defines functions for what to do in the cases of success and failure. In simplest terms, we’ve got

var callback = {
success: handleSuccess,
failure: handleFailure
};

where “handleSuccess” and “handleFailure” are user-defined functions that take the http response object and do stuff with it.

handleSuccess = function(o){
// cheer! (or process data returned from the server)
}

handleFailure = function(o){
// cry, vow to try again! (or display failure message)
}

There’s also the ability to pass scope, timeouts, and additional arguments to the callback object. To do so you’d read the great tutorials at the links above and add the lines below, of course changing the values to values meaningful in your application.

scope: Ajaxobject,
timeout: 5000,
args: ['arg1', 'arg2']

The handlers. handleSuccess and handleFailure both take an object o, which is the http response object. There’s a detailed list of all the properties of o on the yui page (Not to be confused with the Story of O, which I will not link to as it is beyond the scope of this article, you dirty rascals, you…). The property you’ll likely use most often is o.responseText, which is the server’s response as a string. This is what you pass back from good old ‘php/post.php’, and getting it is simple: echo. What? echo. What? echo..o..o… ok, sorry, moving on. For instance, if we wanted to capture the update_date in our successHandler to print to our page and we’re using php, we’d write something like this:

echo $project->update_date;

and if we’re in Rails? something like this:

render_text @project.update_date

If you need more data than a string — an array or collection of objects passed back from the server, you’ll find that’s simple, too: call the ruby method to_json() on your array instead. This essentially serializes your object so it can survive the journey to the Client. Once there, you can access the data using JavaScript’s magic wand: eval(). It’s great. So if you had an array of users connected to a project (and your database relationships are set up correctly), you could write

render_text @project.users.to_json

in php, assume you’ve got your $users array, and use print_r

print_r($users);

The in your JavaScript successHandler use eval(), like so:

var users =  eval(o.responseText)

and bingo: in two lines you’re happily in your JavaScript parsing your users array like you would any other JavaScript array. You have connected your server to your DOM and no one is the wiser for it.

All this is great. We have our AJAX call and our callback object and are ready to go. But, suppose you don’t want to rewrite the AJAX call all over your app? The Yahoo folks have a great example of a ‘“hypothetical ajax object” (mysteriously named “AjaxObject”) that encapsulates success, failure, and process methods and calls a callback object that defines AjaxObject as it’s scope. Encapsulating your AJAX request so you can call it from wherever you want in your scripts in a DRY fashion makes your code cleaner and easier to manage. Yahoo! does this well in their example: in my usage I changed it up a little bit to meet my needs.

To quote the great Chicago writer Leo Tolstoy from his famous novel Anna Karenina Does Lake Michigan, ‘“Happy families are all alike; every unhappy family is unhappy in its own way”. I’ve learned that when working on an app, the opposite is true: success cases call for a range of actions: failures can more easily handled (log, display error, abort). Based on this, I’ve adapted the yui AjaxObject example to accept a postAction, successHandler, and object (used to define scope). This allows you to call AjaxObject from other objects, pass specific success handlers, and pass this (a reference to your current object) so you can access it in your successHandler from within the calling object. The AjaxObject builds the callback using those arguments. Like so:

var AjaxObject = {

handleFailure:function(o){
// Fail gracefully
},

/**
* Wrapper for AJAX calls using YUI connector
*
* @param postAction {String} URL to post to
* @param callBackSuccess {String} Success handler
* @param postData {String} Data to post
* @param obj {Object} Object that handler has scope in
*
*/
startRequest:function(postAction, callBackSuccess, postData, obj) {

var callback = {
success:callBackSuccess,
failure:this.handleFailure,
scope:obj
}
// ASSUME you've shortened your yui connection mgr to $C
$C('POST', postAction, callback, postData);
}

};

Then you can call AjaxObject from within a class, like so, and pass it a class method as it’s success-handler:

var Project = function Project(){
// initialize project however you like
this.foo = "bar";
...
// CREATE in db and return id
AjaxObject.startRequest('/project/create',
this._generateDbId, postData, this);

}   // Success handler  Project.prototype._generateDbId = function(o){
if(o.responseText !== undefined){
this._setDbid(Number(o.responseText));
// DO other stuff..
}
}

This way your AJAX calls are in one place, you can use them in the scope of the calling object and define as many success handlers as success cases (or pass false); and fail in one standard way (gracefully, of course). Of course, this can be adapted to pass failure cases in too, or however you like. This was a way I found helpful in my work, and I hope it’s helpful to you as well. And thanks again to the folks at Yahoo! for providing so much great stuff to work with in the first place.

Published by: Apress

Authors: Chris Snyder and Michael Southwell

Book Site | Sample Chapter: Preventing SQL Injection | Table of Contents

At first, I thought this book was all about cleaning your input variables and filtering your output, XSS attacks, SQL injections but I was most presently surprised to find that it was that and so much more! In fact, I would have called this “ProPHP Security and Administration” instead! It is absolutely fantastic. It really is about security in all of the facets of web development - from server, to code, to database to the system users.

The book is divided into 4 parts:

• Part 1: The Importance of Security
• Part 2: Maintaining a Secure Environment
• Part 3: Practicing Secure PHP Programming
• Part 4: Practicing Secure Operations

Here are some brief overviews of the sections and the tidbits I found interesting:

Part 1:

The first part is the shortest and gives a general overview the what and why of security.

Part 2:

The second is much more hearty and goes into detail about Shared hosts and why they are secure and how to make the more so. It even dips into alternatives for the traditional shared hosts and goes into Virtual Machines. This is valuable to not only to administrators but to PHP Developers. After reading this, I understand the “why” behind many of the things about shared hosting that I found frustrating.

One of the most important things I found in this chapter is how to maintain separate development and production environments. When I was helping to set this up at one of my past jobs it was a topic that I couldn’t find much information about. It also makes mention of version control, using wikis, bug tracking, sandbox and testing! Oh and here’s a concept…. pretend your live system failed — how well does your backup plan work?

How many times have I thought, I should make a cron job to back up my database to my home server every day/week? Have I ever done this? No! But now I have no excuse! Backing up a database and storing remotely is one of the sections in this chapter and code included! Fantastic.

There are chapters about Encryption theory and practice which I read several times to understand. It was interesting but it wasn’t something I have to do right now in my life, but I will return to this book to refresh my memory when I do.

Securing Network connections SSL and SSH, these proved helpful as I have become the “Reluctant System Admin” for one of my projects — partly because if they were to hire a part time person I’d rather they get a CSS person and I’d rather do the sys admin!

The Controlling Access section goes into details about using certificates with php, single sign-on, basic and digest http authentication … whoa this is some deep stuff! But good, when I was looking into this for a project a few years ago I couldn’t find anything helpful. It continues with then permissions and restrictions, a lot about Unix permissions and keeping things running where they should, securing databases and PHP Safe mode!

Part 3

Finally — the stuff that I thought the book would be about - validating user input, filtering output, preventing cross site scripting attempts, remote execution.. so much more to security than I thought! It talks about securing temp files, I always assumed the OS handled this and I didn’t need to worry.

Part 4

Ahh — Practicing Secure Operations… all you ever wanted to know about making sure your users are humans, verifying your users, setting roles for users, logging your users actions, preventing data loss, executing system commands safely, working with webservices and finally Peer Reviews! Sometimes it’s that extra pair of eyes that can see things you miss.

Something I find interesting - in the section about preventing data loss, it talks about setting a flag on records that are “deleted” and then making a db view of the “good” data and using that to select from. One of the things I like in Ruby On Rails is this “acts_as_paranoid” model option that does about the same thing. Neato.

Pro PHP Security is a most excellent read and so much deeper than my brief overview here. It will be a handy book on my shelf to keep me on my toes regarding security in all areas of web development, from the server to the code, to the users, to best practices of security you will find this is a helpful book too!

Book Site | Sample Chapter: 3 PHP and Ajax | Table of Contents

Although no stranger to Ajax, I received a review copy of Beginning Ajax with PHP expecting some watered down presentation of Javascript with some PHP thrown in. I was quite surprised to find a good presentation of using Ajax and PHP, easy enough for the beginner and still interesting for those who have done it for years.

The book starts out exactly how I would write it — SIMPLE! The first time I did Ajax with XHR (xml http request), I used a plain text file, which I then read into a DIV at the click of a link. This takes a similar approach and has data stored in an array which is then accessed with a simple call to a PHP file. The following chapter, takes it a step further and this building upon previous chapters is a common theme in the book.

After going through the basics, the book gets into more practical uses of Ajax. The latter chapters talk about using forms to pass along data to be processed by Ajax and doing form validation. It also gives a good explanation of the proper use of the form methods GET and POST. It goes into detail about uploading images and other files using a hidden form submit trick, since XHR doesn’t support file uploading (javascript is not allowed to access files on your harddrive). And this chapter is the perfect predecessor to the “Real-World Ajax Application” chapter where you will take what you have learned and create an Ajax based photo gallery. Practical, hand-on is the best way to learn something IMHO (Sorry “Hello World” scripts!). It is interesting that this chapter is in the middle of the book, when I would expect it at the end. Perhaps the author wanted the user to jump in and try it, instead of persevering to the end. I don’t know about you, but often the last few chapters of the book go unread by me.

After the reader has confidence on how to use AJAX, the book gives the warning, “Whoa! Wait a minute! AJAX isn’t appropriate for EVERYTHING!” It gives examples of when AJAX would be a good idea and when it would not. I think this is pretty important as each CEO now wants Ajax everywhere in their application but it’s not always the best solution! And it talks about the classic, “THE BACK BUTTON”, problem. Then, in the same chapter, the book takes sort of a funny turn (in my opinion) and gives an introduction to PEAR. The book explains how to use PEAR’s HTML_TABLE class to illustrate a good use for Ajax in creating an Excel-like grid that sums columns. This is a very cool class but would have been better suited for an appendix.

The rest of the book seems to be a random splattering of interesting topics: web services, map applications, cross-browser issues (touches again on the back button problem - but a solution this time!). There is also a brief mention of security. This should have been more in the middle of the book (see above for skipped last chapters syndrome). What then follows is a testing and debugging chapter which would have been more effective as the 3 or 4th chapter in the book. Finally there is a chapter about the browser DOM.

A great minor addition to the book would be an overview of some Ajax libraries such as Prototype, JQuery, Dojo, etc.

I had borrowed a Perl Hacks book from and friend and really liked it, it was great! It had a lot of practical things as well as some fun things. I expected the same from PHP Hacks and I was not disappointed!

Here’s the table of contents:
http://www.oreilly.com/catalog/phphks/toc.html

O’Reilly also has some sample hacks:
http://www.oreilly.com/catalog/phphks/chapter/index.html

Here’s some that I found interesting:

The Practical Stuff
Breadcrumbs
Not familiar with the term? Check it out. I think this hack may get you started on a breadcrumb function/method. In the end they suggest a xml file to show which page urls were parents of which. The way I’ve done this before was I had a class for each major section, and sub section, and had a method ->addCrumb($label, $url) which I had in the constructor…and the subsections of course would call the parent contructor and it kept the breadcrumb hierarchy intact. But hey, that’s the fun of programming - different ways to do the same thing to meet different needs! Definitely a good hack to get the juices flowing!

Building Lightweight HTML Graphs
Don’t want to use flash to display a graph? use PHP to figure out the ratios and give you a width and use a table. I’ve done something similar by figuring out the width of a div, making the background a color… and I have used 1×1 pixel images that have been stretched to a certain width and height. It’s a very lightweight download for your user, that’s for sure! Later in the book, there’s a hack for creating a Dynamic HTML Graph that will change without reloading the page.

Put an Interactive Spreadsheet on your Page
This one is so cool — you need to read about it in the book yourself! Lets says, move over Google Spreadsheets! We can do it too!

Create Link Graphs
I call these Tag Clouds, not sure why they call them Link Graphs here in the book — probably, tag clouds has been copy written by some Web 2.0 smartass. Here I am, sue me! This is a unique and visual way to show the popularity of certain words in a group. Rather than a numbered list, this is visual. I had this discussion not too long ago with a group and sadly, most of them didn’t get it. I think if I actually used this sort of technique on a page, I’d include a “What’s this?” link or an alternative view.

Create Dynamic Database Objects
This was very interesting to me because I love Active Record in Rails. This relies on some of the magic of PHP5 to work, probably this is not going to be the best performance code but really — is anything easy the fastest?

Generating CRUD Database Code
Similar to previous, but a create-once and go method, this hack will read from a xml file and create CRUD objects for maintaining your database. These will probably be faster then the previous one -but you’d have to run this script or update manually when your schema updates. Some people hate code generation - some don’t. Pear’s DB_DataObject is a similar concept.

There are a few other nifty database hacks making this my favorite section of the book!

Turn any Object into an Array
Using foreach is my default iteration function and using the PHP 5 iteration interface on any object to give it that functionality is awesome. This is one of the most practical design patterns (other than the other favorite: singleton) that I talk about to people who ask me - what are design patterns and why should I care? Speaking of design patterns - tired of reading a design pattern book and trying to figure out the smalltalk or java code? the design pattern section of the book has diagrams and sample code that you can understand.

Fun Stuff

Build a DHTML Binary Clock
What is that you say? Take a look at ThinkGeek and learn how to make something similar in DHTML. Yes, this is not practical but its fun. Something fun is always a great way to get excited about programming and enjoy yourself.

Generate Your Unit Tests
I put this in the fun section because testing IS fun - I love it. One of the things people (normal people, not wacky test freaks like me) complain about testing is - no time! Here’s a hack that will let you put your test in a comment and running this script on it will pull out those comments and write your test for you. Nifty!

Build GUI Interfaces with GTK
I’ve always wanted to try something with GTK, but never have. This hack shows you how to build a regex expression tool to test and play around with regex. I’ve had programs like this and they are darn handy when you want to do a quick check. So, after you’ve had your fun building this — its practical as well.

Send RSS feeds to your IM Application using Jabber
Depending on your use, this may in fact be practical but I think its rather fun. I have not figured out a use for this myself but the book uses it to send weather forecasts to your IM client. Neat-o

What I didn’t like about this book
not too much in the way of checking input variables. I know, probably they “leave that as exercise to the reader” but noobs and experts alike need to get this ingrained into the head by default. So I suggest also picking up Essential PHP Security

What I like
ER diagrams and control flow - Nice!
Handy size

I’ve only touched on a few of the great hacks and there are many more I also like, but didn’t really want to give away the entire book! I suggest you pick it up and keep it handy. Next time you are bored — flip though and find something interesting!