Alejandro Celaya has a new post on his site covering one thing he sees that makes the Zend Expressive framework (based on the full Zend Framework) one of the best to work with: it's interoperability with other libraries and tools.

I have written a lot of posts about Zend Framework in general and Zend Expressive in particular, but I have noticed that I have never talked about one of the things that, from my point of view, makes Expressive so game-changing, Interoperability.

He starts with a bit of background about frameworks in PHP and how developers most commonly selected them because of the features they bundled. Picking and choosing different parts of different frameworks wasn't an easy task until the PHP-FIG came around to try to consolidate and standardize interfaces. This made interoperability possible and provided the methods for Zend Expressive to implement for working with just about any library you'd like to plug in. He then gets into detail about Zend Expressive's interoperability functionality and which are based on PHP-FIG PSRs (recommended interfaces). He also covers some of the extendibility Zend Expressive brings to the table as well as providing a proof of concept to help illustrate this points.

On the FormaPro blog Maskim has written up a tutorial introducing you to a new feature that's been integrated into the Yii2 framework: AMPQ Interop, a standard structure for the handling of MQ messages (queuing).

Great News! Queue Interop is one step closer to PHP world domination.

Yii PHP Framework is the first of major frameworks that has placed a bet on AMQP Interop. A corresponding pull request “Add AMQP interop based driver.” has been merged to yiisoft/yii2-queue repository.

With this integration, the Yii framework now natively supports many AMPQ packages without having to create a custom interface layer. This includes enqueue/amqp-lib, enqueue/amqp-ext and enqueue/amqp-bunny.

On the SitePoint PHP blog Larry Garfield, a member of the PHP-FIG group, has written up an article covering the past, present and future of the PHP-FIG. In it he tries to give readers a perspective on where the group came from, some of the growth they've seen along the way and, finally, the proposal for PHP-FIG 3.0 - a restructuring of the organization based on things they've learned so far.

The PHP Framework Interoperability Group (PHP-FIG, or just FIG for short) is at a crossroads. Many electrons have been sacrificed talking about FIG’s tribulations of late, but sadly much of it has been FUD, with little effort spent on the positive. At SitePoint’s invitation, I’d like to offer a more positive outlook on FIG and the PHP community, and demonstrate why FIG can, and should, continue to have a positive impact on the PHP ecosystem.

He starts with where the group began (an "uncomfortable beginning") at php[tek] 2015 and the proposal/passing of the PSR-0 autoloading specification soon after. He then gets into the "slow but steady growth" the group had over the next several years and some of the groups that became involved (not just framework projects either). He covers some of the other PSRs created/passed, the impact they've made on the community and the growing pains they've gone through. He ends the post talking about the PHP-FIG 3.0 proposal and some of the support, opposition and discussion that has come along with that.

On the SitePoint PHP blog Deji Akala has written up a post talking about the PHP-FIG - some if its history and its current role in the community.

The Polish writer, Henryk Sienkiewicz, was awarded the 1905 Nobel prize for Literature for his epic novel Quo Vadis, which is a Latin phrase meaning “Where are you going?”. In the face of any dilemma, a brief pause and redefinition of one’s goals may be therapeutic.

The PHP Framework Interoperability Group (PHP-FIG) has come of age. With the acceptance of more PHP Standards Recommendations (PSRs), PHP has attracted further positive attention and admiration of the programming community. PSRs governing coding standards, coding style guides, autoloading, logging, caching and HTTP messages have been accepted.

[...] However, the future isn’t as bright as painted, as a recent ruckus within the organization has thrown its continuing existence under doubt.

The post starts out with some of the origins of the group and how its organized and communicates (with a large part of it being the main mailing list). There's some mention of the successes that the group has had (like PSR-0/PSR-4 that allowed for easier creation of the Composer package manager) as well as some disputes that have risen recently about the goals of the group. the post wraps up with a look at other open source communities, the fact that people don't always "see eye-to-eye" and some of the author's own thoughts about the state of PHP-FIG and its future.

One note here: be sure to read the comments on the post - they help clear up a few misunderstandings in the article's contents and give a wider context to the group and its current state.

In this recent post to the In2it blog Michelangelo van Dam makes a recommendation to decouple your logic from your framework to make it easier in the future if you need to replace it.

Decouple your framework or library from your business logic for future upgrades or replacements through usage of interfaces. By separating your business logic completely from the tool used to glue all things together, you can replace your framework or upgrade to a newer version without much problems.

He talks about how it's common for applications to quickly become "good application turns into a cluster of code on top of a cluster of code". While the title suggests completely swapping out the underlying framework, he shifts it to talk more about updates to the current framework, especially ones that would break non-decoupled functionality. He then covers the ideals of "interoperability" between PHP packages based on common interfaces (like the PSRs) and how following a similar idea can help decouple your code to prevent hard work for future potentially breaking changes.

