Alex Vanderbist has a recent post to his site showing how to fix an issue with Imagick and the "not authorized" exception that can happen when processing PDF files.

Over the last few days we've had a couple of issues with Imagick and processing PDFs on our servers. As it turns out, these issues are caused by automatic security updates. Let's look into the issue and its solution.

The post starts with an example of the errors they've been seeing with the "not authorized" message in their Bugsnag logs. As they traced the problem they saw it was happening on older codebases too, not just new ones. Finally they tracked down the culprit: a recent security update to Imagick that added extra policies for PDFs that need to be configured for it to work as before. They provide an example of what should be added to your policy.xml file and how to bulk-patch your systems via Ansible.

In a new post to his site Cees-Jan Kiewiet has posted in introduction to using asynchronous processing in your PHP application by using RecoilPHP and ReactPHP.

Getting your mind wrapped around async nature can be mind bending at first. But with RecoilPHP you can write code promise as if you're writing sync code.

He starts with some sample code showing the difference between normal ReactPHP and how the same kind of thing would be written using RecoilPHP. He then gets into the setup of a project that includes the RecoilPHP package and several others from React. With that base set up, he shows how to create a promise that opens a socket and listens on it for incoming messages and how to modify it to add additional coroutines. Finally he shares a few "bonus tips" and covers error handling.

In a post to his site Sergey Zhuk shares his opinion on asynchronous PHP and why it's in such demand these days in web-based applications.

Asynchronous programming is on demand today. Especially in web-development where responsiveness of the application plays a huge role. No one wants to waste their time and to wait for a freezing application, while you are performing some database queries, sending an email or running some other potentially long-running tasks.

Users want to receive responses to their actions, and they want these responses immediately. When your application becomes slow, you start losing your clients. Once a user has to deal with a freezing application, in most cases he or she simply closes it and never returns. When the UI freezes from the user’s point of view, it is not clear if your application is broken, or it is performing some long-running task and requires some time for it.

He goes on to talk about the importance of responsiveness in web applications and clearing up the difference between running tasks in parallel and running them asynchronously. He also talks briefly about the use of asynchronous processing on the backend and how it compares to other technology (like Node.js and Go) that have built-in asynchronous processing.

The TutsPlus.com site has a new tutorial posted for the Laravel users showing how to defer tasks to queues using functionality already included in the framework.

In this article, we're going to explore the Queue API in the Laravel web framework. It allows you to defer resource-intensive tasks during script execution to enhance the overall end user experience. After introducing the basic terminology, I'll demonstrate it by implementing a real-world example.

The article starts by talking about some of the advantages of using queues to help with reducing page load times and improving the overall performance/quality of your site's user experience. It then starts in on the Laravel-specific pieces of the queuing puzzle including the queue drivers, connection types and the queues themselves. Next they move on to the code, showing how to create a simple first job that will manipulate the images a user uploads. The post includes the code to create the "jobs" table, build the "Images" model and the "ProcessImageThumbnails" job that will build the smaller thumbnail images from larger ones. Finally they create the controller and views for the upload handling, show how to delegate it to the job for the image processing and run the queue processor do to the actual work.

Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.

Frank de Jonge has a tutorial posted to his site showing you how to use partitioning for concurrency in optimizing the business logic processing in your PHP applications.

With new ways of dealing with problems, new problems emerge. When the solution space evolves, so do the problems we deal with. One could say we only exchange one type of problem with another.

[...] Such constraints might steer you towards a synchronous solution, but a deeper understanding of a given domain might allow for an alternative approach. The need for synchronous processing is not always as final as it may seem. Sequential handling may only be a requirement within a certain context. A context may be defined by anything related to a single user, group, or even a process.

He talks some about concurrent processing versus sequential processing and how, sometimes, pure versions of either aren't exactly the right fit. Instead he proposes a system where multiple streams could be used with synchronous handling keeping with the concurrency between the streams. He illustrates his point with a "silly chat application" with the requirement that users all get their emails in order. In his proposal he starts with a standard single thread/multiple workers scenario but points out that this may lead to messages being out of order depending on the processing time for the worker it ends up on. He refactors this into a system that uses the parallel processing instead, including the PHP code that's required to make it work.

