PHP ClassesNotable PHP package: PHP Get All Words (30.4.2016, 20:34 UTC)
By Manuel Lemos
PHP provides an extensive set of functions to manipulate text strings including several ways to split a string into its words.

However, there is no built-in way to detect and exclude stop words.

This class can extract the words of a text excluding stop words. I can also consider words that may appear duplicated but with different case.

Read this article to learn more details about how this notable PHP package works.
SitePoint PHPStarting a Business with Laravel Spark (29.4.2016, 16:00 UTC)

I am really excited about Laravel Spark. By the time you read this, there will probably be a multitude of posts explaining how you can set it up. That's not as interesting to me as the journey I'm about to take in creating an actual business with Spark!

The idea is simple. I have created a Pagekit module which you can use to back up and restore site data. The module makes it easy to store and download these backups, and restore them on different servers.

The trouble is, getting those backup files to the remote server takes time and a bit of hassle. I have often wanted a way to quickly and painlessly transfer this application state from one server to another, and make automated offsite backups. So I'm going to set that up for myself, and perhaps others will find it useful enough to pay for it.

Spark splash screen

Getting Started

I'm using Stripe, and intend to have a single plan with no trial. The setup for this is quite easy, but I've made a note of the plan ID. I'll need that to set the plan up in Spark...

Stripe welcome screen

Next, I reset my secret and public Stripe keys and update to the latest API (through the same screen,

I forgot that the settings in .env do not automatically reload while the Laravel development server is running, so I was getting needlessly frustrated at the keys which wouldn't seem to update.

Spark has a few expected registration/profile fields, but I want to add a few more. I would like to ask users if they would like automatic backups and I'd also like to collect their billing address, so I can show it on their invoice. First I'll have to create a migration for the new field:

php artisan make:migration add_should_backup_field

To do this, we can add the column (making sure to remove it if the migrations are rolled back):

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class AddShouldBackupField extends Migration
    public function up()
        Schema::table("users", function (Blueprint $table) {

    public function down()
        Schema::table("users", function (Blueprint $table) {

Continue reading %Starting a Business with Laravel Spark%

Evert PotWriting SQL that works on PostgreSQL, MySQL and SQLite (28.4.2016, 08:56 UTC)

I am one of those crazy people who attempts to write SQL that works on SQlite, MySQL and PostgreSQL. First I should explain why:

This is all for my project sabre/dav. sabre/dav is a server for CalDAV, CardDAV and WebDAV. One of the big design goals is that it this project has to be a library first, and should be easily integratable into existing applications.

To do this effectively, it’s important that it’s largely agnostic to the host platform, and one of the best ways (in my opinion) to achieve that is to have as little dependencies as possible. Adding dependencies such as Doctrine is a great idea for applications or more opinionated frameworks, but for sabre/dav lightweight is key, and I need people to be able to understand the extension points fairly easily, without requiring them to familiarize them with the details of the dependency graph.

So while you are completely free to choose to add Doctrine or Propel yourself, the core adapters (wich function both as a default implementation and as samples for writing your own), all only depend on an instance of PDO.

The nice thing is that ORMs such as Doctrine and Propel, you can get access to the underlying PDO connection object and pass that, thus reusing your existing configuration.

For the longest time we only supported SQLite and MySQL, but I’m now working on adding PostgreSQL support. So I figured, I might as well write down my notes.

But how feasable is it to write SQL that works everywhere?

Well, it turns out that this is actually not super easy. There is such as thing as Standard SQL, but all of these databases have many of their own extensions and deviations.

The most important thing is that this will likely only work well for you if you have a very simple schema and simple queries.

Well, this blog post is not intended as a full guide, I’m just listing the particular things I’ve ran into. If you have your own, you can edit this blog post on github, or leave a comment.

My approach

  • I try to keep my queries as simple as possible.
  • If I can rewrite a query to work on every database, that query will have the preference.
  • I avoid stored procedures, triggers, functions, views. I’m really just dealing with tables and indexes.
  • Even if that means that it’s not the most optimal query. So I’m ok with sarcrificing some performance, if that means my queries can stay generic, within reason.
  • If there’s no possible way to do things in a generic way, I fall back on something like this:

if ($pdo->getAttribute(PDO::ATTR_DRIVER_NAME) === 'pgsql') {

    $query = "...";

} else {

    $query = "...';


$stmt = $pdo->prepare($query);



First there is the “Data Definition Language” and “Data Manipulation Language” the former is used for queries starting with CREATE, ALTER, DROP, etc, and the latter SELECT, UPDATE, DELETE, INSERT.

There really is no sane way to generalize your CREATE TABLE queries, as the types and syntax are vastly different.

So for those we have a

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

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!

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