Lorna MitchellZCE Questions Pack Unavailable (16.12.2014, 09:09 UTC)

There is a change in legislation for selling digital goods to anyone in the EU, and to cut a long story short this means that my ZCE Questions Pack will be unavailable at least in the short term. The pack is intended for anyone preparing for ZCE, it has general advice, sample questions and detailed answers and resources covering all the topics you will encounter at ZCE.

However from January the VAT rules change and I'm not in a position to comply with the new rules (they would cost a lot more than the sales make). I'm looking for alternative sales channels that would enable me to keep making the pack available but those won't be in place immediately. If you are studying for ZCE over the Christmas break, please make sure you have the pack well in advance!

Buy ZCE Questions Pack $25 Buy Now

Buy the pack by clicking above, I have other (free!) resources for you also on my ZCE page. If you have an earlier version of this pack, email me your receipt and I'll send you a new copy - but again, you have about a week to do it!

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Cal EvansInterview with Stefan Koopmanschap (16.12.2014, 05:00 UTC)

Twitter: @skoop

Show Notes

SitePoint PHPAngularJS in Drupal Apps (15.12.2014, 16:00 UTC)

Angular.js is the hot new thing right now for designing applications in the client. Well, it’s not so new anymore but is sure as hell still hot, especially now that it’s being used and backed by Google. It takes the idea of a JavaScript framework to a whole new level and provides a great basis for developing rich and dynamic apps that can run in the browser or as hybrid mobile apps.


In this article I am going to show you a neat little way of using some of its magic within a Drupal 7 site. A simple piece of functionality but one that is enough to demonstrate how powerful Angular.js is and the potential use cases even within heavy server-side PHP frameworks such as Drupal. So what are we doing?

We are going to create a block that lists some node titles. Big whoop. However, these node titles are going to be loaded asynchronously using Angular.js and there will be a textfield above them to filter/search for nodes (also done asyncronously). As a bonus, we will also use a small open source Angular.js module that will allow us to view some of the node info in a dialog when we click on the titles.

Continue reading %AngularJS in Drupal Apps%

Brandon SavageThe definitive guide to contributing to open source (15.12.2014, 14:55 UTC)
There are millions of PHP developers, but only a (large) handful of contributors, authors and maintainers of open source software. Packagist reports a little under 50,000 packages in the PHP ecosystem. This is a huge number of open source packages, but is a small number compared to the PHP developers in the world. The truth […]
PHP 10.0 BlogObjects as keys (15.12.2014, 07:58 UTC)

I’m going to put to vote soon another of my RFCs, namely one about “objects as keys“. So, I want to outline the case for it here and address some criticisms and questions raised while discussing it.

Why we may want it it?

Traditionally, in PHP array keys could be strings or numbers, and this is deeply linked to how PHP hash tables (which store mostly everything in PHP that is a collection) work. And this was mostly enough until recently, when special type objects started popping up – such as GMP numbers. These work very closely to native numbers – i.e. you can add them, multiply or subtract them, etc. However, though they look like numbers, there are things you can do with numbers that you can not do with them. One of these things is using it as an array index.

There’s more – we have proposals to make UString class to represent Unicode strings. There may be more to represent special types of quantities and strings. It would be only natural for these to be able to do something that numbers and strings can do – namely, be array keys.

How to use it right

This idea is not without dangers, and certainly can be abused (channeling my internal Yogi Berra – especially if you’re using it wrong).

For starters, not every object is good for using as an array key. For example, mutable objects almost never are, since if you put something under key X and then it mutates to represent something different from X – where are you going to find it? PHP also doesn’t have very good means to control mutability, at least not just yet. Also, it may not be good to use complex objects as keys, e.g. a tree having 1000 elements rarely makes a good key since it’s not clear what exactly it even means it being a key, and how to really make it so same trees would produce same key but different ones would produce different ones – scanning every element would be quite expensive.

So this feature is mostly good for value objects – i.e. objects that express some simple and usually immutable value. Of course, there may be scenarios where other objects find it useful, but those would be exceptions from a general rule.

Why not just use __toString()?

Of course, it would be very easy to say “if the object has __toString, just convert it to string and we know how to deal with those”. However, there are two problems with this:

  1. Human-readable representation of an object and value used for keys may not be the same one. As I mention in the RFC, most languages that allow object keys, have separate functions, some for technical reasons (i.e. needing number instead of string), some for semantical. I think both of these reasons are valid – some values that objects represent may be more efficiently represented as numbers, and some the developer may want to be different when expecting the human and the engine to look at it.
  2. Using __toString has the reverse side – if we use __toString, every object that has __toString becomes hash-able. But, as I noted above, we may not want every object to work this way – for some, it just makes no sense and may be even dangerous, but __toString may still make sense. It would be better if whoever designs the class explicitly allows to do this. Of course, they can choose to go back to __toString – this door is always open – but they have an option not to.

Why not just use spl_object_hash()?

This function provides the identity of the specific object – but for value objects, its identity and what it represents may not be the same. I.e. do we want two distinct objects both representing number 42 considered different? Sometimes we may want it, but if those are true value objects, we may not. It may be even more complicated if the objects have some data that changes but still represent same values. The best solution here would be to give control to the developer, since the engine can not know what which part of the object means.

And, of course, the point of not being able to control which object can be used this way is the same as above.

Inherent implementation problems and disadvantages

One point that was raised when discussing it is that the objects do not really become the array keys – instead, we “using” them as the keys, but the value derived from them in developer-specified manner is used. So, if you do a foreach loop over such array later, you do not get the original object back. You could maybe rec

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

PHP ClassesHow your PHP Programming Style Can Hurt Your Code Performance - Lately in PHP podcast episode 54 (15.12.2014, 03:42 UTC)
By Manuel Lemos
The recent article of Anthony Ferrara explaining how disabling garbage collection improved the performance of Composer exposed how certain programming styles can hurt PHP code performance. That was one of the main topics discussed by Manuel Lemos and Cesar Rodas in the episode 54 of the Lately in PHP podcast.

They also discussed proposed features for PHP 7 like built-in annotation support, Unicode character escaping, the removal of PHP 4 constructor style, among other related topics.

Now listen to the podcast, or watch the hangout video, or read the transcript to learn about the details of these interesting PHP discussions.
SitePoint PHPWriting API Documentation with Slate (12.12.2014, 17:00 UTC)

So you’ve built yourself an API. Perhaps it’s REST_ful_, REST_like_ or something else entirely. You’ve implemented authentication - be it using OAuth, HTTP Basic Auth or JSON Web Tokens. You’ve fashioned your responses using JSON, maybe XML, or even something else. Your unit and integration tests are passing, you may have a third-party service such a Runscope testing it periodically, or using JSON or XML schemas to validate your responses.

There’s one more thing, however.

Thing is, an API is only as good as its documentation. That applies if it’s for internal use only - perhaps it’s for a JavaScript-based one-page app, or a mobile application - but even more so if it’s for public consumption.

There are a number of ways in which you can put together your documentation. For the purposes of this article I’ll assume it’s web-based, whether it’s publicly available over the internet or privately held on a company intranet.

You could of course hand-code it in HTML. You could use a paid service such as Readme.io. There are even tools to help automatically generate API documentation from source-code such as Doxygen and API Blueprint, or for creating dynamic docs; such as Swagger.

Another option is Slate. Slate allows you to write your API documentation by hand using markdown, which it will then package up as a pre-styled static HTML site for you. Because it generates static HTML, hosting is straightforward - in particular, it’s a breeze to host with Github Pages. Let’s take a look at how it works, and go through an example from installation through to deployment.

Continue reading %Writing API Documentation with Slate%

Remi ColletPHP-FPM in Docker (11.12.2014, 13:31 UTC)

Use case : running php 5.3.3 on a Fedora 20 / 21 development workstation, for production deployment on  RHEL-6 (as no php 5.3 SCL exists).

This example can be easily adapted for all available PHP versions available as RPM (5.3.3 in RHEL-6, 5.4.16 in RHEL-7, 5.4.16 and 5.5.6 in RHSCL 1.2 or using a third party repository).

I use this Dockerfile:

FROM centos:6
RUN yum -y update && yum clean all
RUN yum -y install php-fpm php-mbstring php-mysql php-gd && yum clean all
RUN sed -e 's/' \
-e '/allowed_clients/d' \
-e '/catch_workers_output/s/^;//' \
-e '/error_log/d' \
-i /etc/php-fpm.d/www.conf
RUN mkdir -p /var/www/html
ENTRYPOINT /usr/sbin/php-fpm --nodaemonize


  • yum install allow to use the available packages, extension list need to be adapted to suite your need
Scripts directory:
  • the /var/www/html directory used here need to be adapted, according to your scripts location

Changes applied to the fpm pool configuration:

  • listen = 9000 to listen on all interfaces
  • remove listen.allowed_clients to allow connection from outside the container
  • remove error_log to use global error recording
  • enable catch_workers_ouput to catch the pool error in the main server

Creation of the container:

docker build -t fpm53 .

Launching the container:

docker run -v /var/www/html:/var/www/html -p fpm53

Notice :  /var/www/html directory and port 9000 (in container) mapped to port 9003 (in host)


Even if I'm a fervent supporter of Software Collections, when missing, we have a very simple way to get an operational PHP version 5.3.3 on a recent distribution (tested on Fedora 20) with the benefit of using official repository.

Brandon SavageDocumenting your code in a useful way (11.12.2014, 13:00 UTC)
Few things bring out fights among programmers quite like a fight over documentation. There are many schools of thought, from “document every line” to “let the code self-document.” For the most part, PHP seems to have agreed on a generalized standard for documentation in code, called PHPDoc. Actual blocks of documentation are referred to as […]
SitePoint PHP7 CRM Options Compatible with Drupal (10.12.2014, 17:00 UTC)

I love Drupal and end up undertaking most of my programming projects with it. I have been using it for so long that I find it far easier to push out projects with Drupal than with anything else, despite it’s infamous learning curve.

Whether you want to call Drupal a CMS (Content Management System), a CMF (Content Management Framework) or a CMSomething, the ‘C’ always stands for Content. Content is where Drupal shines and is what it’s designed for.


When an organisation is at a stage and mindset that they also want to manage their contacts and interactions effectively they will often need tools designed specifically for that function. These are generally referred to as a CRM, which stands for Client Relationship Manager or Constituent Relationship Manager, depending on the sector (For-Profit or Not-for-Profit respectively). CRMs are big business, with many free and paid options available, all with their own advantages and disadvantages.

Often these interactions that people have with your organisation will include things such as registering for an event, making a donation, becoming a member, expressing interest in a product or receiving a newsletter. This all sounds quite simple, but often representing a business rule in the digital realm is very difficult as everyone thinks ‘their way’ is ‘the only way’ and that surely every off-the-shelf system should represent them out of the box.

Continue reading %7 CRM Options Compatible with Drupal%

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