On the Tideways blog Benjamin Eberlei has written up a post showing how to use php-fpm as a "poor man's queue" system, making it easier to hand off requests to be worked on out of band without having to install other software.

There are many tasks that a web-request should not perform directly so the user doesn't have to wait many seconds for a response. [...] The usual advice you find on the internet is to setup a queue such as RabbitMQ, Redis, Kafka, Gearman or Beanstalkd. But this means another service that you need to install, setup, maintain and monitor. With some of the queue systems operating them includes a steep learning phase that requires time and money for additional hardware.

But maybe you just need a poor mans version of an asynchronous queue without all the overhead? Then why not just use PHP-FPM itself?

He admits that it's more of an "experimental approach" but feels like it could be a viable option for the php-fpm users out there. He then shows how to use the hollodotme/fast-cgi-client library to execute an asynchronous request for a "SendEmail" command. The request is then passed off to another PHP-FPM worker for processing without the user having to wait on a result. He ends the post with a few words of warning about using this approach and some other methods for getting around the offloading of longer processing.

Lorna Mitchell has a quick post to her site sharing a method she uses for handling incoming web hooks requests in PHP and the process her code usually uses for parsing the incoming message.

An increasing number of applications now offer webhooks as an integration, often in addition to an API. The classic example, familiar to most developers, is the GitHub webhooks which can notify your other systems such as CI tooling that a new commit has been added to a branch.

[...] Whether it's your source control, updates from your IoT sensors, or an event coming from another component in your application, I have some Opinions (TM) about handling webhooks, so I thought I'd write them down and include some code as well, since I think this is an area that many applications will need to work with.

She talks about the receive/respond workflow she recommends: immediately storing and acknowledge the data and then responding out of band (asynchronously). She includes a bit of example code that reads in the raw input from the incoming message, saves it and then responds back with a 200 response code back to the waiting service. She then talks about the out-of-band processing the message could use, evaluating the contents and acting on them as a result.

The Delicious Brains site has a new tutorial posted introducing WP Image Processing Queue, a tool that allows for on-the-fly image processing in your WordPress application via background processing.

I think the best solution is to get background processing into WordPress core so that all themes/plugins can share a single queue and ensure we don’t impact server performance. And so started my crusade.

At PressNomics, I had a great chat with Mike Schroder. He presented a very good path to core: find a feature that WordPress core needs and that needs background processing. In other words, piggyback! This is exactly how the image optimization stuff made it into core last year: by piggybacking off of responsive images. For background processing, he proposed coming up with an alternative to on-the-fly image processing (OTFIP). Whoa, turns out OTFIP is a problem we regularly deal with for WP Offload S3 as well. This could be a “two birds – one stone” kind of thing. Stars were aligning.

He talks more about some of the current discussions and efforts around processing the images like this (with OTFIP, On The Fly Image Processing). He covers some of the libraries that are currently out there for this processing and how, ultimately, the image processing queue came out to replace them as a result of some work at WordCamp US Contributor Day. He gives an example of the code needed to resize the images and the resulting markup. The post ends with the work he's planning on getting this queuing into the WordPress core and encourages plugin authors to use the OTFIP functionality rather than an external library.

The TutsPlus.com site has posted a tutorial today showing you how to use the "Store" functionality in Mailgun from your PHP application to temporarily handle your incoming emails.

In today's episode, Mailgun stepped in to sponsor a tutorial about how I integrated its message routing and Store() API to handle replies from users.

For example, when people receive meeting requests from others with Meeting Planner, they may just choose to reply and send a note like they would to a typical email thread. [...] Sounds complicated, but one of Meeting Planner's goals is to reduce the back and forth emails between people about planning and consolidate real-time changes into fewer notifications.

The start by introducing the Mailgun service and, more specifically, the Store() offering it provides. He uses a Yii2 framework based application to show the integration. Once the MX (mail) records are set up correctly it can then hook back in to your mail servers or web application. The code is included to make the migration to hold the notification info, make the POST request back to the application and use background process to handle the mail processing.