PHP | Today I Learned

You can pass more than a single variable to PHP's isset(). From the docs:

If multiple parameters are supplied then isset() will return true only if all of the parameters are considered set. Evaluation goes from left to right and stops as soon as an unset variable is encountered.

In PHP, you can embed a variable into a string in these two ways:

$a = 'b';

echo "1: $a"; // outputs "1: b"

echo "2: {$a}"; // outputs "2: b"

However, you can also embed it in this arguably-more-confusing way:

echo "3: ${a}"; // outputs "3: b", but why!?

And, moreover:

$b = 'c';

echo "4: ${$a}"; // outputs "4: c". This is insanity.

Luckily, these two cases are being deprecated and going away in PHP 9.

PHP will (as of version 8) happily send a 200 response when there's a fatal error like, for example, a syntax error on an autoloaded class, even if you define an error handler using set_error_handler that will output a different HTTP status code.

The problem is, set_error_handler doesn't work on all error types. A workaround is adding a shutdown function using register_shutdown_function that checks the last error's type.

A null (zero) character will confuse PHP's password_* functions, when using bcrypt encryption (which is the default), so it's probably safe to just refuse any password with this character.

Trying to use undefined properties in PHP stdClass objects gives you a "warning" as of PHP 8 (it used to be a "notice" that, being realistic, you ignored).

One way to fix code that looks like the following is to use the new "null coalescing" operator (??):

$a = new stdClass;

$a->first = 1;

// This will give you a warning

$b = array($a->first, $a->second ?: NULL);

// This is fine

$c = array($a->first, $a->second ?? NULL);

When a development team is working on a PHP project that uses Composer with Git, it often happens that there are conflicts on the composer.lock file, on the "content hash" line.

To solve this, Composer provides a way to update the lock file from the packages currently installed, including the content hash value: composer update --lock. This does not try to update every package to the latest versions (as composer update would do).

An unclosed PHP output buffer can cause PHPUnit tests to be marked as "risky". This is not documented, but clear in the source code.

PHP supports the "data: stream wrapper" natively, so you don't have to do ugly string manipulation to get, for example, the data from a string such as data://text/plain;base64,SSBsb3ZlIFBIUAo=. Instead, you can do this:

$string = 'data://text/plain;base64,SSBsb3ZlIFBIUAo=';

$source = fopen($string, 'r');

$destination = fopen('myfile.txt', 'w');

stream_copy_to_stream($source, $destination);

fclose($source);

fclose($destination);

Apparently, PHP can work just fine without loading a php.ini configuration file. I have no idea where it gets its default configuration from (for example, a value of 128M for memory_limit), but luckily phpinfo() will tell you where it's looking for a php.ini (search for "Configuration File" in its output), so you can just add the file in that path and it will get picked up.

There's a simple algorithm that uses the Bayes theorem that can be used to classify documents, using their text tokenized into individual words, into categories (e.g. tags on a website). The classifier needs to be trained with existing data, and then it will return which categories a new document probably belongs to.