London, UK

Friday, January 8th 2010, 09:13 GMT

Over and over again PHP users complain that next month in PHP's date-string parser doesn't go to the next month, but instead skips to the one after next month; like in the following example:

modify( 'next month' );
echo $d->format( 'F' ), "\n";
?>

The output of the little script will be March. March obviously doesn't follow January as February is in between. However, the current behavior is correct. The following happens internally:

• next month increases the month number (originally 1) by one. This makes the date 2010-02-31.

• The second month (February) only has 28 days in 2010, so PHP auto-corrects this by just continuing to count days from February 1st. You then end up at March 3rd.

• The formatting strips off the year and day, resulting in the output March.

This can easily be seen when echoing the date with a full date format, which will output March 3rd, 2010:

format( 'F jS, Y' ), "\n";
?>

To obtain the correct behavior, you can use some of PHP 5.3's new functionality that introduces the relative time stanza first day of. This stanza can be used in combination with next month, fifth month or +8 months to go to the first day of the specified month. Instead of next month from the previous example, we use first day of next month here:

modify( 'first day of next month' );
echo $d->format( 'F' ), "\n";
?>

This script will correctly output February. The following things happen when PHP processes this first day of next month stanza:

• next month increases the month number (originally 1) by one. This makes the date 2010-02-31.

• first day of sets the day number to 1, resulting in the date 2010-02-01.

• The formatting strips off the year and day, resulting in the output February.

Besides first day of, there is an equivalent last day of to go to the last day of a month. The following example demonstrates this:

modify( 'last day of next month' );
echo $d->format( 'F jS, Y' ), "\n";
?>

This outputs February 28th, 2010. Internally the following happens:

• next month increases the month number (originally 1) by one. This makes the date 2010-02-08.

• last day of increases the month number by one, and sets the day number to 0, resulting in the date 2010-03-00.

• PHP then auto-corrects the invalid day number 0 by removing one from the month and skipping to the last day of that month, resulting in 2010-02-28.

I hope this clears up some of the behaviour of PHP's Date/Time handling. For more information on Date/Time Programming with PHP, please refer to my book "php|architect's Guide to Date and Time Programming" that is available through Amazon.

It has been two years since I released Xdebug 2.0.0. Since then I've added many new features to Xdebug. For some of those new features you can find a little description below—I will write more about these, and other features later.

Besides the features, I also fixed a whole array of bugs and Xdebug 2.1.0 comes with PHP 5.3 support. From now on I will not be supporting any PHP versions less than PHP 5.1 anymore. But now on to the descriptions:

Header Setting Interception

All functions that set HTTP headers such as with header() and setcookie() are now intercepted by Xdebug. The intercepted headers are stored internally in an array that can be retrieved by calling the xdebug_get_headers() function. This is very useful in cases where you need to test certain functionality that sets headers somewhere deep in code. This function is also used in eZ Components' test suite to test whether the correct HTTP headers are set in the MvcTools component.

Variable Assignment Tracing

Allows you to record changes to variables in scripts to trace files. I've already written more about it in Variable tracing with Xdebug.

"Scream" Support

The scream PECL extension disables the @ (shut-up) operator to actually see all notices, warnings and errors that PHP generates. The scream extension's functionality have been duplicated as Xdebug's xdebug.scream php.ini setting. Why disabling the @-operator is a good thing, I've already outlined in Five reasons why the shut-op operator (@) should be avoided.

What's Next?

There are still a few bugs left that need some attention, but this first beta should have most of them fixed. Please test the beta as much as you can and provide feedback in the issue tracker. After this initial beta it is like that one more more betas will follow before I prepare a release candidate. Xdebug 2.1.0beta1 can be obtained through the Xdebug website and a full changelog is also available. You can also follow Xdebug on twitter to be kept up-to-date with the latest developments.

When moving the Xdebug website and my own website to a new server I had to pick a web server to serve the pages through PHP. Up to then I was still using Apache 1.3 with zero intentions to ever upgrade to any later version. I'd heard a lot about lighttpd and decided to give that a try—yes, that meant something that I didn't really know to well was going to run in a production environment. Unlike Apache, with lighttpd PHP doesn't run as a module, but instead you run it out of process with something called FastCGI.

On my development machine I was also running Apache 1.3 with PHP as static module embedded. If I want to test something with a different PHP version, I would start a different Apache daemon. When I had a quick look the other day, I found that I had about 28 different binaries named httpd-{Apache version}-{PHP version} ranging from PHP 4.1.2 to 6.0dev. Some of those I hadn't used for years.

All my PHP installations were installed with the same prefix (/usr/local) where the last built PHP version was available as php and additional versions as php-{version}. An annoyance with this is, is that I had to run make install in one of the PHP source directories before I could compile extensions against a different PHP version than the latest installed one. This combined with the enormous amount of httpds and the inability to run multiple versions of PHP at the same time prompted me to come up with something better: PHP Development Environment 2.0.

Multiple PHP Installations

The first thing I wanted to do was to make sure that each minor PHP version (5.1.x, 5.2.x, 5.3.x and 6.0.x) could be installed alongside each other, and that I could compile extensions to all of them without having to re-run make install. I did this by specifying --prefix=/usr/local/php/{PHP version} to the PHP configure call. At the same time, I also removed the --with-apache configure option and for PHP 5.1 and PHP 5.2 I added the --enable-fastcgi option which is default enabled for PHP 5.3 and PHP 6.0. The initial section of the configure invocation now looks like for the PHP 5.2 build:

./configure --prefix=/usr/local/php/5.2dev --enable-fastcgi \
  --with-gd  ...more configure options here...

Although /usr/local/bin is usually in the path, but /usr/local/php/5.2dev/bin is definitely not. The initial goal was to be able to easily switch between different PHP versions, so I added a snippet to my .bashrc that sets the correct PATH environment variable depending on the selected PHP version:

function pe () {
  version=$1
  shift

  if [ "$#" == "0" ]; then
    export PATH=/usr/local/php/${version}/bin:/usr/local/bin:/usr/bin:/bin
  else
    PATH=/usr/local/php/${version}/bin:$PATH $@
  fi
}

This bash function is then evoked like pe 5.3dev to set the path in such a way that php runs the PHP 5.3 binary, as well as additional tools such as pear, phpize (required to build extensions) and php-config. If you forget to call the pe function, then when running php you will encounter the warning bash: php: command not found. You could pick a default version if you wanted, but I prefer that I always have to be explicit about which PHP version I pick. Multiple install paths makes it easier to maintain multiple PHP installs, but it also means that you have to install tools such as PHP Unit for each of the installations.

Setting up Lighttpd

Now that I had multiple PHP installations, I could move on to setting up lighttpd. As I have mentioned, I never used lighttpd before and decided to take the easy way by installing it with apt-get install lighttpd. PHP works through the FastCGI interface with lighttpd which you can enable with lighttpd-enable-mod cgi fastcgi simple-vhost (I also enabled CGI and simple VHOSTing).

To enable PHP as FastCGI server, and to be able to run multiple versions at the same time, I modified the /etc/lighttpd/conf-enabled/10-fastcgi.conf configuration file. Find my annotated version below:

## Enable the FastCGI module.
server.modules   += ( "mod_fastcgi" )

Next we start an FastCGI server for the default PHP version (5.3) on the default port (80) by enabling it in the global scope:

fastcgi.server    = ( ".php" =>
  ((
    ## The path to the PHP-CGI executable
    "bin-path" => "/usr/local/php/5.3dev/bin/php-cgi",

    ## The listening socket that allows lighttpd to talk
    ## to the PHP FastCGI process. This needs to be
    ## different for each fastcgi.server definition.
    "socket" => "/tmp/php80.socket",

    ## Configure the number of parent processes that are
    ## spawned by lighttpd (max-procs) and configure how
    ## many many workers should be started (4) and the
    ## maximum number of requests that they can process
    ## before they get recycled (10000).
    "max-procs" => 1,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),

    ## configure additional bits
    "bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),
    "broken-scriptfilename" => "enable"
    "idle-timeout" => 20,
  ))
)

Now tell lighttpd to also listen on port 8502. And in case requests come in over this port, use the defined FastCGI server for *.php. In this case we configure PHP 5.2. Similarily you can also define a block for PHP 5.1 (on a suggested port 8501) and PHP 6.0:

$SERVER["socket"] == ":8502" {
  fastcgi.server    = ( ".php" =>
    ((
      "bin-path" => "/usr/local/php/5.2dev/bin/php-cgi",
      "socket" => "/tmp/php8052.socket",
      "max-procs" => 1,
      "idle-timeout" => 20,
      "bin-environment" => (
        "PHP_FCGI_CHILDREN" => "4",
        "PHP_FCGI_MAX_REQUESTS" => "10000"
      ),
      "bin-copy-environment" => (
        "PATH", "SHELL", "USER"
      ),
      "broken-scriptfilename" => "enable"
    ))
  )
}

Tell lighttpd to also listen on port 8502. Because we're not overriding the fastcgi.server configuration from the global configuration (the bit were we set-up PHP 5.3 in the first few lines of the file), it will reuse this fastcgi.server configuration enabling requests for .php files coming in on port 80 or 8503 to be processed by the globally configured FastCGI server:

$SERVER["socket"] == ":8503" {
# Just some dummy text because lighttpd doesn't allow
# empty definitions.
}

With the configuration made, you only have to restart lighttpd with /etc/init.d/lighttpd force-reload and PHP is ready to go on multiple ports with different PHP versions.

Just like Xdebug's server was moved1 to a new VPN at XtraHosting so did my personal website (the one you're looking at). Hosting it on my own gives me full control over what software runs it, and which PHP version and extensions I run. I switched most of the code from a PHP 4.1 atrocity to PHP 5.3 goodness.

At the same time, I also moved all the contents from some self-invented XML format to reStructuredText. reStructuredText is a format that can be parsed and transformed into other formats by eZ Components' Document component. Right now I am transforming to HTML only, but in the future I will also transform certain articles to PDFs. Comments can also make use of some of the reStructuredText formatting options, but there are still some things that need sorting out there.

Besides changing the layout and converting the content to a more manageable format, I also introduced a stream of dopplr, flickr and twitter updates on the right side. This is implemented by parsing the relative RSS feeds from the different sources. If location information is present, this is also shown in this feed. Previously I would only export an RSS feed for all of the content, but with this site update, there is now a feed for every tag that I've used. All RSS functionality is provided by the Feed component of eZ Components (although a patch is currently needed for the location information).

I'm not a 100% happy with the new layout, so most likely I will be doing some changes in the near future.