On his Medium.com site Nicolas Grekas talks about a new RFC that's been proposed to provide a safer method for serializing and unserializing values in native PHP functionality.

PHP serialization/unserialization has several drawbacks. [...] To mitigate these security issues, the unserialize() function handles an allowed_classes option since PHP 7.0. Implementing Serializable has this security-mitigation advantage of allowing authors to filter the allowed classes in the subgraph managed by their objects. This feature is only a mitigation because not all use cases know all the possible classes beforehand.

He starts by listing out some of the issues with both the current implementations of serialization and unserialization in PHP. From there he makes a proposal for some new functionality to help make things a bit more sane:

• a __serialize magic method
• a new S type representing serialized data
• a new __unserialize magic method
• automatic protection around destructors during the unserialization process

He finishes up the post talking about some of the expected benefits of this kind of functionality and a few of the extra considerations that would need to be thought through as a part of the implementation.

On the Delicious Blog Ian has written up a post with a proposal for WordPress suggesting that it introduce some functionality to help with dependency management and possible conflicts between the needs of plugins.

‘Dependency hell’ is a problem faced by all software, and it has been rearing its ugly head in the WordPress space over the last few years with more and more plugins using third-party libraries of code. [...] The most frustrating thing about this issue is that it’s caused by having the best of intentions! Developers use third-party code to be efficient and avoid reinventing the wheel. The code has been written by others and used and battled tested by many.

The WordPress community has a hard enough time already trying to get onboard with Composer (unlike the rest of the PHP world), without it getting tarred with the wrong brush!

He points out that, while this does have to do with packages installed through it, Composer itself isn't the issue. He offers a few suggestions and what he sees as an "ideal approach" to the problem based on some of the ideas presented here. He breaks it down into four types of code: third-party installed via Composer, Composer packages in core, custom Composer behavior and the idea of "package sandboxing". He includes some of the considerations to make this happen and plans on how the idea can move forward.

Phil Sturgeon has a new post to his site giving a brief overview of the state of the PHP-FIG, the v3.0 proposal that's been put out and sharing some of his own thoughts on both.

I was involved in the PHP-FIG since 2012, and I have seen every conversation, been part of every decision, and know the reasoning for a lot of stuff, regardless of the result and my person preferences. Being so involved with this group for so long, I have a fair bit of context that other people are lacking.

The latest of about four large conversations in the FIG is: whether or not a new organization should take its place. Seeing it framed in this way is odd, because I'm not sure anyone is literally proposing that.

Phil covers some of the background behind the PHP-FIG group including some of the original goals and how it grew well beyond the "framework" part of its name. He talks about some of the reasons he sees that the group has stayed around. Then he gets into the FIG v3.0 proposal - a relaunch of the group with a different structure and different way of getting things done (after learning from some of the mistakes in the current group). He also talks about the other elephant (elePHPant?) in the room: whether this new structure calls for a new group to be formed or if the PHP-FIG should just adapt and move on.

It will be interesting to see how this all shakes out in the end but the PHP-FIG group has, undoubtedly, helped to usher in a lot of the "modern PHP" work we see in the community now especially when it comes to things like Composer, logger structure and middleware handling.

The PHP Town Hall podcast has posted their latest episode (after a bit of hiatus) giving the low down on PSR-15, the proposed PHP-FIG standard for HTTP middleware.

n all star cast this episode, as Ben and Phil are joined by regular guest Anthony Ferrara - thinker of good ideas and long-time part-time side-line contributor to the PHP-FIG, Woody Gilk - one-speed rider & BDFL of Kohana, and Beau Simensen - author of a bunch of stuff including StackPHP.

Here we’re talking about some awesome stuff the PHP-FIG is working on: PSR-15 (HTTP Middleware). [...] We discuss all this, and the reason PSR-7 (HTTP Message) is not enough for the ecosystem to benefit from shareable middleware. [...] Woody provides a bit of the decision-making process in a very tricky aspect of the FIGs job, which is: should standards be built entirely to match existing implementations, or should standards try to improve on the learnings of the existing implementations to better them all as implementations change to support the standard. It’s all a bit chicken and egg, but a very worthy discussion to have.

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 and get the latest as new shoes are released.

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.

In a recent RFC that's been proposed and is now up for voting, the suggestion has been made to drop the var keyword in PHP 7.1 and completely remove it in PHP 8 (made a bit redundant buy the public keyword in classes). Evert Pot, however, disagrees and suggests dropping public instead.

A PHP RFC vote has started to deprecate the var keyword in PHP 7.1 and remove it in PHP 8. At the time of writing, there 23 who say it should be removed, and 18 who say it should not. [...] I’d like to offer a different opinion: I think people should be using var instead of public. I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discussions), but hear me out!

