Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

There is a vulnerability in certain CGI-based setups (Apache+mod_php and nginx+php-fpm are not affected) that has gone unnoticed for at least 8 years. Section 7 of the CGI spec states: 'Some systems support a method for supplying a [sic] array of strings to the CGI script. This is only used in the case of an `indexed' query. This is identified by a "GET" or "HEAD" HTTP request with a URL search string not containing any unencoded "=" characters.'

A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this. Straight shebang-style CGI also does not appear to be vulnerable. If you are using Apache mod_cgi to run PHP you may be vulnerable. To see if you are, just add ?-s to the end of any of your URLs. If you see your source code, you are vulnerable. If your site renders normally, you are not.

You can download this latest version from the downloads page for the source releases or windows.php.net for the Windows binaries. You can look at the Changelog if you'd like more details on the update.

In this article we will be looking at how to handle errors in PHP. Errors are an inevitable part of software development, and accordingly, we will be looking at the various error types and demonstrating how to handle them. If you intend to run any of the sample scripts in this article, please make sure that display errors is turned on in your PHP initialization document (php.ini).

The article talks about the types of errors PHP uses (syntactical, runtime and logical) and shows how to handle some of the most common issues with them. It also talks about the different error reporting levels (ex. E_ALL, E_WARNING, E_STRICT) and includes the code for a simple error handler class that switches off and handles each type differently.

Solr supports multiple output formats. Some are for general use (xml, json) and some are even language specific. If you're using PHP these are the most logical response writer formats: xml, json, phps (serialized php), php (php code to execute). On top of that PHP offers multiple ways to parse XML. I'm benchmarking these options to determine the most efficient decoding to implement in the next major version of Solarium, but the results should be useful for any PHP Solr implementation.

He includes a snippet of code he's using to generate the benchmarks, a PHPUnit test that pulls in two different json-based results and, for now, just runs a json_decode on it. You can see the results of his testing here, graphing out the different response handling methods and their time (in milliseconds) to parse the response. It's interesting to see that there's a direct relation to the size of the data set and how long it takes for the methods to execute.

The current code for his benchmarks is available over on github

Earlier today, on twitter, @skoop asked: "dear #lazyweb, when I use DateTimeZone('GMT'), why does format('e') output UTC?" [...] As you can see [the example with a format of "e" on a DateTimeZone('GMT')] has UTC and not GMT as you might expect.

Derick mentions that sometimes, systems require "GMT" instead of "UTC" in the output they're given. To work around this issue, he shows how to add a "type 2" timezone to the DateTime object by including it when you initialize the object (code samples included). Using alternative methods, you can add these "type 2" timezones in three ways - an offset in the initial string, using the abbreviation (like "EST" or "PST") and specifying the long version of the timezone (like "America/Montreal").

PHP has a vast selection of built-in string handling functions that allow you to easily manipulate strings in almost any possible way. [...] There is no way I can cover every string function in one article, and besides, that is what the PHP manual is for! But what I will do is show how to work with some of the most commonly used string handling functions that you should know. After this, you'll be working with strings as well as any concert violinist!

He shows how to use functions to: change the case of string, remove extra whitespace, get the length, slicing them up and doing replacing on some certain characters. You can find more information on these and the complete list of string functions in PHP in the manual.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

In this fifth part of an eight-part series on working with file and operating systems with PHP, you'll learn how to read data from a file and move the file pointer.

Example code is included showing how to use the file, file_get_contents, fgetc, fgetcsv, readfile and fscanf (among several others). Also included is code showing how to use the fseek method to move around in a file.

I love PHP's PDO (PHP Data Objects) extension; it gives a consistent, object-oriented interface to handling all kinds of relational database backends. One thing that annoys me is that the MySQL driver for PDO defaults to a silent error mode which can make SQL errors tricky to spot!

In her two code snippets she shows a failing PDO request (that fails silently) and a method for catching this issue - checking the result of the "errorCode" method to see if it equals "0" (zero). If there were errors, you can use the "errorInfo" function to get to them. This will return the SQL error code, the driver-specific error code and a driver-specific error message.