There's been quite a bit of drama lately around the PHP-FIG (Framework Interoperability Group) organization in the past few weeks, mostly resulting from an inflammatory situation involving one of the member projects. There's been questions around about the PHP-FIG, its role in the community and how that might change in the future. In this post to his site Evert Pot shares some of his own thoughts about the group and why it still matters.

The PHP-FIG is currently going through some growing pains. I recently resigned as a voting rep, and after some juvenile controversy Lavarel, Doctrine and Propel have as well.

Since its inception 8 years ago, the groups greatest problem has been to properly organize itself. [...] Now as a sort of knee-jerk reaction to these issues, PHP-CDS was setup with a much simpler process. [...] Some good stuff is happening though. A few people are working on a thankless effort to restructure the organization dubbed “FIG 3.0”. (thanks Larry Garfield and Michael Cullum).

He makes some of his own suggestions to the group as to things he think could be "quick wins" and help make the group better overall. He then gets to the "why it matters" section. He uses the PSR-6 caching standard as an example and points out that many other standards were based on successful interfaces on projects - not so much on the caching though. He also talks some about PSR-7 and how request/response handling can "look odd" at first glance. He suggests that while the PSR-7 standard probably evolved from too much discussion, but the PHP-FIG was there to facilitate that discussion. Now they just need to make it easier to get through the process...

The Laravel News site has a post sharing some of the tools you can use to connect your Laravel and WordPress applications directly and, potentially, allow for reading and writing between them.

WordPress is one of the most popular open source applications and that means many people are comfortable using its admin to manage their site. There are times when building out a site this is advantageous as it prevents you from having to retrain the user on how to manage content, menus, photos, and more. A popular way of setting up a site like this is to use WordPress as the admin and then build out the frontend in a framework such as Laravel.

For each package they include a brief description of what it has to offer and a code sample of it in use:

• Corcel
• WordPressToLaravel
• WP Eloquent
• laravel-wp-api

They also include links to a few other tutorials showing how to make the integration, some with their own (somewhat simpler) tools to bridge the gap.

There's been a big discussion happening over on the PHP-FIG (Framework Interoperability Group) mailing list recently about the goals and vision for the project. While the group originally started out as a way to define standards for frameworks and projects to work together, some have begun to wonder if it's a bit more far reaching than that. This discussion/poll on Reddit sums up the question nicely:

There are some ongoing discussions on the PHP-FIG mailing list about, among other things, how the FIG is seen by the wider PHP community. [...] Since an earlier discussion pointed out that perhaps the FIG, while well-known, don't do enough "active outreach", consider this an attempt to "reach out."

Do you think:

• The FIG is a bunch of self-aggrandizing elitist jerks who couldn't write a competent or useful "proposed standards recommendation" if their lives depended on it, and should disband entirely.
• The FIG, while aware that the wider PHP community is watching, writes PSRs primarily for itself, and others can adopt or ignore as they wish;
• The FIG has become the closest thing to a userland standards group that the PHP community has, and should accept that role;
• Some other opinion?

There's already 50+ comments on the thread with several of the options being supported. There seems to be a leaning towards either the second option or the third with advantages and disadvantages for both. The group has undoubtably helped to change the way that modern PHP is written and they want to keep the tradition going and be what the community and language need. Go over an voice your own opinion on the matter too!

The PHP Framework Interoperability Group (or PHP-FIG for short) has just released a new version of their website with a great new look and even better organization for the PSR content: http://php-fig.org. They just tweeted about it too:

What do you think of our new website? Slicker, cleaner and easier on the eyes. Give us your feedback! :)

The new version of the site provides sections not only for the details around currently accepted standards but also on current proposals, members of the organization, bylaws and frequently asked questions about the group. They also have links to some resources where you can get involved if you're interested in the group and what they're up to.

The Zend Framework blog has posted an announcement about a new project they're offering to help make building PSR-7 middleware applications simpler - announcing Expressive.

We are pleased to announce the immediate availability of a new project, Expressive!

Expressive allows you to write PSR-7 middleware applications for the web. It is a simple micro-framework built on top of Stratigility, providing: dynamic routing, dependency injection via container-interop, templating and error handling.

The post helps you get a simple application using Expressive up and running via a Composer install and a bit of code. They talk about some of the goals behind Expressive, the interoperability it makes available and how it fits in with the Zend Framework ecosystem. They've released version 0.1.0 already and ask for testing (and bug reports) for this new framework. You can also check out the project documentation for more information about what it offers and the features currently implemented.