There is no right or wrong way, but no matter what there is no *pretty* way to do SQL inside of a PHP application. I have been having a personal debate with myself all week about how to make SQL statements nicer in an application without going to a huge DBAL package like Doctrine.

He looks at each idea and provides some of the pros and cons about each of them, noting that he hasn't quite decided on which is the best method. Some sample code is included to help clarify the points, showing the "find by unique key" version and how a more complex query might be created with the "builder object."

If you have ever popped open a PHP session file, or stored session data in a database, you may have noticed that this serialization looks very similar to the serialize function's output, but it is not the same. Recently, I needed to serialize data so that it looked like PHP session data (don't ask why; I highly suggest not doing this if it can be avoided.) It turns out, PHP has a function that encodes data in this format: session_encode.

Unfortunately, this method doesn't take arguments - it just outputs the encoded version of the current session data. So, he came up with his own encode/decode methods that use the PHP session, extract the serialized string and return it.

Parsing XML essentially means navigating through an XML document and returning the relevant data. An increasing number of web services return data in JSON format, but a large number still return XML, so you need to master parsing XML if you really want to consume the full breadth of APIs available. Using PHP's SimpleXML extension that was introduced back in PHP 5.0, working with XML is very easy to do. In this article I'll show you how.

He starts with some basic usage of the SimpleXML parsing, giving an example XML to parse, the resulting object and how to access the data inside it. There's also a bit about dealing with namespaces in the XML you're parsing and a more practical example - parsing the output of a YouTube feed to get links to various videos.

Operator precedence parsers are very simple on the surface. So don't feel in the least bit intimidated, because by the time you've read through this I hope to have you walk away with a solid foundation on how to write your very own operator precedence parser. The goal is to understand how to solve the problem of operator precedence parsing, and not necessarily to write your own parser. Learning how the problem can be solved is the most important thing to take away from this article.

He starts with an introduction to the concepts behind "operator precedence" including processing order and grouping. He also mentions infix and postfix (RPN) notations for handling different formats of equations. He used the "Shunting-yard Algorithm" and how it relates to handling the different parts of the equation, one at a time, in the correct order. He rest of the post is dedicated to the details of the execution in the tool, including code examples and the tokenization of the strings passed into it.

We recently upgraded phpunit from a very old version to the current 3.6.x version (at time of writing). During the upgrade I noticed that assertType is no longer supported in many of our tests which were testing if something was a string, an array, or an object. So I had to write a quick script to update assertType to assertInternalType and figured I would post it for others if they needed to do the same.

The code goes into each of your tests (recursively) and finds the places where the "assertType" assertion is used and replaces it with its newer cousin "assertIntrnalType".

There's already a great article here that discusses Test Driven Development, but did you know that you can also test the code that interacts with your database? Especially if your application is data intensive, subjecting your CRUD code to a battery of tests is good practice that helps ensure that your application is working correctly. In this article you will be learning how to write database tests in PHP using PHPUnit and its database extension.

Included in the post is an example schema and an example of the seed data (defined as XML) for the testing to use as predictable data in its execution. His test class extends PHPUnit_Extensions_Database_TestCase (instead of the usual PHPUnit_Framework_TestCase) and a test for a basic "getArticles" method in his "IArticleDAO" class. By calling the "createXMLDataSet" method, the test loads in the pre-defined XML records and allows the correct evaluation of the assertions,

The issue of PHP strings equaling zero has come up a few times recently. [...] Running that will display Equals zero!, which at first glance probably doesn't make much sense. So what is going on here?

He gets into the specifics of what's happening - a bit of type jugging, less strict comparison since it's the "==" versus "===" and how the PHP manual talks about strings being converted to numbers.

While I still think it is odd that the string gets cast as an integer instead of the other way around, I don't think this is a big deal. I can't recall a single time where I've ever run into this issue in a PHP app. I've only seen it come up in contrived examples like the ones above.

Yes I know. Eval() is evil. If our answer is to use eval() function, we are probably asking the wrong question. When we see an eval() function all our coding smell's red lights start flashing inside our mind. Definitely it's a bad practice. But last week I was thinking about it. How can I eval raw PHP code without using the eval function, and I will show you my outcomes.

He includes some sample code showing a basic script with a class and a loop executing normally, then an "eval version" that puts it all in a string and executes it. He offers a different method - not an ideal one since it requires being able to write to the local file system, but prevents the need for eval - writing the PHP code to a temporary file and using a "fake eval" to pull it in.

Back in September, Socorro received a security bug relating to the method we were using for processing inputs for the duration of certain reports. The vulnerability included a proof of concept, with an alert box popping up on production when the link was followed. [...] I was quite surprised at the root cause of the vulnerability. We had opted to compare the incoming data against a known set of valid values - a common practice when whitelisting certain inputs. [...] As expected, when this [example] code is tested, a string of '3' and an integer of 3 work equally well, and a string of '5' and an integer of 5 fail equally.

This automatic casting that PHP does internally caused another issue as well - if the string passed in even started with a valid number from their whitelist set, it still passed.

At first we thought this surely had to be a bug in PHP. However, Laura Thomson told me "If comparing two values, type juggling is performed first, which means that the string is converted to a number. This is done by taking the first number found in the string. So this may be confusing/a quirk/a gotcha, but it isn't a bug." And she's right: this isn't a bug per se, but it's certainly an interesting "gotcha."

We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.