He goes through an example on one of his own projects, showing how he's mostly removed the public level of exposure from his development (using final and statics instead). He then suggests three common thoughts he sees people having being in favor of dropping var versus public:

• #1: Everyone doing the same thing is good
• #2: It’s ugly!
• #3: The public keyword is useful to convey intent

He also points to one place where he does see the need for a public but also suggests that in that case var would do juts fine too.

With a lot of talk happening around the PSR-7 HTTP request/response proposal and PSR-4 being the last "official" standard to be posted, some people are wondering what happened to PSR-5 and 6. Phil Sturgeon, a previous member of the PHP-FIG, has posted some clarification to how the PSR process works and where those seemingly missing PSR numbers are at.

The last PSR from the FIG to be sent out into the world, to be used by whoever felt like using it, was PSR-4: Autoloader. Now people are starting to hear about PSR-7, and they’re starting to “lolphp”, wondering what has happened to PSR-5 and PSR-6. [...] This is not like The Neverending Muppet Debate of PHP 6 v PHP 7, despite it being the first though to pop into many peoples heads. Instead, this is down to the Workflow Bylaw I put into place last year.

He goes on to talk about the current workflow stages and how, unlike systems in other languages, the PHP-FIG's process gives proposals a PSR number even before they're published and accepted. He also briefly talks about PSR "nicknames", naming to differentiate between similar proposals and how, despite the need for these names, they're just reference points for conversations more than anything.

The PHP Town Hall podcast has release the latest episode today - Episode #36: PSR-7 and the World of Tomorrow. In it hosts Phil Sturgeon and Ben Edmunds are joined by Hari KT and Matthew Weier O'Phinney to discuss the PSR-7 HTTP message proposal currently in the works by the PHP-FIG.

Now PSR chats can be a little boring when its about autoloading or tabs v bloody spaces, but this PSR could have some really big impact on the way you write PHP over the next few years. We talk a bunch about Aura and Zend and their plans around middlewares, what motivated Matthew to get involved with taking over PSR-7, what middlewares mean for PHP in general and some of the concerns that have been fixed in recent iterations of the PSR like mutability, streams, etc. There also a bit of chat about turtles, standing desks and broken ribs, while Phil slowly goes loopy on pain killers.

You can catch this latest episode in a few different ways: either through the in-page audio player, by downloading the mp3 or by watching the live recording over on YouTube. Be sure to subscribe to their feed if you enjoy the episode.

Pascal Martin has a new post today sharing some of his thoughts around one of the currently proposed PHP RFCs for < href="http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html">scalar type hinting. PHP has had type hints for custom objects and some things like arrays but this proposal would add in additional ones for things like "string", "int" and "float".

The Scalar Type Hints RFC for PHP 7 has first been initialized in December 2014. It went on with version 0.2 at the middle of January 2015, after changing several major ideas, and is now in version 0.3, integrating return types, as RFC Return Type Declarations has been accepted a few days ago. [...] I’ve been following this RFC (and the previous ones) with some interest, and, as I’ve taken some time to play with it a bit last week, building PHP from the sources of the corresponding Git branch, I’ll try summarizing here why I think it is interesting. Please note this is my personal opinion.

He starts with a look at what the proposal entails around these new scalar type hints and why he thinks they're a good idea. He looks at some of the things that PHP's current weak typing allows and how it has made the language very flexible as a result. He also shows how the proposal suggests the use of the "declare" function to define a strict typing constant to essentially turn on the checking only where needed. He provides a few code snippet example including object/method handling, setting a custom error handler and which of the calls work in which typing method. He finishes the post looking at the "per-file" idea of enabling the strict typing checks and some of his confusion around the point. He also talks about return types, the directives that are proposed to enable the feature and the current status of the RFC.

In his latest post Hari KT looks at Conduit, a middleware system that lets you build PHP applications out of various pieces (the middleware) according to the PSR-7 specification (for HTTP messaging).

Long back, I happened to talk with Beau Simensen about stackphp on #auraphp channel. It was hard for me to digest when I noticed it need symfony/http-kernel and its dependencies. After a few months, I started to like the middleware approach of slim framework and wanted to push it to aura. But nothing happened there. Conduit is a Middleware for PHP built by Matthew Weier O’Phinney lead of Zend framework. Conduit supports the current PSR-7 proposal. I believe like the many PSR’s, PSR-7 will be a revolution in the PHP world. Conduit is really a micro framework and can grow with your project.

Hari walks you through getting the tool installed and includes an example route that just echoes "Hello conduit!"back to the user. With that in place, he shows how to add in some middlewares, chosing the Aura router and dispatcher for more complex route handling, and integrating them into a simple controller/action microframework structure.