Tomas Votruba has a post to his site sharing some background on a migration he recently helped perform migrating an application from Nette to Symfony.

On the break of January/February 2019, we migrated whole Entrydo project from Nette to Symfony. It was API backend with no templates, but still, it wasn't as easy as I expected.

Many coffees and beers were drunk during this migration. 0 programmers were too frustrated to give up. Yet, you'd laugh if you knew what took us the most time.

He starts with some of the reasoning why they wanted to make the move and walks through the steps they took to get there:

• getting ready
• making a commitment
• automated migrations > manual changes

He also talks about some "WTF moments" they had along the way where code that should have worked wasn't (and the simple issue that caused them).

Sergey Zhuk has a new tutorial posted on his site showing you how to use child processes in ReactPHP to send emails asynchronously using Swiftmailer.

In PHP the most of libraries and native functions are blocking and thus they block an event-loop. For example, each time we make a database query with PDO, or check a file with file_exists() our asynchronous application is being blocked and waits. Things often become challenging when we want to integrate some synchronous code in an asynchronous application. This problem can be solved in two ways: rewrite a blocking code using a new non-blocking one or fork this blocking code and let it execute in a child process, while the main program continues running asynchronously.

This first approach is not always available, asynchronous PHP ecosystem is still small and not all use-cases have asynchronous implementations. So, in this article, we will cover the second approach.

He starts by creating the main HTTP server handler running locally on port 8080. He adds in an exception handler to catch potential issues and provides example code of an exception being thrown. With that structure in place he starts on the Swiftmailer integration, adding it to the exception handler and pushing the details of the exception into the message body. This is then modified to use the react/child-process package to wrap a new PHP file inside of a child process loop. The tutorial ends with an example of how to pass data between the parent and child process. In this case it's the message from the exception.

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.

If you're a WordPress user and you've ever wondered about the process of creating your own custom plugin, this new tutorial from Delicious Brains might be just what you need. In it they go through their process for creating a plugin, from the initial ideas to release.

If you’ve been reading our blog for a while, you’ve probably seen some of our tutorials on developing plugins using different technologies like React and Vue. But when not writing examples for blog posts, we rarely if at all dive into creating a new plugin – there’s a lot more that goes into it before we write a single line of code.

In this week’s post, we’ll be taking a look at everything we do to create a new product or WordPress plugin. We don’t adhere strictly to any specific software development process, but the method we’re using currently seems to work well.

They then walk through the process, step-by-step, with a summary of each and helpful hints as you go along:

• Research and Brainstorming
• Wireframes
• Developing the Plugin
• Reviewing and Testing

The post ends with some concluding thoughts about the amount of work required, scope creep and the value of planning/wireframes.

In a post to his site Keith Mifsud shares his recommendations around a good workflow for developing PHP applications. Composer and GitHub play a part in the process as does the use of Git and your IDE of choice.

Continuing from the previous post Developing a Command Bus in PHP, we will look into how to get started in setting up our composer library project. Although my PHP software development workflow does vary slightly from project to project, most steps are more or less the same. Whether your project is the result of a successful proposal or you want to build an open source composer package like we’re doing here, this post will guide you in working with PHP the right way. If you are learning PHP from scratch and find that I am missing some intermediary steps or making assumptions, please feel welcome to comment below and I’ll be more than happy to explain in more detail.

He then walks through the steps in the process, each with explanation (and screenshots where appropriate):

• Getting organized and planning the application features
• Creating the GitHub repository and setting up the Kanban board
• Defining a release milestone
• Setting up a local Homestead instance for development
• Setting up Git and your IDE

The final step is to create the composer.json configuration file that defines the basic information about the project, any dependencies and the autoloading paths.

As is mentioned in this post on the Symfony Finland site, the PHP-PM project has hit their first stable release, v1.0, that includes some nice tools as well.

Running an application server written in PHP has been feasible for some years. One of the robus mature options for this has been PHP-PM, a process manager. Now the project has reached a major milestone with the release of 1.0.

The PHP-PM team released the first stable release on 8th of January 2018. It builds on the work done for some years and it builds on ReactPHP. ReactPHP is a low-level library for event-driven programming in PHP.

PHP-PM allows creating long running PHP processes that serve applications directly instead of relying an embedded PHP (like with Apache's mod_php) or a web server with PHP process manager (as with Nginx and PHP-FPM).

Updates for this release include the addition of bridges for static handling, PSR-7 integration and version bumps for Symfony components used in the system. You can check out the full list of changes in the release notes if you want to see more. The post also links to other articles with more reading and tutorials covering PHP-PM and how to put it to use (including Docker integration and basic benchmarks).

Continuing on from his first part of the series Cees-Jan Kiewiet has posted part two of his series covering the extension of ReactPHP's child processes.

react/child-process is very flexible and can work a lot of ways but sometimes you don't want to be bothered with the details of how it works and just want a simpler API to do that.

He mentions his wyrihaximus/react-child-process-pool package that makes working with the pool of processes easier and covers some of the "under the covers" handling behind it. He then shows an example of it in use, creating a pool that executes database queries via Doctrine's DBAL functionality to select the number of users from the users table. He then refactors it a bit using the wyrihaximus/react-child-process-closure functionality to make the child processing of a closure simpler.

The Cloudways blog has a new tutorial posted showing you how to speed up your deployment using Envoyer, a service from the Laravel ecosystem that's used to push code to an environment in an automated way.

Envoyer is a deployment tool used to deploy PHP applications. The best thing about the the tool is the zero downtime during deployment. This means that your application and the customers using it are not even aware of the fact that a new version has been pushed.

Envoyer works well with major repository management platforms such as GitLab and Bitbucket. Other benefits include unlimited deployments and team members. The following blog will guide you through the process of deploying applications on Cloudways using Envoyer.

The tutorial then walks you through creating an Envoyer account, connect it to a repository and set up the server to deploy the code to. They then show how to set up the deployment itself, make the push to the server and configure any post-deployment steps that may need to be performed. Screenshots are included in each step of the process so you can be sure you're on the right path.

On the Symfony blog they've shared a post giving you an "inside look" at their Call for Papers process for the SymfonyCon and SymfonyLife events. Each conference is different and has a different process for attracting speakers and selecting them once the Call for Papers has completed.

All the Symfony conferences we organize are aimed at gathering the Symfony community together to enable every community member to meet each other, share best practices and learn tips and about new features. This all happens in a convivial atmosphere that feels like a big family reunion. The highlight, of course, is listening to high quality talks. The speaker line up is very important to us and we take great care to make sure the talks we select will be appreciated and useful for the majority of conference attendees.

[...] The CFP criteria are available online and are the same for all the conferences: we're looking for the best Symfony-focused topics that are relevant to the community. We don't select speakers based on any racial, gender or physical criteria: all the talk proposals received are studied no matter who the speaker is.

They talk about what they provide to speakers, how they review the talks once the CFP is complete and some about the committee that does the selection. With the speakers they want selected they then send out the acceptance notifications and confirm schedules. The post finishes up talking about their emphasis on trying to improve the ration of female to male speakers and their code of contact.

In a new post to his site Cees-Jan Kiewiet walks you through the process to extend the ReactPHP project's child process handling (the first part of a series of posts).

react/child-process is very flexible and can work a lot of ways but sometimes you don't want to be bothered with the details of how it works and just want a simpler API to do that.

He then covers two packages where he used this "simpler is better" mentality and wrapped the current ReactPHP handling in a simpler API: one for defining "promises" on the child process and the other handles the messaging between the child and parent processes. He includes code examples for each of these, showing them in use to create simple operations.