On the SitePoint PHP blog they've posted a tutorial from author Tonino Jankov sharing some techniques you can use to increase the performance of Apache and Nginx when serving up your web applications.

The article starts with some of the basics, introducing both the software and some of the concepts around their use and evaluation:

• an introduction to Apache and Nginx
• hardware considerations
• monitoring
• testing the systems (benchmarking)

It then starts on the tuning tips, one section for each of the web servers. For Apache it covers changes for the mpm modules, disabling htaccess and browser cache control with mod_expires. On the Nginx side, they mention changing the number of workers created, tuning the keepalive timout and setting up server-side caching.

PHPStorm users out there might want to check out this list of helpful hints from the Stitcher.io blog covering some "lesser-known-yet-powerful features" of the IDE that could help improve your daily workflow.

Their list includes:

• binding keys to pane display preferences (ex: floating, windowed, etc)
• namespace auto-importing
• "copy path" of the current file
• defining custom JVM options
• inspection of why a term/word is syntax highlighted

Each of the items on the list comes with a description of where to make changes and animated GIFs of where to find it in the interface and what it looks like. If you're not a PHPStorm user and want to find out more about this IDE offered by JetBrains, check out this page on their website.

The Laravel News site has a quick post today with a helpful hint for those trying to track down exactly what queries their Laravel application is performing on database calls. In this post they show two ways to get this information - one using the Debugbar and the other with a quick script.

When you are building an application and utilizing Eloquent it’s very easy to hit the N+1 problem. This is where you select a model and then later use lazy loading to fetch child records.

They give an example of selecting a user, grabbing it's list of "posts" and then looping through them causing queries to fire for each post individually. A fix for it is using the "with" method to pre-load them but determining this could be tricky. Enter their two solutions: the Laravel Debugbar package and this quick script shared by magkopian that listens for a "kernel.handled" event and outputs the results of the "getQueryLog" method with the Laravel "dd" helper.

In a new post to his site Aaron Saray has shared two tips that can help you protect the information in your PHP sessions - two configuration options to enable that can enforce stricter standards and options enhancing their overall security.

Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.

The two configuration options he mentions are ones that:

• force the session identifier to use cookies (versus also allowing it from the URL)
• enforce "strict mode" on the sessions

Each comes with a bit of description as to what the setting does and the recommended setting is to provide the most protection. One note, though: strict mode is only included in PHP 5.5.2 or greater.

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.

Lorna Mitchell has shared a tip she's found helpful when using the phan static analysis tool for finding only PHP files via a simple grep.

Phan is the PHP Analyzer for PHP 7 code. I've been using it, partly out of curiosity, and partly to look at what the implications of upgrading my various projects will be. [...] I generated my filelist.txt files with a little help from grep - by looking for all files with opening PHP tags in, and putting that list of filenames into a file.

The phan tool is still pretty young but it provides a good example of how to use the new php-ast handling to parse and analyze PHP code.

Scott Keck-Warren has a quick post to his site sharing a method for keeping data providers maintainable in your unit tests. Data providers are a quick way to retest the same logic with several different types of data and not have an individual test for each.

I’m a big fan of using PHPUnit’s data providers feature because it allows you to easily run a lot of data through the same kinds of tests over and over again without having a bunch of duplicate code sitting around. But they aren’t always the easiest thing to come back to an understand.

He briefly introduces how data providers are used in PHPUnit testing, including a brief code example. The errors that can come up with this common setup can be cryptic to debug. He recommends a slight alteration to the data provider return structure to use an associative array instead of a single-level array. This way, if there's an error the resulting message refers to the index, not just a number making a bit more sense and aids in debugging.

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.

Rob Allen has a quick tip posted today about SSL certificate verification in PHP 5.6 and things that need to be updated thanks to recent improvements in PHP's SSL handling.

I recently updated my local OS X Zend Server installation to PHP 5.6 and when I ran composer self-update, I got this error message: "The "https://getcomposer.org/version" file could not be downloaded: SSL operation failed" [...] Googling around, I finally worked out that there have been various SSL improvements in PHP 5.6 and that the problem was that it couldn't find any OpenSSL certificates on my system. This isn't a total surprise as OS X has been moving away from using OpenSSL internally in favour of its own libraries.

To resolve the issue he found where PHP was looking for certificates (using openssl_get_cert_locations) and how a quick "brew install" of the needed OpenSSL handling resolved the issue. Then, in the php.ini file a quick update to the "openssl.cafile" path points it to the right certificate.

Matthew Weier O'Phinney has posted the last part of his "Deployment with Zend Server" series with part eight. This part focuses on some hints around the actual deployment and automation.

This is the final in a series of eight posts detailing tips on deploying to Zend Server. Zend Server SDK to deploy your Zend Server deployment packages (ZPKs) from the command line. Today, I'll detail how I automate deployment with zf-deploy and zs-client (the Zend Server SDK), and wrap up the series with some closing thoughts.

He quickly summarizes the previous parts of the series as individual steps and wonders if there's a better way than doing each of them manually. He shows exactly this with the automation handling that zf-deploy and zs-client offer combined with a make script defining steps for the deploy, ZPK update and a cleanup/Composer update task.