Out of curiosity I asked another friend, a team lead, how things where going with their PHP MySQL project, for which they had planned to have most of their business logic in stored procedures. I got an email in reply stating something along the lines: "Our developers found that mysqli does not support stored procedures correctly. We use PDO.". Well, the existing documentation from PHP 5.0 times is not stellar, I confess. But still, that's a bit too much... it ain't that difficult. And, it works.

He describes the three parameters (IN, OUT and INOUT) and gives some examples of setting/getting them from your SQL statements. They're all still set up using the query method on your connection as well as handling the result sets that come back and working with prepared statements.

We were talking about why some of the SPL Iterators accept only an Iterator as the constructor argument (Such as LimitIterator), and others accept either an Iterator or an IteratorAggregate as the argument (Such as IteratorIterator). Feeling that this would be a useful feature to add (having all of them accept an IteratorAggregate), I opened up the PHP source and started looking at how hard of a change this would be. What I found was... Interesting...

He shares some of the C code he came across in his investigation including a "WTF" moment when he found a case statement for DIT_IteratorIterator in a constructor. Because of some of the logic in this constructor, the inputted iterator is "cast down" to a class. This is shown in a few code examples comparing simple iteration objects and arrays and how it seems to be able to bypass class inheritance to use methods from other classes.

The key issue was that 5.3.7 accidentally broke is_a() for a reasonably large number of users. Unfortunately the fixup release 5.3.8 did not address this 'mistake', and after a rather fruitless exchange I gave up trying to persuade the group (most people on mailing list), that reverting the change was rather critical (at least pierre supported reverting it in the 5.3.* series).

This new issue was causing some strange errors to pop up in his code because of a parameter type change in the is_a call, updating the first parameter to be an object instead of a class name. The is_a() call sends its requests to __autoload in some cases and the string->object mismatch of those parameters causes errors to be thrown. His workaround is, in your checking, just be sure to call an is_object first before passing things off to be is_a() checked and autoloaded.

At the end [of Marco's post to his blog], he states it ultimately boils down to find a better way to bring features build downstream back upstream. So I thought I would do my part by first my blogging about a few "itches" I'd love to see scratched. My first itch would be some form of Object Notation for PHP.

He talks about the notation method that Javascript has always had and how it can help to make objects more flexible by not forcing their creation through a method/argument interface. He offers one potential solution - using arrays for settings values - but notes that it could be more trouble than it's worth in the implementation. He proposes a new sort of notation instead, one that allows the passing of something similar to the Javascript JSON-ish definition of values and callbacks as anonymous functions.

Last week at JumpIn Camp we spent quite a bit of time focusing on the SQL Server Driver for PHP. As developers worked to build SQL Server support into their applications, they had lots of questions about how both the SQLSRV and PDO_SQLSRV drivers work under the hood. One of the questions that came up was "When using the SQLSRV driver to execute parameterized queries, why do I have to pass parameters by reference?"

He includes a simple code example to show this passing by reference - first without it on the call to sqlsrv_prepare (and the warning message it gives) then the more correct version of passing in the past parameter by reference.

The SQL Server Driver for PHP team understands that passing parameters by reference is not ideal. [...] With that said, the team is continuing to investigate solutions that would produce expected behavior without passing parameters by reference.

In this episode, Manuel Lemos and Ernani Joppert discuss several unusual site speedup techniques presented in recent articles of the PHPClasses site blog. They also discuss the (non-)inclusion of new PHP features discussed by PHP core developers like having named parameters in function calls and the support of Java-like annotations in PHP code.

To listen you can either use the in-page player, grab it from iTunes or just download the mp3. Complete show notes and transcript are also included in the post.

In this video tutorial from our Advanced PHP series, we look at how to write a very simple MVC (Model,View,Controller) framework from scratch using PHP 5.3, soon to be PHP 6

You can find other advanced PHP videos on this page of the KillerPHP.com site covering topics like Javascript, creating CRUD, making a login system, ORM and much more.

How to prevent SQL injection in PHP scripts is probably a topic that doesn't need anything more written about it. [...] However, it is important to have fresh information for new Web developers and I don't necessarily agree with some of the most common suggestions for preventing SQL injection. [...] So, this will be yet another post about preventing SQL injection, but I will offer my 2 cents about what I think is the right way to prevent it.

He explains SQL injections for those that are unsure on the concept with a basic form example and what he thinks is a better way to prevent it than just trying to escape the SQL - bound parameters. These allow you to both filter and protect your application from any would-be attacks that might come your way. He is, of course, using SQL Server so the parameter binding is included in the database functionality. Other databases might have to use something like PDO to accomplish the same kind of thing.

I've been getting increasingly impatient with its tendency to try to escape my SQL code for me - this is a really useful default feature but it seems to assume I don't know what I'm doing and so it puts backticks all over perfectly acceptable SQL code, very annoying!

Thanks to a reply on twitter from damiangostomski to her frustrations she found the optional second parameter you can give the "select()" method, a boolean that tells it whether or not to escape the query (it's mentioned here) for those that were wondering.

This not only makes parameter passing intuitive (rather than calling $this->_request->getParam() ) but also automatically uses the default value if provided and if typehinting is provided either via phpdoc comment or before the parameter (array or classname) it will do the required instantiation or type casting.

The post includes a snippet of sample code, but you can learn more about the script here.