PHP: Hypertext PreprocessorPHP 5.5.35 Release (28.4.2016, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.5.35. This is a security release. Several security bugs were fixed in this release. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.35 please visit our downloads page, Windows binaries can be found on The list of changes is recorded in the ChangeLog.
PHP: Hypertext PreprocessorPHP 5.6.21 is available (28.4.2016, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.6.21. This is a security release. Several security bugs were fixed in this release. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.21 please visit our downloads page, Windows binaries can be found on The list of changes is recorded in the ChangeLog.
Pascal MartinINI directives are evil! (27.4.2016, 22:00 UTC)

Cet article est aussi disponible en français.

A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optionnal1, depending on an INI configuration directive — the idea being each user could then enable it or not.

Still, the idea of directives that could change, sometimes deeply, the behavior of a programming langague… It scares me!

For a moment, let’s think about a language2 developped to facilitate creating HTML forms and dealing with their data.

To help beginners who know nothing about security, and as using MySQL to store data is what people do, this language’s developpers set up an option that, once enabled, automatically causes an \ to be added in front of all ' quotes passed as input3 (GET/POST/…).

Of course, some sysadmins immediately enable this directive, as it considerably improves security4 by preventing some SQL injections. But other admins disable it, as dealing with their data is each developper’s responsibility: the language must not modify those on the fly!

And now, a given application works flawlessly on one server, but will totally screw up on another one — either injecting some \ everywhere, or exploding on half SQL queries! All that because it won’t have been specifically developped to take into account different combinations of configuration options.

You were dreaming about this? Welcome to magic quotes5 hell!

In the same way, do you remember register_globals, with variables magically appearing in your scripts, when that directive was enabled? Wasn’t it hell too?

Let’s come back to this century: each time a configuration directive is added to PHP6, it means:

  • Several code branches must be tested, debugged and maintained. Maintenance, for a feature in a language as used PHP, goes for 10 years. And more!
  • More documentation to write, on one hand — and to read and understand, on the other hand.
  • More work, to ensure each application7 works with each combination of parameters.
  • In case of a problem, how long before realising some strange behavior is caused by an unusual or unexpected value for a specific configuration directive? Or, worse, by an unusual combination of values for several odd configuration directives?

Good thing is, developpers working on PHP know about those problems and tend to avoid adding new INI directives (of this kind) without solid reasons. They also provide two php.ini-development and php.ini-production files, with good configuration values — and you should stay close to those.

In any case, before suggesting « but they could allow us to enable or not this feature with a simple INI directive » for ideas as critical as a weak or strict typing mecanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?

And now, let’s repeat after me: « INI directives are evil! »

  1. Because it might break backward-compatibility, because it would change the way of the language, because some don’t like it, because some don’t want it… 

  2. I’ll let you guess which language I’m thinking about ^^. But what I’m writing here, maybe generalizing a bit, can be applied to others! 

  3. Please note this is my interpretation of things, many year

Truncated by Planet PHP, read more at the original (another 1316 bytes)

PHP ClassesNotable PHP package: PHP Image Mosaic Generator (27.4.2016, 20:44 UTC)
By Manuel Lemos
Some applications need to present groups of images in an attractive way for their users.

One nice way to present images is to create a mosaic effect. Several images are displayed as tiles next to each other, so the users can see many images at once.

This PHP class can show tiled images using the mosaic effect. There is one main background image and all the group images are displayed over that image using transparency in a way that looks like small glasses over the background image, causing great visual impression.

The class can generate the mosaic effect in a PDF document that can be printed but using the same algorithm it could eventually generate the same mosaic effect outputting as an image.

The package comes with a nice screenshot of the output so you can see the effect in practice.

Read this article to learn more details about how this notable PHP package works.
PHP ClassesPHP 7 Migration guide Part 3: 11 Changed Functions and 21 New Functions (27.4.2016, 07:36 UTC)
By Atif Shahab Qureshi
In the first two parts of our series on PHP 7 migration guide we cover backwards incompatible changes and new features.

Read this article to learn more about functions that were changed and other new functions that were added.
Matthew Weier O'PhinneyOn Deprecating ServiceLocatorAware (26.4.2016, 17:25 UTC)

A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.

One of those was, evidently, quite controversial: in v3, zend-servicemanager no longer defines the ServiceLocatorAwareInterface, and this particular release of zend-mvc raises deprecation notices when you attempt to inject a service locator into application services, or pull a service locator within your controllers.

The arguments go something like this:

  • "Dependency injection is too hard to understand!"
  • "This feature simplifies development!"
  • "If this is so bad, why was it in there in the first place?"

These are usually followed by folks:

  • saying they'll switch frameworks (okay, I guess?);
  • asking for re-instatement of the feature (um, no);
  • asking for removal of the deprecation notices (why? so you can delay your pain until upgrading, when you'll ask for re-instatement of the feature?); or
  • asking for a justification of the change.

So, I've decided to do the last, justify the change, which addresses the reasons why we won't do the middle two, and addresses why the assumptions and assertions about ServiceLocatorAware's usefulness are mostly misguided.

Originally posted elsewhere

This was originally posted as a comment on an issue. I've decided to post it to my blog to reach a larger audience, and to provide a bit more background and detail.

The intent of zend-servicemanager is for use as an Inversion of Control container.

It was never intended as a general purpose service locator (interestingly, that link details mostly disadvantages to the pattern!); that role was something foisted onto it in the spirit of "rapid application development" and to "simplify initial development," but the intention even there was that, once a class has stabilized, you should refactor to inject dependencies. (And we all know what happens with busy developers: refactoring is put off or never occurs.)

Why shouldn't you inject a service locator?

Google for "service locator anti pattern" to get an idea of why it shouldn't be used. The main points boil down to:

  • Dependency hiding.
  • Error indirection.
  • Type safety.
  • Brittleness.

Let's look at each of these individually.

Dependency hiding

What is meant by "dependency hiding?"

Take a look at this class signature:

class Foo implements DispatchableInterface, ServiceLocatorAwareInterface
    /* Defined by DispatchableInterface */
    public function dispatch(Request $request, Response $response);

    /* Defined by ServiceLocatorAwareInterface */
    public function setServiceLocator(ServiceLocatorInterface $serviceLocator);
    public function getServiceLocator();

Based on that, you'd expect:

  • that you can instantiate the object with no dependencies.
  • if you feel the need to, you could pass a service locator to the instance.
  • you should be able to execute dispatch() by passing it a request and response instance, and it should successfully return.

The service locator is nebulous; its purpose isn't clear, and it's clearly not a required dependency, as it's in a setter method.

So, you go and write a test for the dispatch() method, and you get a ServiceNotFoundException. What's wrong?

You dive into the code of the dispatch() method:

public function dispatch(Request $request, Response $response)
    $authentication = $this->serviceLocator->get('authentication');

    if (! $authentication->hasIdentity()) {
        return $response;

    $identity = $authentication->getIdentity();
            ['identity' => $identity]
    return $response;

There's two possible places that ServiceNotFoundException may have been thrown: on the first line of the method, or within the setBody() call. In both cases, you're faced with a conundrum:

  • You now know that the service locator is required. That wasn't obvious from looking at the class o

Truncated by Planet PHP, read more at the original (another 10717 bytes)

Paul M. JonesMulti-Project Issue Tracking With Producer (26.4.2016, 14:06 UTC)

With Producer, you can get a list of the open issues from your remote origin by running producer issues from the project repository:

$ cd ~/Code/radarphp/Radar.Adr
$ producer issues

    14. Separate Package for ResponderAcceptsInterface?

    29. Service level actions?


However, I’m the lead on about 40 different packages and projects, and at one point or another many of them have issues to be tracked on Github. It’s tedious to go to each package repository to list its issues separately. I want to be able to see a list of all issues on all my projects; then I can review them all at once to see what gets my attention.

To get a list of all open issues on several projects, you can create a bash script that changes to each project directory and runs project issues in each one:

cd ~/Code/atlasphp/Atlas.Cli; producer issues;
cd ~/Code/atlasphp/Atlas.Orm; producer issues;
cd ~/Code/auraphp/Aura.Accept; producer issues;
; ...
cd ~/Code/radarphp/Radar.Project; producer issues;
cd ~/Code/relayphp/Relay.Relay; producer issues;
cd ~/Code/relayphp/Relay.Middleware; producer issues;

Call the script, make it executable with chmod +x, and then you can issue ./ to get a list of all open issues on all your projects. Pipe the result to a file for easy viewing if you like!

PHP ClassesUsing Microsoft Visual Studio as PHP IDE with the PHP Tools extension: Part 1 PHP Editing Support (26.4.2016, 06:37 UTC)
By Dave Smith
Microsoft Visual Studio is a very popular IDE among developers using Windows but it does not come with built-in support to PHP. On the other hand, 75% of the PHP developers use Windows when they are developing their PHP projects.

Fortunately for Visual Studio fans there is an extension called PHP Tools that adds PHP support to that IDE and works with the Micros

Read this first part of the article to learn how to use the PHP Tools extension so you can setup and edit PHP code projects from Visual Studio.
Voices of the ElePHPantInterview with Juliette Reinders Folmer (26.4.2016, 04:00 UTC)


Audio only


Show Notes

The post Interview with Juliette Reinders Folmer appeared first on Voices of the ElePHPant.

Ben RamseyPost-Open Source (26.4.2016, 00:00 UTC)

I’m a tad late to this discussion, but I think it’s still pertinent today—perhaps even more so—and Jordi Boggiano’s recent post, “Common files in PHP packages,” got me thinking about the lack of open source licenses in public repositories.

In his post, Jordi explains how he analyzed all packages at Packagist, specifically for the sake of identifying common file names developers are using for their change logs. As part of that analysis, he was also able to tell how many projects have a license file, about which he writes:

55% [of PHP packages at Packagist] have a LICENSE file, that’s.. pretty disastrous but hopefully a lot of those that don’t at least indicate in the README and composer.json

In a 2013 analysis of software licenses on Github, Aaron Williamson, then Senior Staff Counsel at the Software Freedom Law Center, found that 14.9% of repositories had a top-level license file, while 3.7% only announce the license in the project’s README1. Of the top licenses, he noted that there has been a significant shift since 2000 in favor of more permissive licenses (MIT, BSD, etc.) and surmises this could be the result of “corporate influence/allergy to GPL” or a reaction against the GPL, favoring “freedom of developer over freedom of users.” Why are so few repositories adding open source licenses?

Luis Villa posits it might be because developers are rejecting permission culture.

The open license ecosystem assumes that sharing can’t (or even shouldn’t) happen without explicit permission in the form of licenses. What if “post open source” is an implicit critique of that assumption – saying, in essence, “I reject the permission culture”?

So, when James Governor posted in September 2012 his sentiment about younger developers being about “post open source software,” it was perhaps a bit of tongue-in-cheek crotchety cane-shaking about a cultural shift in developer attitudes toward open source and the need to grant permission.

If we’re in a post-open source era and open source licenses represent permission granted to use one’s code, then is this era marked by a reaction against the need for that permission? After all, the “younger devs” grew up in a post-Napster world full of DRM, EULAs, IP/copyright lobbyists, and legalspeak about what we can and cannot do with the content and software we’ve purchased. Open source licenses are yet another way to proliferate that permission culture. It’s no wonder there’s a backlash against the need for licenses.

In Lawrence Lessig’s 2004 book Free Culture, Lessig warned:

Free cultures are cultures that leave a great deal open for others to build upon; unfree, or permission, cultures leave much less. Ours was a free culture. It is becoming much less so.

Are open source licenses just another manifestation of the shift to a permission culture and away from a free culture? While companies have embraced open source software and many contribute back to open source projects under a variety of permissive licenses, I can’t help but feel that open source is losing its soul. These days, I don’t hear people talking about it as a philosophy. Rather, the focus is always on licensing and business cases—the permission to use it.

What do you think? Do open source licenses propagate permission culture? Are we in a post-open source era?

  1. The analysis used FOSSology to examine 1,692,135 Github repositories out of about 6 million. Alternate locations of licenses could not be accounted for (file headers, subdirectories, unexpected file names, etc.).

Truncated by Planet PHP, read more at the original (another 956 bytes)

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP