In a post to his site Tomas Votruba takes a look at the "rocket science" behind the migration of DocBlocks to typehints in your PHP application.

What if you could add scalar typehints int, bool, string, null to all parameter type and return type by running a CLI command? But also all classes, parent, self and $this?

Do you think it's an easy task to move @param int $number to (int $number)?

He talks about some of the current tools that handle the conversion of type-hints to type checks, but points out that some of them break the code (as they don't have the right context). He shares the results of some of his own research using these tools and issues that can come up with code changes. He also includes issues that could come up with the use of self/parent and namespacing. The post ends with some instructions on using the rector/rector package to handle this refactoring in a bit better way (including the configuration required).

In a new post to his site, Rob Allen walks through the process of migrating an older site to use the password hashing functions in PHP instead of the previous custom implementation.

I’ve recently been updating a website that was written a long time ago that has not been touched in a meaningful way in many years. In addition to the actual work I was asked to do, I took the opportunity to update the password hashing routines.

This site is so old that the passwords are stored using MD5 hashes and that’s not really good enough today, so I included updating to bcrypt hashing with password_hash() and password_verify() in my statement of work.

I’ve done this process before, but don’t seem to have documented it, so thought I’d write it the steps I took in case it helps anyone else.

He starts off by taking all of the current passwords (not plain-text, already hashed) and migrating them all to their bcrypt-ed version. He then updates the login functionality to select the account by email and check the record's password value with the password_verify function. Finally, he updates the system to rehash the plain-text password value (received from the user and verified) with bcrypt and save that back to the database and updated the password hashing method on user account creation.

Continuing on in his series of migrating your PHP syntax checking over to the EasyCodingStandard, Tomas Vortuba has a new post showing how those currently using PHP CS Fixer can make the migration over to the new tool.

We looked at how to migrate from PHP_CodeSniffer to Easy Coding Standard on Monday. But what if your weapon of choice is PHP CS Fixer and you'd to run also some sniffs? There are a few simple A ? B changes, but one has to know about them or will get stuck.

ECS is a tool build on Symfony 3.4 components that combines PHP_CodeSniffer and PHP CS Fixer. [...] But what if you already have PHP CS Fixer on your project and want to switch?

He then lists out the six steps, giving a brief description of the change and any commands of code required:

1. From String Codes to Autocompleted Classes
2. From notPath() to skip Parameter
3. From .php_cs to YML Config
4. Configuring Fixer Values
5. From no --dry-run to --fix option
6. From @Rules to imports

You can find out more about the EasyCodingStandard on its GitHub repository.

Thomas Vortuba has a new tutorial posted to his site showing how to easily switch from PHP_CdeSniffer to EasyCodingStandard for enforcing the structure and syntax of your PHP application's code.

Last year, I helped Shopsys Coding Standards and LMC PHP Coding Standard to migrate from PHP_CodeSniffer to EasyCodingStandard.

There are a few simple A ? B changes, but one has to know about them or will get stuck.

Do you also use PHP_CodeSniffer and give it EasyCodingStandard a try? Today we look at how to migrate step by step.

The post then walks you through the five-step process and lists out the major changes:

1. From String Codes to Autocompleted Classes
2. From @codingStandardsIgnoreStart to skip Parameter
3. From 0 and to skip Parameter
4. From XML to YML Config Paths
5. Configuring Sniff Values
6. From Severity and Warning to Just Errors
7. From Beautifier to --fix option

Each step includes either the command required, the configuration changes to make or code examples of the refactor to help illustrate the changes.

The OS X users out there are no doubt familiar with the Homebrew package management system that makes it easier to install and update software on your system. This includes PHP and several other related pieces of software. In this post to his site Andy Grunwald shows you how to use Homebrew to migrate your local PHP setup up to PHP 7.2.

Last week, Hans Puac, a colleague of mine, wrote a small guide into our internal company chat on how to migrate your local PHP environment on macOS to the new Homebrew version 1.5.*. The guide helped a lot of other engineers inside trivago. I thought it might help more people from the internet. I asked Hans if I am allowed to share it, and he approved. So kudos belongs to him. Here we go:

With Homebrew 1.5.0 the tap homebrew/php got deprecated. They migrated it to homebrew/core, but this is changing the installation process completely.

He then walks through the steps (complete with the commands required) to make the update happen:

1. Cleanup (the currently installed PHP packages)
2. Update [Homebrew]
3. Install PHP (7.2)
4. Verify the installation
5. Install extensions
6. Cleanup

He also includes a few tips to help you troubleshoot some of the common problems including wrong versions of PHP, wrong php.ini being used and a "module already loaded" issue.

Christoph Rumpel has a post to his site sharing the process he followed in migrating his blog site from Jekyll to Laravel. Jekyll is a Ruby based static site generator rather than a dynamic solution like Laravel provides.

One of my resolutions for 2017 was to redesign my blog. One week before the new year I faced myself with the challenge and thought to myself if this was still doable. Somehow I managed it and here it is. In this article I will explain the process and show you how I redesigned the blog with Tailwind CSS and moved it from Jekyll to Laravel with keeping almost the same performance.

He then walks through the entire process, breaking it down into a few different sections:

• How to start
• The backend stack
• Toughest decisions are the ones about design
• Tailwind CSS
• Make it fast

For each of the sections there's code, screenshots and links to other resources included.

Sergey Zhuk has posted another article to his site covering functionality provided in ReactPHP. In this latest tutorial he covers the PromiseStream handling of the library allowing for the translation from promise to stream (and back).

One of the patterns that are used to deal with streams is spooling: we need the entire resource data available before we start processing it. One approach is to collect each chunk of data received from the stream.

But, imagine that we have some client code that wants to process some data from a file. It doesn’t care about the streams, it only needs to receive the entire data from the file. With this approach, this code should be called inside the callback for the end event of the stream. So, the client code should now about streams, events, and callbacks. But sometimes it’s impossible.

Example code is included to illustrate the problem above and an answer is provided in the form of ReactPHP promises. This allows the data to move into the promise as the data is being read from the stream's source. The tutorial goes on to talk about the functionality behind this transition including the buffer method to create the promise with chunked data, the all method to build the promise from the full data in the stream and the first method that works with events on the stream. The article then covers the reverse, showing how to pull information from a promise and push it back out to a stream via the unwrapReadable and unwrapWritable methods.

In a post to his site Adam Culp makes a recommendation to all of those running their applications on older versions of the language: stop the pain, get to PHP7.

So, now you may be asking, “What does [my football story] have to do with upgrading to PHP version 7?” The answer, because many are letting the pain of moving to PHP 7 prevent them from experiencing the pleasure and rewards.

PHP version 7.0 was released almost 2 years ago. (1 year 10 months to be exact.) And many are still running PHP version 5.something. As a matter of fact, PHP version 7.0 is already going to run out of active community support in only 1 month and will only receive security fixes for another year after that.

He then talks about some of the pains that usually come with upgrading, especially when the jump is a relatively large one (like from the 5.x world). He mentions the acclamation of limitations that is all too easy to get used to with older versions. He also covers some of the pleasures that come with PHP 7 including one of the most major ones: the instance performance boost it gives most applications.

On the Twilio blog they've posted a new tutorial from author Margaret Staples showing you how to create a Symfony 3 project with user handling along with the Friends of Symfony bundle.

User handling is a fundamental part of a ton of web projects. This post will walk through how to get setup using the Symfony 3 framework and the Friends of Symfony bundle so that your project can allow users to register, login and out, and view and edit their User profile. The steps here will serve as a great starting point for your next web project.

She then walks you through the installation of the Symfony standard edition and how to answer some of the interactive setup questions. Once that's set up she shows how to install the FriendsOfSymfony/FOSUserBundle and what configuration options need to be changed to implement it. She then shows how to update the database schema for the new user handling and how to check to be sure the login, registration and profile pages are working as expected.

On the Master Zend Framework site Matthew Setter has written up a new tutorial showing you how to migrate from Zend Expressive v1 to v2 with the help of some command line tooling support provided as a part of recent updates to the project.

In part one of this series, we started learning about the tooling support available for Zend Expressive, provided by Zend Expressive Tooling There, we learned how we can use the package to create, register, and deregister middleware, and scaffold new modules. But that's only half of what the package can do.

Here, in part two, let's learn about the other half, which removes some of the heavy lifting required when migrating Zend Expressive applications from version one to two.

He first defines some of the main differences between the two versions, a checklist of things the tooling will help you more automagically update. He talks more specifically about migration support, moving to "programatic pipelines" in Expressive v2 and scanning for deprecated error middleware. There's also information about locating the legacy request and response handling and how they're refactored to the newer format.