In this new post Josh Adell looks at working with PHP sessions and how you can manually encode data to look as if it came from the normal session handling.

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.

Sherif Ramadan has a post looking at creating a better operator precedence parser in PHP. His example is a fully PHP implementation that takes equation strings and evaluates them to create the result.

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.

In this quick post to his blog, Mike Purcell mentions the deprecation of the "assertType" assertion and includes some code you can add to correct the issue in your tests.

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".

Joseph Scott has a new post to his blog looking at "why PHP strings equal zero" - that when you use the "==" operator on a string to compare to zero, it's true.

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.

In this new post Gonzalo Ayuso talks about "using eval without using eval" in PHP applications - executing PHP code without having to use the eval function to do it.

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.

Brandon Savage has a new post to his blog about what he calls a XSS vulnerability in the making, something to watch out for when you're doing validation in PHP involving the possibility of numbers as strings.

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."

On the Refulz.com blog there's a recent post introducing the __toString() magic method in PHP. This handy method allows you to define how to return an object when it's referenced as a string.

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.

Nicolas Grekas has shared another tool that he's pulled out of his "Patchwork" framework to make it a stand-alone tool: the Patchwork-UTF8 helper that provides matching functions to those PHP already has for regular strings, but a little smarter to work with UTF8 correctly.

The PatchworkUtf8 class implements the quasi complete set of string functions that need UTF-8 grapheme clusters awareness. These functions are all static methods of the PatchworkUtf8 class. The best way to use them is to add a use PatchworkUtf8 as u; at the beginning of your files, then when UTF-8 awareness is required, prefix by u:: when calling them.

In the README for the tool he talks about the functions included in the current release that match PHP's string functions as well as some additional methods like "isUtf8", "bestFit" and "strtocasefold". It relies on the mbstring, iconv and intl extensions being installed, and if they aren't, it falls back to other functionality (list of those methods included).

In this new post to his blog Nikita Popov aims to dispel the popular micro-optimization myth of using single quotes over double quotes for a performance boost.

If there is one PHP related thing that I really hate, then it is definitely the Single Quotes Performance Myth. [...] Let's do a random Google search for "PHP single quotes performance": You will get many results telling you that single quotes are faster than double quotes and that string interpolation is much slower than string concatenation. Most of them advise to use single quotes and concatenation to improve the performance of your application. Let's be clear here: This is pointless.

He did some benchmarking of his own to see how the myth would hold up and, as it turns out, it doesn't - "There is none". His proof compares two strings, one normal single-quoted and the other a double-quoted, and the opcodes they generate. They end up exactly the same. Since it's the opcodes that matter, he recommends using something like APC if you're really worried about the performance. He also includes an example using the token_get_all function of PHP to see how fast the strings run through the lexer too (again, almost no difference).

As an added bonus, he also throws in a bit about string concatenation versus string interpolation with some benchmarking scripts and results of their own.

In this quick new post to his blog Mark Story talks about two new errors he ran across when upgrading his installation to PHP 5.4, both showing up under E_ALL.

I've been running the PHP5.4 RC builds for the last few months, and there are some interesting changes in the upcoming PHP release. On top of all the great new features coming in PHP5.4. After updating to PHP5.4-RC4, a few things that used to not trigger errors and silently do the wrong thing, now trigger notices or warnings.

The two he mentions deal with a new warning on illegal string offsets and the other about string offsets ("Notice: String offset cast occurred"). You can find out about more changes in the PHP 5.4 series in the various Changelogs for each Release Candidate and beta release.