Ulf Wendel has a new post today with details on using stored procedures with mysqli - not overly difficult if you know how to handle the IN, OUT and INOUT parameters. He includes a few code examples showing how to use them.

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.

In a new post to his blog Till Klampaeckel looks at something the Zend Framework's Zend_Db component dosen't seem to support - an "IN" on a fetchAll - and how he worked around it.

The IN-clause is only supported when I wrap my statement with Zend_Db_Select, which is something I rarely do. Part of the reason is that I still don't feel comfortable writing my SQL in a DSL which doesn't really do anything besides wrapping a string into an object and IMHO it doesn't add to readability either. And the other reason is that I don't plan to run this import against any other database than MySQL. Which is why I don't see the need for abstraction either.

He shows some failing code where the IN isn't populated correctly when an array is passed in and the warnings that come with it. He solution's pretty simple, though - rewrite the query string before sending it with the correct number of bind locations ("?") for the number of parameters. In the comments, other approaches are suggested including using a simple select() call or tricking the bindings with a special kind of array.

Company	Purdue University
Location	West Lafayette, IN
Title	Web Programmer/Analyst
Summary	Responsible for designing, developing, and maintaining complex Web applications. Duties can include: meeting with customers to understand application requirements, developing technical specifications for application, programming application, testing that application satisfies requirements, is secure, and is accessible to all users, interfacing Web application with a Database Management System (DBMS), and documenting application and creating user manuals. Develop, support, and administer database server software. Provide help desk support for faculty, staff and graduate students. Serve as a member of the Department of Mathematics Web Committee. Supervise one regular service staff member. Assign, instruct and review the work of staff. Qualifications Required: Bachelor's degree. One year experience designing and interfacing database applications that interact with the web, and database administration. Experience developing database-driven web applications using PHP and MySQL or PostgreSQL. UNIX and Linux web server experience. Good oral/written communication skills. Capable of working both independently and with others, while managing multiple projects. Preferred: Experience with CGI scripting in Perl. Knowledge of Shell scripting, Java, Subversion, XML. Additional Information: FLSA: Exempt (Not Eligible For Overtime) Retirement Eligibility: TIAA/CREF Contribution Waiting Period. See this page for more information: http://purdue.taleo.net/careersection/wl/jobdetail.ftl?lang=en&job=42620
Link	More Information

While not directly PHP related, Developer.com has an interesting article covering the use of authentication in your applications.

Authentication is the act of establishing identity via the presentation of information that allows the verifier to know the presenter is who or what it claims. This identity could be any number of things, including people, systems, applications, messages.

Why would one want to verify an identity in the first place? Hopefully, most people reading this recognize that as sarcastic humor. This article presents different types of authentication and ways of adding it to your applications.

They discuss a range of authentication types - all the way from simple authentication out to cryptographic and multi-factor authentication. They wrap it up with a look at how you can choose the appropriate authentication methods for your applications as well.

I've seen several sites moving more and more to the next step up from the basic level of authentication up to even just the multi-factor. The more levels of security you can put on your application the better, especially if you're housing any kind of personal data about your users.

PHP Magazine has posted their results from a poll they took after the "PHP Developers Meeting" that happened in Paris about what developers would like to see in PHP6.

Following release of the PHP Developers Meeting in Paris (November 11th and 12th, 2005), the International PHP Magazine polled the community to find out What they were looking our for, the most, in PHP 6?

The results of the poll suggest almost an equal weightage to all of the points noted in the developer meeting minutes. Of the 809 members polled, 15-20% of the respondents were looking out for OO functionality changes, functionality cleanup, performance boost, Security enhancements, and unicode support, in that order. Only 7% were keen to see additions made to the PHP engine. Less than 3% clicked on the "others" option.

The votes were pretty close, with "Functionality" only barely edging out "Performance Boost". "OO Functionality Changes", however, topped the list with points to spare.

In this post on the Sitepoint PHP Blog, Harry Fuecks makes a quick mention of another blog post dealing with the enhancements in PHP6 and another handy feature he noticed as well.

Pierre-Alain Joye picked this one up last week, and it needs repeating. For PHP6 the following are already gone from CVS: Register globals, Magic quotes, Safe mode.

As blogged a while back, you'll find these changes discussed here. Nice use of carrot and stick in fact - for the pain on fixing your apps to run under PHP6, you get Unicode.

The other feature he's noticed pertains to the php.ini settings file that PHP uses:

Just noticed a new ini setting here: "allow_url_include - PHP_INI_SYSTEM Available since PHP 6.0.0." Excellent! That eliminates another major source of exploits (perhaps the biggest) have moaned about that before here and here.