Adam Wathan has shared a new post on his site with advice on finding out-of-date mocks when using the Mockery mocking tool in your testing.

If you're not careful, it's easy to find yourself in a situation where a test double has gotten out of sync with the actual class or interface it's mocking.

In this quick screencast (taken from my Test-Driven Laravel course), I walk through how I use a little-known Mockery feature to help track down these issues and make sure I'm not mocking methods that don't exist.

The quick screencast (about 4 minutes) gives an example of locating the issue when a "Ticket" class is refactored. While the tests still pass, it can cause issues in testing and can be difficult to find. Mockery comes with a configuration option (in 1.0 alpha) to disable the mocking of methods that don't exist on the original object. He shows how to disable this feature and what the resulting error looks like when the tests are run.

In this post to his site Paul Jones makes some suggestions about how to handle session cookies (PHP's default session handling mechanism) and requests/responses using the PSR-7 structure.

One of the great things about PHP is its session handling capabilities. One call to session_start() and a huge amount of heavy lifting is done for you. It’s a great aid when writing page scripts.

However, as you start to need finer control over the HTTP response in your project, some of the automatic session behaviors begin to get in the way. In particular, when you are using PSR-7 to build your HTTP response, you realize that session_start() and session_regenerate_id() both automatically do the equivalent of calling setcookie() to write headers directly to the output. This means you cannot buffer those calls into the Response object for later sending.

How then can we use PHP’s session handling, when we want finer control over when and how cookies get sent?

He suggests that you do two things. First, disable PHP itself from automatically sending the cookie via some ini_set calls. The second is to do the session ID comparison manually and perform the related action (either allowing or sending a new ID on failure). He includes example code showing it in action and also mentions some of the shortcomings of the approach around cache and limiter headers.

In a recent post to his site Jeff Geerling shows you how to disable the output buffering that PHP includes and create "streaming PHP" code similar to Drupal's recently introduced BigPipe handling.

For the past few days, I've been diving deep into testing Drupal 8's experimental new BigPipe feature, which allows Drupal page requests for authenticated users to be streamed and loaded in stages—cached elements (usually the majority of a page) are loaded almost immediately, meaning the end user can interact with the main elements on the page very quickly, then other uncacheable elements are loaded in as Drupal is able to render them.

[...] BigPipe takes advantage of streaming PHP responses (using flush() to flush the output buffer at various times during a page load), but to ensure the stream is delivered all the way from PHP through to the client, you need to make sure your entire webserver and proxying stack streams the request directly, with no buffering.

He decided to try out different configurations to see if he could reproduce the same thing outside of Drupal and - good news, everyone - he found a reliable way. He starts with a basic procedural script that emulates BigPipe and calls a flush inside a loop to push the latest output to the waiting client. While this cooperates on the command line the browser doesn't cooperate the same way. A small tweak helps it work, so he shows how to reproduce this reliably across the full stack - Nginx, Apache and Varnish.

He ends with a quick warning for those using VMWare/VirtualBox about some oddness he experienced in buffering the responses and includes a way to test if it's your script or the VM causing the trouble.

On the Zend Developer Zone they've posted the fourth part in their series of tips around using the Z-Ray profiling tool in your PHP applications. In this fourth tip they show you how to "get rid of it" in certain parts of your application.

Well, while Z-Ray is a great friend to have when developing your apps, there are just some parties you don’t want it to show up at. You might be using PHP scripts for accessing static pages. Or, you might not want Z-Ray to be displayed for one specific request. In production, you most definitely don’t want Z-Ray popping up for users using your app!

There are numerous ways to disable Z-Ray both in development and in production to make sure your development workflow is not interrupted and your live apps are not affected. Here are a few of them.

They include a few different ways to disable the tool including the use of a function call in the code (zray_disable), using a header in the HTTP request and, naturally, from the Z-Ray toolbar itself. They also talk about setting it up to be removed for production in one of two modes, either selective (only showing for certain requests) and completely disabled.

Joshua Thijssen has a quick new post today talking about debugging Symfony components, sharing a simple but useful hint.

Don’t you hate it when you are stepping through your debugger during a Symfony application debug session, and all of a sudden it cannot find files anymore as Symfony uses code located in the bootstrap.php.cache instead of the actual Symfony component. Symfony creates these cache-classes in order to speed up execution, but it makes that xdebug cannot find the correct code to step through anymore.

He found a solution in a few changes to his "app_dev.php" bootstrap file to alter the location of the autoloader and disable cache loading. This prevents issues with Symfony trying to access cached versions and use the actual files and locations, making debuggers much more happy.

In his latest post Anthony Ferrara looks at a recent change in the Composer dependency management tool involving a major speed boost, just from disabling the garbage collection.

If you've been following the news, you'll have noticed that yesterday Composer got a bit of a speed boost. And by "bit of a speed boost", we're talking between 50% and 90% speed increase depending on the complexity of the dependencies. But how did the fix work? And should you make the same sort of change to your projects? For those of you who want the TL/DR answer: the answer is no you shouldn't.

He talks about what the actual (one line) change was that sped things up but goes on to talk about why doing this isn't necessarily a good thing. He covers how PHP handles variables internally, how it relates to "pointers" and the copy-on-write functionality. He includes code snippets and gives an overview of how each would be handled by the interpreter. Unfortunately, the way PHP handles things, deleting a variable only removes variable reference, not the value, but does decrement the reference count for it. When that hits 0, garbage collection kicks in and removes associated values too.

He talks about a few other kinds of garbage collection (the reference count method is just one of them) and circles back around to how this relates to Composer's functionality. He points out the number of objects created during the dependency resolution process and what can happen when the root buffer, populated with all of these objects, gets too full (hint: garbage collection). He finishes the post talking about how, in Composer's case, the garbage collection change yielded the performance impact it did, but doesn't suggest it for every project. He also makes a few suggestions as to things that could be done to improve PHP's garbage collection handling.

If you're relatively new to the PHP world, you may be wondering why there has been so much emphasis put on "magic quotes" in the language's past. If you're not entirely sure what they are (and why to avoid them) take a look at this quick overview from XpertDeveloper.com.

First of let me say that Magic Quotes is deprected from the PHP 5.3 and will be removed completely from the PHP 6. But as a developer you might face a situation when you have to work on application which runs on older version of PHP with some older functionality like rely on Magic Quotes.

They introduce the simple concept behind the magic quotes idea and, thankfully, the settings and code you can use to turn it off. It's been deprecated in PHP 5.3 but some older versions came with it enabled. If you're currently running with it on, it's highly recommended to turn it off and refactor your code accordingly.

As Ruslan Yakushev points out in this new blog entry, the same security issue that's effecting ASP.NET pages running on IIS web servers can still open up PHP scripts running on the same server.

Microsoft has recently released a Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET. The PHP applications running on IIS are also subject to this vulnerability if ASP.NET is enabled in IIS.

The issue allows attackers to access the contents of various files on the server and could allow them to tamper with the data inside. Ruslan notes that, while Microsoft is coming up with a fix, one of the safest things you can do is either completely disable ASP.NET in the IIS server or use this workaround.

As Sameer Borate points out in his latest post to his blog, there's a way to disable that pesky suppression operator (@) in your PHP installation thanks to the scream extension.

PHP supports one error control operator: the at sign (@). When prepended to an expression any error generated by that expression will be ignored. It can also be useful for hiding errors generated by various functions. [...] Although quite useful at some times, using the @-operator can have some annoying side effects.

He shows you how to install the extension on a stock Ubuntu platform (including the PHP packages) and how use the feature in your application by means of a call to ini_set (or, of course, setting it in your php.ini file).

Derick Rethans has a few choice words for those developing PHP packages for linux distributions out there - don't cripple PHP. His example deals specifically with RedHat and their choices on timezone management.

Red Hat thought it'd be wise to create a patch to use the system provided timezone database instead. We (the PHP development team) thought that to be a bad idea because of several reasons. Among them is that it removes control from PHP's users about which database is, decreased performance, and some missing functionality

He mentions other problems - other issues related to timezone support - that caused them to not accept RedHat's patch to try to "fix" things by disabling the bundled timezone database. He looks at why this is such a bad thing, why it can cause trouble with PHP's date handling and what the future holds for this database support (hint: PHP 5.3 will shake things up).