SitePoint PHPInspecting PHP Code Quality with Scrutinizer (25.4.2015, 16:00 UTC)

We’ve gone through a decent number of tutorials about code quality, inspections, auto-build systems and so on here at SitePoint:

In this article, we’ll take a look at Scrutinizer CI - a continuous integration tool that’s quite expensive and closed to private projects, but very handy for public ones.

Scrutinizer vs/+ Travis

Scrutinizer is kind of like your online version of Jenkins and the tools suggested in the 4-part series mentioned in the introduction of this post. It supports PHP, Ruby, Python and to an extent JavaScript out of the box.

Continue reading %Inspecting PHP Code Quality with Scrutinizer%

Nomad PHPPHP Files: An Introduction (24.4.2015, 21:01 UTC)

Speaker: Jacques Woodcock @jacqueswoodcock Working with files in PHP can be a fun and a frustrating task; one you never know when you’ll be asked to do. In this talk, we’ll go over how to work with files and some of the most common built in functions to help accomplish your tasks.

The post PHP Files: An Introduction appeared first on Nomad PHP.

Hasin HayderGetting rid of Redux Framework annoyances (24.4.2015, 16:14 UTC)
SitePoint PHPSending Emails in PHP with PHPMailer (24.4.2015, 16:00 UTC)

PHPMailer is the most popular open source PHP library to send emails with. It was first released way back in 2001 and since then it has become a PHP developer’s favorite way of sending emails programatically, beside a few other fan favorites like Swiftmailer.

Emails flying stock picture

In this article we’ll talk about why you should use PHPMailer instead of PHP’s mail() function and we’ll show some code samples on how to use this library.

Is it an alternative to PHP’s mail() function?

In most cases, it’s an alternative to PHP’s mail() function, but there are many other cases where the mail() function is simply not flexible enough to achieve what you need.

First of all, PHPMailer provides an object oriented interface, whereas mail() is not object oriented. PHP developers generally hate to create $headers strings while sending emails using the mail() function because they require a lot of escaping - PHPMailer makes this a breeze. Developers also need to write dirty code (escaping characters, encoding and formatting) to send attachments and HTML based emails when using the mail() function whereas PHPMailer makes this painless.

Continue reading %Sending Emails in PHP with PHPMailer%

blog.phpdevInvoke and Gatekeeper for Route Authentication & Authorization (24.4.2015, 12:59 UTC)

As a part of a new project I’m working on (personal, not work) I came across a common need to enforce authentication and authorization handling in a bit more automated way based on the URL requested. I looked around for options and didn’t really find many that could be implemented somewhat simply but I did like the way Symfony defines their YAML to enforce auth* on the various endpoints. I set out to make something similar but a little simpler and ended up making Invoke.

It’s a super simplified version of the YAML-based routing and only has functionality for checking groups and permissions right now, but that’s not what I really wanted to talk about in this post. Invoke is fun and all, but I wanted to show how I’ve integrated it with another more robust tool I’ve written, Gatekeeper. The goal of Gatekeeper is to make a simple drop-in authentication system for applications to take care of a lot of the boilerplate user management needs. It comes with the usual CRUD handling for users, groups and permissions (RBAC) and also supports password resets, security questions and “remember me” functionality. Again, Gatekeeper is a cool library but it’s not the primary focus here. I wanted to integrate the two libraries so I could let each do what they do best – Invoke to check the current user against a set of criteria and Gatekeeper to provide the data for this validation.

Invoke lets you hook in your own users via a `UserInterface` that you can implement in your own application. In this case Gatekeeper has a concept of users too, but they don’t exactly mesh with what Invoke is expecting. So, let’s make an Invoke-compatible user object that it can use for it’s checks. This is the real key to the integration:

use \Psecio\Gatekeeper\Gatekeeper as Gatekeeper;

