Paul Jones has a post to his site covering a method he's worked up to solve the "widget" problem in ADR, the Action-Domain-Responder design pattern he worked on defining.

The “widget problem” is when you have several panels or content areas on an HTML page that have different data sources. You might have a main content area, then a calendar off to the side, with perhaps a list of recent news items or blog posts, a todo or reminder widget, and maybe other information panels. The problem is that they each have different data sources, and may not always be displayed in every circumstance — perhaps they are only shown to some users based on their preferences, or under certain conditions.

So how, in Action-Domain-Responder, do we get the “right” data for the set of widgets that are actually going to be displayed?

His answer is pretty simple, basically that the requests are handled the same as everything else but with more kinds of data contained in the "domain" of the response. He walks through a code example of a site that would pull out the set of widgets to show and inject them into the "payload" for passing back to the responder for output handling.

In a recent article Théo Fidry covers a topic that's become common with the use of Composer and various PHP packages: managing dependencies.

When you are creating a PHP application or library, you usually have 3 kinds of dependencies:

• Hard dependencies: what your application/library needs to be able to run
• Optional dependencies: for example a PHP library can provide a bridge for different frameworks
• Development dependencies: debugging tools, test frameworks…

He then works through several of the issues involved with using each including having too many dependencies, untestable dependencies and conflicts. He then counters these with some helpful suggestions around them including the use of phars and using multiple repositories to break down the package and make it easier to manage their dependencies.

In this post to the bitExpert blog Stephan Hochdörfer shares some updates to his own opinions on the "require-dev gone wrong" problem he previously posted about. In this new post he points out that, while there is an issue here, it's not something that can't be resolved (or has been to some extent).

The gist of all this is that, yes, we do have a problem. Fortunately, there are already solutions out there - none of them perfect, but there's always room for improvement isn't there? Installing .phars with Composer is currently not supported out-of-the-box by Composer but there are 2 projects to help us deal with it: One is tooly-composer-script - a Composer plugin that manages to pull .phar files from a remote location. The other one is PHIVE - the PHAR Installation and Verification Environment.

He points out that, while these two packages help the situation, there's still another "require-dev" issue with tools that don't actually "touch" the code. This requires that a certain version of the tool be run against a certain version of your code, creating a dependency of a different kind. Fortunately there's also a tool to help some with this as well, the php-scoper project that makes it easier to isolate functionality through randomly generated namespaces.

In a new post to his site Rob Allen shows you how he adapted a package of his own to work with a Slim framework based API to render "ApiProblem" types correctly (according to this specification).

In the API I'm currently building, I'm rendering errors using RFC 7807: Problem Details for HTTP APIs. As this is a Slim Framework project, it uses PSR-7, so I updated rka-content-type-renderer to support problem.

RFC 7807 defines a standard for sending details of an error in an HTTP response message. It supports both XML and JSON formats.

He starts with an example of the "Problem" response format that includes data for the type of error, details and links to other related objects. He points out this package from Larry Garfield that handles the actual output of the respose format but Rob needed a way to shift between JSON and XML formats too. This is where his updates to his package came in, changing it to include a ApiProblemRenderer that reads the "Accept" header of the incoming request and correctly formats the results accordingly.

Anthony Ferrara has written up a post for his site sharing more information about middleware and the PSR-7 proposal that's being discussed to help standardize interfaces with this popular form of application processing.

Last week, a proposal to standardize middleware for PSR-7 was introduced to the PHP-FIG. The general concept of middleware is not a new one, and has been in use in the PHP world for many years. Several people have raised significant concerns with the proposal, which have gone completely unheeded by the author. Let me go through the most major of these concerns, as well as show what a better proposal might look like.

He starts off with a brief look at the current proposal - the interface it defines and an example of a real world usage of it to check some attributes on the request/response. He gives a few more examples before getting into what he sees as the fundamental problem with the interface: that it passes in a response instance rather than creating its own ("what does $response mean inside the middleware?"). He's mostly talking about context and not knowing from one middleware to the next what kind of changes may have been made to the response. He also includes some of the arguments on the "for" side of including the parameter and an interesting list of middleware that does this modification prior to the next() call, making it difficult to determine the actual state.

He ends the post with a few other issue he has with the proposal including the use of the __invoke method name, a restriction on typing and the next method being callable. He makes a few suggestions of modifications to the proposal that he thinks could help make it better, correcting these issues.

On the Paragon Initiative site there's a new post that promises a way to solve all of your cryptography problems in PHP with three simple steps.

