The SitePoint PHP blog has another tutorial posted from author Christopher Pitt looking at writing async libraries with PHP. In this particular article he focuses on just one of many tasks an asynchronous library could perform: converting HTML to PDF documents.

I can barely remember a conference where the topic of asynchronous PHP wasn’t discussed. I am pleased that it’s so frequently spoken about these days. There’s a secret these speakers aren’t telling, though: "Making asynchronous servers, resolving domain names, interacting with file systems: these are the easy things. Making your own asynchronous libraries is hard. And it’s where you spend most of your time!"

The reason those easy things are easy is because they were the proof of concept – to make async PHP competitive with NodeJS. [...] Today, we’re going to look at a few ways to make your application code work well in an asynchronous architecture. Fret not – your code can still work in a synchronous architecture, so you don’t have to give anything up to learn this new skill. Apart from a bit of time…

He starts with some theory about things in the async world including callbacks, promises and what they might look like in PHP-land. He then starts in on the creation of the PDF files, creating a "Driver" class to handle some of the logic and using the Dompdf library to do the heavy lifting (the conversion from HTML to PDF). He walks through the code required for this class then moves on to the code, using the Amp project, to handle the async operations. He then creates a simple set of web accessible endpoints that call the Driver class with some basic attributes and performing the conversion. He ends the post talking about porting the parallel driver to other systems (such as ReactPHP) and a few simple steps if you need to move back to the synchronous world.

On the Nginx.com site they've posted the first part of a series showing you how to maximize your performance with PHP 7 and this already speedy web server.

PHP is the most popular way to create a server-side Web application, with roughly 80% market share. (ASP.net is a distant second, and Java an even more distant third.) [...] Now the PHP team is releasing a new version, PHP 7 – more than a decade after the introduction of PHP 5. During this time, usage of the web and the demands on websites have both increased exponentially.

[...] This blog post is the first in a two-part series about maximizing the performance of your websites that use PHP 7. Here we focus on upgrading to PHP 7, implementing open source NGINX or NGINX Plus as your web server software, rewriting URLs (necessary for requests to be handled properly), caching static files, and caching dynamic files (also called application caching or microcaching).

They start by looking at why "PHP hits a wall" in its execution in high load situations, stepping through the process it follows to handle each request. They also share some of the common ways PHP developers have combatted these issues including more hardware, better server software and multi-server setups. They then get into the actual tips themselves:

• Tip 1. Upgrade to PHP 7
• Tip 2. Choose Open Source NGINX or NGINX Plus
• Tip 3. Convert Apache Configuration to NGINX Syntax
• Tip 4. Implement Static File Caching
• Tip 5. Implement Microcaching

For each tip there's a summary with more information on why they make the suggestion and, for some, how to make the transition happen. In the next part of the series they'll get into reverse proxy servers and a multi-server Nginx implementation to boost performance even more.

Joseph Scott has a new post to his blog looking at "why PHP strings equal zero" - that when you use the "==" operator on a string to compare to zero, it's true.

The issue of PHP strings equaling zero has come up a few times recently. [...] Running that will display Equals zero!, which at first glance probably doesn’t make much sense. So what is going on here?

He gets into the specifics of what's happening - a bit of type jugging, less strict comparison since it's the "==" versus "===" and how the PHP manual talks about strings being converted to numbers.

While I still think it is odd that the string gets cast as an integer instead of the other way around, I don’t think this is a big deal. I can’t recall a single time where I’ve ever run into this issue in a PHP app. I’ve only seen it come up in contrived examples like the ones above.

Brandon Savage has a new post to his blog about what he calls a XSS vulnerability in the making, something to watch out for when you're doing validation in PHP involving the possibility of numbers as strings.

Back in September, Socorro received a security bug relating to the method we were using for processing inputs for the duration of certain reports. The vulnerability included a proof of concept, with an alert box popping up on production when the link was followed. [...] I was quite surprised at the root cause of the vulnerability. We had opted to compare the incoming data against a known set of valid values – a common practice when whitelisting certain inputs. [...] As expected, when this [example] code is tested, a string of '3' and an integer of 3 work equally well, and a string of '5' and an integer of 5 fail equally.

This automatic casting that PHP does internally caused another issue as well - if the string passed in even started with a valid number from their whitelist set, it still passed.

At first we thought this surely had to be a bug in PHP. However, Laura Thomson told me "If comparing two values, type juggling is performed first, which means that the string is converted to a number. This is done by taking the first number found in the string. So this may be confusing/a quirk/a gotcha, but it isn’t a bug." And she's right: this isn't a bug per se, but it's certainly an interesting "gotcha."

In this new post to Symbiotix.net they take a look at a migration they made taking their site and content over from a WordPress installation into a new Drupal site.

We've been running a small educational non-profit - Edulogos - for over three years now. Until recently edulogos.org has been little more than a Wordpress blog with a few extra pages and an off the shelf theme. [...] We decided it was high time to redesign the site and move it over to Drupal to give it room to grow. Like repotting a plant. "Liefde en substral", as they used to say in our home country.

They talk about the planning stages of the move - what version control they were going to use, which Drupal modules they were going to install - and walk you through the installation and configuration process step by step. They used git and github as their chosen method for deploying the site.

Tiffany Brown has a new post today showing how you can gather some statistics about the (successful) use of your e-commerce Zen Cart website with the help of Google Analytics.

Google Analytics allows you to collect pretty robust data about how users move through your e-commerce site. Here’s how to make it work with Zen Cart, an open source shopping cart.

You'll need to already have a Google Analytics account set up for the application, a Zen Cart instance installed and have at least a passing knowledge with using PHP and MySQL. There's two steps to the process - a creation of a custom functions file (code provided) and a modification to two other files (the checkout success page and global footer) to send additional information to the Analytics service.

The tilllate.com blog has a new post about a milestone in their development process - the removal of two old legacy components with ones from the Zend Framework making it running 100% on the Framework code.

The gallery and the user registration. The whole site tilllate.com is now running on Trevi, our extension of Zend Framework. With a reach of 2.5 million unique clients a month, tilllate.com is one of the world's biggest installation of Zend Framework.

They talk about the two upgraded parts of their older system - the move up to the Zend_Db database abstraction layer and a change to use memoization in the Zend_Date and Zend_Config components.

Andrei Zmievski has posted an encouraging note on his blog about the progress of PHP6 concerning the number of functions that have been correctly converted to support Unicode.

Well, PHP boys and girls, this feels like quite a milestone: 50% of the 3084 functions that are bundled with PHP 6 have been upgraded to support and work safely with Unicode.

He includes a small chart beside the post as well showing where things are currently at like the safe vs unsafe functions.

Andrei Zmievski has posted an encouraging note on his blog about the progress of PHP6 concerning the number of functions that have been correctly converted to support Unicode.

Well, PHP boys and girls, this feels like quite a milestone: 50% of the 3084 functions that are bundled with PHP 6 have been upgraded to support and work safely with Unicode.

He includes a small chart beside the post as well showing where things are currently at like the safe vs unsafe functions.

Sara Golemon brings us some news from the front about PHP6 in her latest blog entry today.

While everyone else has been busily gearing up for the release of PHP 5.2 and the new features that are going to come with it, Andrei and his small band of merry babelonians (yours truly included) have been making inroads on preparing PHP6 for a preview release. In the past week we've managed to roughly double the number of builtin functions (those which are part of the main distribution) that have been reviewed for unicode safety, either flagging them as good or upgrading their functionality

She also talks about what kinds of functions this entailed and how far along they are total (around 22%). She also encourages anyone that wants to get involved to help to jump right in.