class InvokeUser implements \Psecio\Invoke\UserInterface
  private $details = array();

  public function __construct(array $details)
    $this->details = $details;

  public function getGroups()
    $groupSet = array();
    $groups = Gatekeeper::findUserById($this->details['id'])->groups;
    foreach ($groups as $group) {
      $groupSet[] = new InvokeGroup($group);
    return $groupSet;

  public function getPermissions()
    $permSet = array();
    $permissions = Gatekeeper::findUserById($this->details['id'])->permissions;
    foreach ($permissions as $permission) {
      $permSet[] = new InvokePermission($permission);
    return $permSet;

Then, we’ll define the Invoke configuration in a YAML document:

  protected: on
  groups: [test]
  permissions: [perm1]

In this case we’re telling Invoke that when it sees the requested URL of `/event/add` it should check a few things:

  • That the user is authenticated (protected: on)
  • That the user has a group with the “name” attribute of “test”
  • That the user has a permissions with the “name” attribute of “perm1″

If the user passes all of these checks, they’re good to go. Here’s how that would look in the execution of the Invoke code:


$en = new \Psecio\Invoke\Enforcer(__DIR__.'/config/routes.yml');

// If you're already using Gatekeeper for user management, you
// can just use this:
$userData = Gatekeeper::findUserById(1)->toArray();

// Otherwise you can push in your own user data
$userData = array(
  'username' => 'ccornutt',
  'id' => 1,
  'email' => ''

$allowed = $en->isAuthorized(
  new Confer\InvokeUser($userData),
  new \Psecio\Invoke\Resource()

if ($allowed === false) {
  // They're not allowed on this resource, forward to an error!


The Invoke Resource by default looks at the current REQUEST_URI value so no options are needed when it’s created.

I’ve found this a pretty simple way to integrate these two libraries while still maintaining the correct separation of concerns enough to let each tool do their job. I’m always welcome to feedback on both projects or, of course, PRs if you find something that needs improving or a bug to fix.

Here’s more information about each of them:

Nomad PHPFear Not the Machine of State! (24.4.2015, 05:00 UTC)

Fear Not the Machine of State!

Presented By
Yitzchok Willroth
July 23, 2015 20:00 CEST

The post Fear Not the Machine of State! appeared first on Nomad PHP.

bjori doesn't blogThe Frills (23.4.2015, 17:12 UTC)
I don't like ORMs. I really don't. It's not just because all of the ORM frameworks I've seen make mockery out of performance needs, but they also tend to be extremely over-engineered, which makes me want to cry. I'd wager that most people using ORMs are actually solving the wrong problem with the wrong solution, simply because there wasn't a better alternative for their data-modeling needs and the benefits of adopting an ORM outweighed its inherent problems.

It's like driving a gasoline-hungry car. You say that you care about its MPG rating, but you are still wasting a lot of gas without ever looking back. It is just a cost of living. Or insurance: You know you can save 15% or more... but you don't. You've accepted that bi-annual rip-off as cost of living.

Just like using an ORM, you have accepted the pain as cost of living. Well, I don't :)

ODS - Object<->Document Serializer

The new MongoDB PHP driver includes an experimental ODS interface (BSON\Persistable) that allows you to automatically store your object as documents in MongoDB the way you see fit. And the best part? When you retrieve the document from MongoDB, the driver will know which class it represented and can reconstruct the object (again, the way you see fit).

All you have to do is implement the two methods of the BSON\Persistable interface:
That's it! There is no special way of querying by type, parent object, or any of those weird things that ORMs have introduced to work around storing objects or documents in databases. Your document is your object. Your relations are your relations.

If you would like to build on top of this functionality, it's trivial to implement a trait that implements both methods and provides basic change tracking. At that point, we are entering ORM and ODM territory and are going beyond what we should ask from an extension. All we want from an extension is performance, and simplicity.

Pádraic BradyTLS/SSL Security In PHP: Avoiding The Lowest Common Insecure Denominator Trap (23.4.2015, 14:50 UTC)

A few weeks back I wrote a piece about updating PHARs in-situ, what we’ve taken to calling “self-updating”. In that article, I touched on making Transport Layer Security (TLS, formerly SSL) enforcement one of the central objectives of a self-updating process. In several other discussions, I started using the phrase “Lowest Common Insecure Denominator” as a label for when a process, which should be subject to TLS verification, has that verification omitted or disabled to serve a category of user with poorly configured PHP installations.

This is not a novel or even TLS-only concept. All that the phrase means is that, to maximise users and minimise friction, programmers will be forever motivated to do away with security features that a significant minority cannot support by default. In the case of PHP users on Windows, this may include not having openssl or curl installed. Without either of these options, TLS verification in PHP becomes impossible without looking outside PHP (e.g. locally available system commands).

The problem is that while programming to the Lowest Common Denominator is fine for many things, doing so to the point of maintaining active security vulnerabilities is not. Let’s take the simple example of Composer. It’s an incredible tool, used by most PHP programmers I know, but it can’t perform TLS verification worth a damn despite operating primarily over HTTPS URLs. On Reddit, there is a another tool just announced which relies on Composer to update application modules. That inherits the same vulnerability by depending on Composer in a live server setting. So too will other Composer dependent tools merely by inheriting from or reusing its download classes. In time, you finally have people seeking refuge in authority because Composer does this, and look, everyone and their pet hamster still uses it!

There’s A Topic In Here Somewhere

Much as I did around writing phar-updater and, more importantly, documenting the reasoning behind a tool that enforces TLS and supports openssl signing as a first citizen, I’d like to drill down into the specifics of how to approach this problem. It’s not an insurmountable one assuming you accept some basic ideas:

  1. You should never knowingly distribute insecure code.
  2. You should accept responsibility for reported vulnerabilities.
  3. You should make every effort to fix vulnerabilities within a reasonable time.
  4. You should responsibly disclose vulnerabilities and fixes to the public.

These four ideas are self-explanatory as the guiding principles that any good security policy is founded upon. When you violate them, you earn general mistrust and reputational damage when your users either figure out that violations occurred, or that those violations contributed towards the worst case scenario: getting hacked and all the ugly outcomes that follow. You only need to go on Reddit and other news sites to find that Magento’s reputation is currently being ripped to shreds over failing to uphold these principles recently.

So, given something like an application where the expectation is that everyone will install it, whether it be on Ubuntu, Windows, or Terminator-X45, how does one go about implementing TLS verification as securely as possible without being overly burdensome on programmers? Is it even possible?

Step 1: Implement TLS Verification

In keeping with those four ideas from earlier, the first course of action is to just implement TLS verification and get a handle on the consequences. Foisting a security vulnerability onto all members without their consent is irresponsible programming and should never be tolerated by the community.

It’s essential to reiterate that Insufficient Transport Layer Protection is a security vulnerability, making it possible for attackers to perform Man-In-Th

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

PHP ClassesPHP IPC with Daemon Service using Message Queues, Shared Memory and Semaphores (23.4.2015, 09:30 UTC)
By Dmitry Mamontov
In a previous article, we learned how to create a simple daemon service in PHP to monitor and process an important activity on a machine in the background.

Now we move with a more advanced topic which is how daemon processes can communicate with other programs, or with other instances of the same daemon process.

Read this article to learn how to perform IPC, Inter-Process communication in PHP to send and receive data using message queues, as well as to transmit large volumes of data using shared memory, an using semaphores to prevent problems caused by simultaneous accesses.
SitePoint PHPStackPHP Explained (22.4.2015, 14:28 UTC)

Today we are going to look at StackPHP and try to understand what this thing is all about. Although this post will have some code, this article will be rather theoretical as we are interested in learning what StackPHP actually is, where it comes from and why it is useful.

StackPHP Logo

As the front page of the StackPHP project says, Stack is a convention for composing HttpKernelInterface middlewares. But, in order to actually understand this definition, we will have to cover a few concepts first. At the end, we will also illustrate the concepts we learned in the context of StackPHP with some example code. This usually makes things much easier to understand.

Continue reading %StackPHP Explained%

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