In this new post to the Laravel News site they list out some of the deprecations coming in PHP 7.2 based on this RFC.

The PHP 7.2 RFC for deprecating some current functionality has been approved. The following items are included in this list and will begin throwing deprecated notices.

The list of features to be deprecated includes:

• the magic __autoload function
• the create_function function
• the (unset) cast
• the each function

Most of the things in the list are functionality that you just don't see much in recent PHP development. It could cause problems for older codebases but for those already on PHp 7 it shouldn't take much to make the necessary changes.

The Symfony blog has posted a quick guide with a tip to upgrading to Twig 2.0 made simpler thanks to some built-in deprecation notices.

As Twig 2.0 is approaching fast now, it's time to focus on how to boost adoption of this new major version. [...] Also, the good news is that most of the time, it's possible to make your code work for both major versions (that's important for shared code like bundles). [...] How to make it easy? Like for Symfony, I've now added deprecation notices throughout the code to give Twig users an easy way to upgrade their code (this is available in the upcoming Twig 1.21 version).

The release of v1.21 comes with the deprecation notices already built-in making it easy to find the issues before making the jump up to v2.0. He also includes mentions of two other things included to make it easier: a deprecation collector to gather the issues in one place and a visitor base class diff that can make them compatible with both versions (1.21 and pre-1.21).

On PHPMaster.com there's a new article that suggests that suppressing notices thrown from your code is a bad practice to get into, both through error reporting and the use of the suppression operator, "@".

The PHP notice suppression operator is somewhat of a controversial topic in many circles. Some overuse it, some don’t use it at all, and some don’t even know it exists. Apologies in advance for the horrible code you’re about to witness in this article, but it serves a purpose to illustrate the usefulness (or lack thereof) of the suppression operator.

He talks about some of the common notices and how the suppression operator prevents the "Notice" message that could come out of it. They suggest, however, that there's never a good time to use the operator, especially during development. Obviously, there are a few cases (they point out one with mail) where it could be useful. There's also some sample code for a custom error handler you can use to capture the issues that might come up.

In this quick new post to his blog Mark Story talks about two new errors he ran across when upgrading his installation to PHP 5.4, both showing up under E_ALL.

I’ve been running the PHP5.4 RC builds for the last few months, and there are some interesting changes in the upcoming PHP release. On top of all the great new features coming in PHP5.4. After updating to PHP5.4-RC4, a few things that used to not trigger errors and silently do the wrong thing, now trigger notices or warnings.

The two he mentions deal with a new warning on illegal string offsets and the other about string offsets ("Notice: String offset cast occurred"). You can find out about more changes in the PHP 5.4 series in the various Changelogs for each Release Candidate and beta release.

If you've ever been bothered by those pesky NOTICEs when running your code, you know that you can wrap evaluations or check things with an empty or isset call to make them go away. Brandon Savage has a new post that can help you decide which one to use when, though.

As developers, we want to develop code that never emits notices or warnings, and PHP gets a bit antsy when we develop code that utilizes uninitialized variables. Lucky for us, PHP makes it easy to test for these variables without getting these notices. [...] PHP (like most languages) evaluates a logical argument left to right. For an AND condition, both conditions have to be true; PHP stops evaluating if it finds any condition untrue.

He suggests that the case to use isset() is more when you just want to use another check in the conditional but don't want to be bothered if the variable isn't there. A call to empty(), however, also evaluates the contents of the variable if it exists. Be careful, though - empty() returns false if the value of the variable is false - so take care in your use and always test scripts with multiple values.

Brandon Savage has posted the next article in his "Scaling Up" series, a look at reducing the amount of "drag" your application makes through its processing path and some tips to help increase its "lift" out of some common problems.

The intuitive will note that many if not most of these suggestions are performance enhancements, not scaling techniques. Why then are they in an series about scaling? Scaling is about more than just adding hardware. It’s also about making sure your system runs better. You can add lots and lots of hardware but you will someday be unable to compensate for bad queries and poor optimization.

Some of his suggestions include taking care of any sort of errors or notices (anything that could slow the script down by writing to a log), defining virtual hosts instead of making excessive use of .htaccess files and installing caching software to maximize code and information reuse.

On PHPFreaks.com there's a new tutorial providing a beginner's guide to debugging in PHP (with the built in functionality PHP has, not external software).

Everyday the forums see probably hundreds of topics posted where the problem is a fairly simple error. [...] As a beginner, it can be difficult to find and solve these errors. By tackling each of these in turn, I hope to teach you some methods of finding and solving them.

They look at the different sorts of errors - syntax errors, fatal errors, warnings, notices - as well as some of the ones a bit harder to track down like database problems and logical errors.

Greg Beaver points out an obscure problem he came across when working with the new _HALT_COMPILER token in PHP 5:

A quick note about an obscure problem peculiar to PHP files that make use of PHP 5's new __HALT_COMPILER(); token. Prior to PHP 5.2.2, if you included two files that contained the __HALT_COMPILER(); token, you would get a notice that __COMPILER_HALT_OFFSET__ was already defined.

This posed a problem for him as he needed it to throw this error for the phar library format. His solution? To patch his installation (PHP5, the PHP6 patch is here) to make the problem a non-issue.

Greg Beaver points out an obscure problem he came across when working with the new _HALT_COMPILER token in PHP 5:

A quick note about an obscure problem peculiar to PHP files that make use of PHP 5's new __HALT_COMPILER(); token. Prior to PHP 5.2.2, if you included two files that contained the __HALT_COMPILER(); token, you would get a notice that __COMPILER_HALT_OFFSET__ was already defined.

This posed a problem for him as he needed it to throw this error for the phar library format. His solution? To patch his installation (PHP5, the PHP6 patch is here) to make the problem a non-issue.

Ivo Jansch discovered something interesting by way of an applicant's resume - a hidden "trick" that PHP pulls on the user when they try to use a Java-like syntax with System.

So yesterday I was reviewing a code sample that a job applicant had written during a test and I encountered the following line of code: It's not hard to guess what his background was :), but I was initially stunned that this actually works in php.

After a little investigating (and ruling out the Java Bridge), Ivo found that the line was being interpreted literally and was just being handled as a string instead of a constant. He gives two other examples to help with clarification.