Last year, we began developing Halite, a FOSS high-level wrapper for the PHP bindings to libsodium. We use Halite extensively in our own projects (including our upcoming CMS which has quite a few of its own innovative cryptography features baked-in).

As of version 2.1.0, we are confident that Halite solves all of the application-layer cryptography problems that most PHP developers face; and it does so in three easy steps. (For transport-layer cryptography, you should still use TLS, of course.)

Their three steps to effectively using Halite and libsodium in your application are:

• Step One: Managing Cryptography Keys
• Step Two: Encrypting or Authenticating with Halite
• Step Three: Decrypt or Verify

Each step comes with example code showing how to use the tool to accomplish it. There's also a few other problems that are solved by using the library including generating encrypted password hashes and whole file cryptography.

On the HHVM blog there's a post talking about some of the updates they've made with array handling in Hack to help make it more efficient and overcoming some of the challenges in how they're being used.

Arrays are the ubiquitous data structure in PHP, used to represent everything from lists, associated lists, sets, tuples, or even a bag of data. This flexibility itself makes it challenging for Hack to understand how an array will be used. [...] If this was the only problem with PHP arrays, then the solution would be “simple”; make the type checker smarter (something we are working on). However there are a number of other semantic details around arrays that are nearly impossible to analyze statically.

They talk about some of the issues a bit more specifically including:

• indexing of non-existent keys
• key coercion
• arrays containing references

They also talk about some of the legitimate use cases for arrays over the collections Hack offers, mostly do to with the values they could contain. The post ends with links to some of the other future improvements to the array handling in Hack and a look further out and their vision of replacing PHP arrays with Hack arrays and moving collections to a runtime library.

Michael Mikowski has a post to his site that suggests that a RESTful API is a big lie and that the concept should "rest in piece" and be replaced with something he calls a "JSON-pure API".

If you have read an internet developer resume or job posting in the past 10 years, then you might be forgiven if you think that RESTful APIs are gifts bestowed from the heavens by The One True Web Developer Deity. RESTful APIs are everywhere. Even the marketing folks are pushing them in sales material intended for CEOs and Human Resources-type folks. So how good of an idea are RESTful APIs really?

He starts with a look at where the concepts for a RESTful API originally came from and defines some of the most common concepts around them (verbs, request/response, etc). He then suggests that they're "pretty awful" and lists some of the larger problems he sees with them:

• Problem #1: There is little agreement on what a RESTful API is
• Problem #2: The REST vocabulary is not fully supported
• Problem #3: The REST vocabulary is not rich enough for APIs
• Problem #4: RESTful APIs are very hard to debug
• Problem #5: RESTful APIs are usually tied to HTTP

He suggests that the way to move forward is to migrate to the "JSON-pure API" methodology, fixing most of the problems he listed. He describes this kind of API and how it simplifies the entire process and makes it "more reliable, easier to use, easier to port, and easier to debug."

The Tideways.io site has posted a tutorial showing you how to "avoid the thundering herd" of incoming requests to your application using a file-based PHP 7 opcode cache to reduce load and increase performance on your site.

In the last blog post about Fine-Tuning Opcache Configuration I mentioned the thundering herd problem that affects Opcache during cache restarts. When Opcache is restarted, either automatically or manually, all current users will attempt to regenerate the cache entries. Under load this can lead to a burst in CPU usage and significantly slower requests.

[...] In Rasmus talk at FrOsCon 2015 (Video at 12:30, Slides), he showed the persistent secondary file-based cache Opcache gets in PHP 7. It can read the generated opcodes from disk instead of having to recompile the code after cache restart. This happens only when the compiled opcaches are not found in shared memory.

They talk about the benefits that this caching can provide, not only to web-based applications but also to command line scripts. There's a mention of possible security issues if an attacker is able to read/write to the cache files (but permissions can help that). The post ends with how to install it on your own PHP 7 instance, using the --enable-opcache-file flag on compilation.

The PHP Roundtable podcast has posted their latest episode - #23: PHP's Major "Bus Factor" Problem, hosted by Sammy Powers with guests from the PHP community: Samantha Quiñones, Davey Shafik, Chris Tankersly and Michelangelo van Dam.

Inspired by a lively Open Spaces session at php|tek 2015, we discuss how PHP's ecosystem could be threatened by a not-so-obvious bus factor and what we can all do to keep things thriving.

You can catch this latest episode either through the in-page video player or directly on YouTube. If you enjoy the show, be sure to subscribe to their feed too!