PHP: Hypertext PreprocessorPHP 5.6.18 is available (4.2.2016, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.6.18. 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.18 please visit our downloads page, Windows binaries can be found on The list of changes is recorded in the ChangeLog.
SitePoint PHP9 Development Workflow Upgrades You Should Know About (3.2.2016, 17:00 UTC)

Every once in a while I run into a tool or plugin so useful I can’t not add it to my arsenal. I usually shout out tweets and try to spread the word that way, but this time I believe I’ve got such a neat (and somewhat random) collection of productivity boosting entries, they deserve a collective article.

Tips and Tricks intro image

Here are 9 new upgrades to your development workflow:

1. git-fresh

git-freshkeeps your repo fresh”. It offers a super handy set of shortcuts for some very useful git commands and combinations - it’ll prune remote branches, rebase, do merges or resets of your workspace, even stash changes effectively so you can easily push or switch branches without committing the latest changes.

It only supports Linux and OS X but since we’re big on Homestead Improved anyway, it’s all Linux for us. In fact, we’re thinking about adding this to the default Homestead Improved installation, so it’s available out of the box. Thoughts?

2. git-extras

git-extras, owned by the mythical TJ Holowaychuk, similarly extends Git’s functionality with incredibly useful additional commands. It’s a pretty old addon, but I’ve only just discovered it and I’m sure there are more of you who might find it rather handy. Examples of new commands include:

  • git setup: initializes a repo and does the first commit of present files for you. A more “bootstrappy” start of a repo, in essence.
  • git ignore: a command line “ignore” so you can add files to .gitignore without leaving the terminal or entering a text editor
  • git summary: provides a neat summary of the repo, including its age, its most active contributors, and more
  • git undo: this one is a real lifesaver - it undoes the last commit, but still keeps the changes as uncommitted so you can safely call git reset --hard to discard them once you inspect the condition of the repo with git status
  • git changelog: automatically creates and populates a changelog file with a MarkDown list of all the commit messages since the last tag was created in the repo.
  • git release x.y.z: a shortcut for creating a release. This invokes a pre-release hook (for builds/tests), creates a release tag of the given version, pushes the tags and the repo to the remote, and everything else you might do on release day
  • git fork: command line forking!
  • git squash: easier squashing of commits!

See full list here.

Continue reading %9 Development Workflow Upgrades You Should Know About%

PHP ClassesGetting User Input through SMS Text Messaging (3.2.2016, 08:33 UTC)
By Dave Smith
Setting up your Web site to interact with users through SMS text messages can be exciting. Users send their requests via SMS, your web site sends back responses, pretty cool right? Still, it is not really two-way communication until we can make requests to our users and get their responses.

Read this article to learn how to request users to input information via SMS messages, so your site can retrieve and process the information entered by the users.
Voices of the ElePHPantInterview with Christopher Pitt (2.2.2016, 05:00 UTC) Link
Thijs FerynMichael Heap – Talking about PHPBenelux, Datasift, miles & points (1.2.2016, 22:51 UTC)

Michael Heap is a developer who works at Datasift. On Thursday January 28th 2016 Michael flew from London Heathrow to

The post Michael Heap – Talking about PHPBenelux, Datasift, miles & points appeared first on Thijs Feryn's blog.

SitePoint PHPBuilding OctoberCMS Form Field Widgets like a Pro (1.2.2016, 17:00 UTC)

OctoberCMS logo

Creating your business website with any CMS requires you to make the back-end user friendly, and that means making the forms meaningful and accessible. In this article, we’re going to explore OctoberCMS form widgets and create a widget called UniqueValue, which helps the user enter a unique value. This could be useful for entering emails, usernames, post slugs, etc. Let’s get started.

Available Form Widgets

OctoberCMS provides a list of simple field types like email input, password, dropdown options, etc. The documentation has a list of all available fields. Moreover, the CMS provides some custom widgets like the media manager widget which lets you select an item from your media library or the WYSIWYG editor, Markdown editor, etc.

An interesting widget we should mention here is the repeater widget. Let’s say you have a recipes website. The cook will enter the recipe name and start filling in the ingredients. You might ask the user “how many ingredients do you need?” and based on that, you can generate the form fields. Another clean way to do it is to have a button at the bottom of the form that says Add new ingredient, which will generate the necessary fields for the cook when needed.

Here is an example configuration for the recipe form:

// models/recipe/fields.yaml

        label: Name
        type: text
        required: true
        label: Ingredients
        type: repeater
        prompt: Add new ingredient
                    label: Ingredient
                    type: text
                    label: How much
                    type: number
                    label: Unit
                    type: dropdown
                        spoon: Spoon
                        ounce: Ounce
                        # etc


Continue reading %Building OctoberCMS Form Field Widgets like a Pro%

PHP Scripts – Web Development BlogPHP download file script (30.1.2016, 14:44 UTC)
This is my favorite PHP download script. I’ve used a different more simple method until a client wanted to be able to allow their site visitors to download a large file from a password protected directory. The PHP script works on Apache web servers for all kind of files. I have used this script for […]
SitePoint PHPAppserver – Server Configuration, Dir Structure and Threads (29.1.2016, 17:00 UTC)

In the first part of our Appserver series, we discussed the very high level differences of Appserver’s architecture to standard web server stacks and got you up and running with an Appserver instance. If you missed that part, please take the time to read it.

Appserver node diagram

In this part, we will be exploring the Appserver architecture a bit more in depth. We will go through the concepts of the different contexts and the parts of Appserver you get out of the box, which cover some of the ground most of the popular PHP frameworks offer. We will also configure the web server and look into an application’s structure. Once we are finished, you should have a fair understanding about Appserver’s contexts in relation to threading, the web server, and its setup.

In subsequent parts, we’ll continue to go over the servlet engine in more detail, the persistence container, beans, the messaging system and the timer module. (Note: as this series evolved, the direction also changed, in order to include more practical information to break up the dry theory.)

The Contexts and Threading

As we had discussed in the first part, in today’s standard web server scenario, you will have a web server and either a web server module (mod_php) or a php process manager (PHP-FPM), to serve the PHP scripts/applications. The web server and the PHP process manager or module both handle their own work and threading to serve either the web page or the PHP application.

Server module gif

In this same respect, Appserver also handles threading for the client developer. However, the usage of the threads is somewhat different. The contents built within a thread aren’t constantly built and destroyed during the time appserver is running. In other words, as long as the appserver is running, the code you have given it to run, will continue to run (stay in memory) for each request. This fundamental difference is being repeated, as it is very important for understanding everything else we’ll be diving into.

Continue reading %Appserver – Server Configuration, Dir Structure and Threads%

Matthew Weier O'PhinneyAutomating GitHub Pages Builds with MkDocs (29.1.2016, 16:55 UTC)

One of the final tasks in prepping for the Expressive 1.0 release was setting up the documentation site. We'd decided to use GitHub Pages for this, and we wanted to automate builds so that as we push to the master branch, documentation is deployed.

The process turned out both simple and bewilderingly difficult. This post is intended to help others in the same situation.


In looking at the problem, we realized we had a number of requirements we needed to consider for any solution we developed.


First, we chose MkDocs for our documentation. MkDocs uses plain old Markdown, which we're already quite comfortable with due to being on GitHub, StackOverflow, Slack, and so many other services that use it. With MkDocs, you create a file, mkdocs.yml, in which you specify the table of contents, linking titles to the documents themselves. Once you run it, it generates static HTML files.

MkDocs allows you to specify a template, and ships with several of its own; the most well-known is the one used on ReadTheDocs. One reason we chose MkDocs is because it has a good-sized ecosystem, which means quite a few themes to choose from; this gave us a tremendous boost in rolling out something that both looked good and was usable.

This meant, however, that we had the following dependencies in order to build our documentation:

  • MkDocs itself.
  • One or more python extensions; in particular, we chose an extension that fixes issues with how the default Markdown renderer renders fenced code blocks that are part of bullet points or blockquotes.
  • The custom theme we were developing.

As such, this meant our build automation was going to require grabbing these items, ideally caching them between builds.

Build only when necessary

The other aspect is that there's no reason to build the documentation for every build we do on the CI server. We only want to build:

  • on the master branch,
  • when it's not a pull request,
  • if the build is a success,
  • and only once per build.

On any given build, we're actually running at least four jobs, one each for PHP 5.5, 5.6, 7, and HHVM. We don't want to build and deploy the documentation for each!


While we were doing this initially for Expressive, we also want to do the same for each of the ZF components. So any solution we built needed to be reusable with minimum fuss. If we have an update to the theme, we don't want to have to update each and every one of the component repositories! Similarly, if there are any changes to the deployment script, we don't want to have to roll it out to all the repositories.

Pushing to gh-pages

Finally, any build automation we did would be required to push to the gh-pages branch of the repository on successful build. This would require having a token or user credentials on the CI server.

Creating the automation

With the requirements in place, we could start work on the solution. Since we already use Travis-CI for our builds, we decided to re-use it for building documentation. Of course, the challenge then was creating appropriate configuration to meet our requirements.

GitHub credentials

In order to push from Travis, we need to have adequate credentials. There are a couple of ways to do this:

In both cases, you need to add information to your Travis environment. The problem, however, is that if anybody has access to these values, they can essentially commit using your credentials — which you definitely do not want to have happen! As such, you need to encrypt the value so that only Travis knows about it.

I covered encrypting your SSH key in my blog post on secure PHAR automation, and, in that particular case, I had several files needing encryption, which led to a fairly complex setup. If you have no other secrets to encrypt, go with the personal access token. For one, it simplifies security; if you find the token has been compromised, you can simply delete it from GitHub, without needing to go to the extra work of creating a new SSH key and propagating it. It also simplifies setup, as you can encrypt a single value, and simply configure it.

To encrypt the token, use the Travis CLI tool, and then paste the value into your .travis.yml. In the following, I assign it to the env variable GH_TOKEN

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

Matthew Weier O'PhinneyExpressive 1.0 in the Wild! (28.1.2016, 17:45 UTC)

A few hours ago, we pushed Expressive 1.0.

This is a huge milestone for the ZF3 initiative; I've even called it the cornerstone. It signals a huge shift in direction for the project, returning to its roots as a component library. Expressive itself, however, also signals the future of PHP applications we envision: composed of layered, single-purpose PSR-7 middleware.

I won't go into the details of the Expressive 1.0 release; you can read about it on the Zend Framework blog.

What I'm excited about is that this marks the fruition of the PSR-7 effort for me. I started work on PSR-7 due to the successes I'd had working with middleware in node.js, and wanted to see a similar ecosystem in PHP.

Today, we have:

and likely a number of others. The ecosystem has blossomed tremendously already; just take a look at the PSR-7 packages on Packagist! Chances are, if you need to accomplish something via middleware, somebody has already written it; if they haven't you can likely write it in a handful of lines of code.

Expressive started out with me remarking off-handedly that I'd like to create a project that is to Stratigility (the ZF PSR-7 middleware foundation) what Express is to Connect — in other words, a microframework providing the most often-desired features when writing web applications and APIs, but no more. What I saw with Connect and Express was that developers were able to write single-purpose middleware, share it, and layer middleware to create complex applications. The features Express layered on top of Connect simplified the most common problems of routing middleware, while Connect provided a robust, simple runtime.

Enrico was particularly excited about the concept, and got the ball rolling last summer, and it's been a whirlwind of activity ever since. And then others started playing with the code, and contributing ideas, validating the approach, and suggesting new directions. We now have a microframework in place that rivals zend-mvc in flexibility, while retaining our core principals of simplicity and minimalism.

How do I know the approach works? This site runs on Expressive already. And many of our users and contributors are already running on it. But the best validation I've read was from one of our prolific Zend Framework contributors, Michaël Gallego, on a recent thread:

For me the only reason to use Zend\Mvc (and, therefore, the eco-system around it) is the facilities provided by the module eco-systems. But even in that case, I've found out that for that, the middleware philosophy makes it so much easier. You no longer need to install Zend\Authentication that would try to map into the mvc, spending a lot of time how it works… Want an authentication? Just analyze your need, and boom, ten lines letter, it's done.

That sort of comment and realization was exactly what I experienced working in node.js almost two years ago. And now, today, it's a reality in PHP.

mwopExpressive 1.0 in the Wild! was originally published 28 January 2016 on by .
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP