PlanetPHP

I had a problem with running test cases on multiple CI environments, where one of the two runs on PHP 5.2 and the other on PHP 5.3. This basically meant that all our pretty PHP 5.3 code caused the builds to fail on the 5.2 only machine. To solve this problem I needed a way to skip tests when the PHP version was less then 5.3.0. Besides the reason I needed this for a -less then ideal- setup. This can also be a generic way to skip certain tests, based on a PHP version.

You can also use the cool @depends annotation of PHPUnit and put the version logic in a test. This has my preference, but it's not always possible. In case you have some code that simply can't be parsed by the older PHP engines.

If you know a better way to do this, please share!

Introduction

This is a blog about running two PHP versions on one webserver and using multiple php.ini files, this combination can be a tricky one to tackle. But luckily one we can tackle quite easily as long as one of the PHP versions is >= 5.2.7. For this example I'll be using Apache, but the webserver flavor doesn't really matter. The most important part is the "PHP_INI_SCAN_DIR" environment variable.

The why

There could be a number of reasons to want what I'm about to talk about. In my case I have a project where I have a legacy code-base, running on a specific PHP version, and a new code-base which will be run on 5.3. Because the new code-base will be a ongoing progress of replacing the old, it first has to run side by side with the legacy code-base. So I wanted my development image to run two PHP versions.

The old code-base used php.ini settings such as a include-path, error reporting, etc.  Which will be different from the new code-bas, and those can no-longer be set with the 'php_value' feature of Apaches since the PHP version we'll be using for that runs as (f)CGI rather then as module.

Welcome to another part of the PHP Quiz series, again some interesting questions to crack your brain about. If you have some nice additions or questions, be sure to leave a comment. Enjoy part three!

As always, think of the answer before you execute the code or look it up. You can find round two here.

Unset cast

What is the type of $a and what is the type of $b

Form fun

What will the output be?

Fun with strings

Strings in PHP are versatile, but how versatile are they... What will the output be?

In these blog series I'd like to talk a bit about some "Did you knows". These series contain information I came across along the way and I mention them here to give you insight or just to make you aware of it's existence. The information is by no means in chronological order and mostly not even covering "state of the art" or "brand new" items for that matter. Some are directly code related, others are just brief descriptions. Basically it's just a pile of PHP and web related information. You can find part one here.

A short quiz this time, but that doesn't make it less fun. Do you know the answer to all of them? Get a cup of coffee and kill 10 minutes with round two...

As always, think of the answer before you execute the code or look it up. You can find round one here.

Array pointer

What will the output be ?

ArrayAccess and isset fun

isset or not isset, thats the question.

Typo?

The output might be confusing..

References

How many notices will be thrown?

In this blog post I'd like to talk a bit about some "Did you know's". With these "Did you know" blog posts I want to tell you a few things that I came across along the way and hopefully you know some I don't know yet! Some DYK's are directly code related, others are just here to give you insight and some are just to let you know of it's existence (Afteral you don't search for what you don't know about.)

So here they come in random/chaotic order:

Writable directories

Not so PHP specific, but often miss-used is checking for writable directories/paths. Directories don't have to be readable to be used for writing, but they do have to be writable and executable.

So a check like this, is simply incomplete:

Form name attribute character conversions

Due to legacy PHP versions and to my understanding mostly due the register_globals feature, some HTML form name attribute characters are translated. The idea behind it makes sense, however it's applied in a strange way.

For example <input type="text" name="fu.bar" value="" > in a form with post method, get's translated (even in the current PHP 6 roadmap) into: $_POST['fu_bar']. This happens with the "." and " " characters. But not with '-'  which seems weird, because $fu-bar isn't a valid variable, but '-' is a valid HTML input name attribute character. You probably never need it, but I had situation recently where I was flabbergasted of why array key's where different from their HTML counterparts and I completely forgot about this behavior.

Best practices are ways of solving problems in a good way, these practices change over time and can depend on versions. A lot of people who have their roots in PHP4 have habits that are no longer best practices. But not just them, a lot of developers don't apply best-practices rules. In this blog post I'd like to point out a few reminders or refreshing points for you to take in. Most you will probably know but some you might not know or didn't look for. If you know some nice additions, make a comment and I'll add it.

Enjoy!

Since I'm on a 'finish blog drafts' spree, I might as well publish this one also. I actually had it in draft for about 5 months now anyway.

In most upload tools files are checked on extensions only, while it might seem pretty solid it's actually not as safe as you might think. Especially in combination with Apache and mod_mime.

When you do:
rename image.jpg image.txt and you request it: domain.com/image.txt you get garbled text.

However when you try something like this:
rename file.php file.php.bogus and you request it: domain.com/file.php.bogus PHP code within the file is handled by the handler set for that extension.

Before you get all excited, the scenario when this happens is not likely to happen, because it only works for unknown file extensions. So basically, this can only happen when you work with black-listing rather then white-listing. And when checking files, you shouldn't be black-listing in the first place. Let's go into detail about the why.

Simple things of PHP can be just as fun as the advanced things in PHP!
To prove that I wanted to make a small quiz, and here it is.

Below you'll see 10 pieces of PHP5 code, the goal is to figure out the code and know the output before you actually run it.
Have fun!

Comment and closing tag

<?php // Without cheating.. What will you see when you run this single line of ?\?> php code

Echo print and get what

<?php
  // What do you expect from this ?
  echo print( 1 ); ?>

What wil eval to true

 <?php
  // How many times will we get 'true' ?

  $boolean  = false;
  echo ($boolean) ? 'true' : 'false';

  $boolean  = '0';
  echo ($boolean) ? 'true' : 'false';

  $boolean  = '00';
  echo ($boolean) ? 'true' : 'false';