Subscribe: Planet PHP
Added By: Feedage Forager Feedage Grade B rated
Language: English
aws  codebuild  composer  framework  gdelt  github  independent packages  independent  package  project  service  subtree  uuid  world 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Planet PHP

Planet PHP

People blogging about PHP


Independent Packages and Subtree Splits - Paul M. Jones

Mon, 05 Dec 2016 22:07:54 +0000

You’ll sometimes see a PHP package hosted in a Github repository with the heading or subtitle “[READ ONLY] Subtree Split”. This indicates that the package is actually copied from another codebase (usually a framework) and is not intended to be worked on separately from that other codebase.

As such, a “subtree split” is not necessarily a sign of an independent package. Using a subtree split to publish a package says to me that the authors’ concentration is on the framework-as-a-whole, not on the package in-and-of- itself.

For example, Symfony does subtree splits for its components, as does Laravel for its Illuminate components. Those packages from the frameworks are not developed independently; they only move forward as part of the whole framework.

In these cases, you often end up with composer.json in the framework origin directories, which is not somehting I generally expect. Further, the framework subdirectories may have their own src/tests/docs/etc. directories. They are there so that the subtree split can have them available at their own top level, but in the origin framework, it is again something I find unexpected.

I say: if you’re going to advertise independent packages, actually write them independently. Let them be their own thing. Aura has done it that way since its beginning, and Zend Framework converted to that approach in version 3. Then you can compose the truly independent packages into a framework, instead of subtree-splitting your framework into pseudo-independent packages that are still bound to the origin framework development and release process.

The Delicious Evils of PHP - SitePoint PHP

Mon, 05 Dec 2016 17:00:42 +0000

I want to look at two PHP functions: eval and exec. They're so often thrown under the sensible-developers-never-use-these bus that I sometimes wonder how many awesome applications we miss out on.

Like every other function in the standard library, these have their uses. They can be abused. Their danger lies in the amount of flexibility and power they offer even the most novice of developers.

Let me show you some of the ways I've seen these used, and then we can talk about safety precautions and moderation.


Dynamic Class Creation

The first time I ever saw dynamic class creation was in the bowels of CodeIgniter. At the time, CodeIgniter was using it to create ORM classes. eval is still used to rewrite short open tags for systems that don't have the feature enabled...

More recently, though, my friend Adam Wathan tweeted about using it to dynamically create Laravel facades. Take a look at what the classes usually look like:

namespace Illuminate\Support\Facades;

class Artisan extends Facade
    protected static function getFacadeAccessor()
        return "Illuminate\Contracts\Console\Kernel";

This is from

These facade classes aren't facades in the traditional sense, but they do act as static references to objects stored in Laravel's service locator class. They project an easy way to refer to objects defined and configured elsewhere, and have benefits over traditional static (or singleton) classes. One of these benefits is in testing:

public function testNotificationWasQueued()
            Mockery::subset(["user" => 1])

    $service = new App\Service\UserService();

...and though these facades are simple to create, there are a lot of them. That's not the kind of code I find interesting to write. It seems Adam felt the same what when we wrote the tweet.

So, how could we create these facade classes dynamically? I haven't seen Adam's implementation code, but I'm guessing it looks something like:

function facade($name, $className) {
    if (class_exists($name)) {

        class $name extends Facade
            protected static function getFacadeAccessor()
                return $className::class;

That's a neat trick. Whether of not you use (or even like) Laravel facades, I'm guessing you can see the benefits of writing less code. Sure, this probably adds to the execution time of each request, but we'd have to profile performance to decide if it even matters much.

Continue reading %The Delicious Evils of PHP%

Building Websites with concrete5 Express - Andrew Embler

Sat, 03 Dec 2016 01:32:00 +0000


Express offers a data-first approach to concrete5 website development.

Building PHP Projects on AWS CodeBuild - Ben Ramsey

Fri, 02 Dec 2016 23:00:00 +0000

I’ve had a great time at AWS re:Invent this week, attending sessions and hanging out with some of the ShootProof team. My favorite part of the week was the “mini con” on containers. I spent Thursday immersed in sessions dedicated to deploying Docker containers on AWS. Of course, the main hightlight of re:Invent is always the keynotes and the new services and features announcements they make during the keynotes. One of the new services caught my attention, and I decided to give it a try. That service is AWS CodeBuild. CodeBuild is designed to be used as part of the AWS CodePipeline, but it may also be used by itself. Additionally, with AWS’s increased focus on their container service (ECS), it’s designed to integrate with ECS to use images you’ve stored in AWS, but it may also use images available on Docker Hub. Out of the box, CodeBuild provides some managed images that you may use to build your projects. These include environments for Android, Java, Python, Ruby, Golang, and Node. PHP is missing from this list, but since you’re able to use other images, I decided to see how easy it is to get up and running on CodeBuild with a PHP project. I chose to try out my ramsey/uuid library for a simple test. Feel free to follow along with me. Getting Started From your Amazon console, search for “CodeBuild” from the AWS Services search box, and choose it from the drop down menu that appears. Figure 1. Search for “CodeBuild” from the AWS console If you’ve not yet begun playing with CodeBuild, you’ll see a page like the one in Figure 2. Click the “Get Started” button to begin. Figure 2. Getting started with CodeBuild Configuring Your Project Figure 3 shows most of the options available when configuring a project, pre-filled for the ramsey/uuid library. I’ll step through each option to explain what’s going on. First, provide a project name. Here, I’ve named the project “ramsey-uuid.” For Source provider, choose GitHub and then click the link provided to connect to GitHub. This will take you through the OAuth dance to grant AWS with access to your GitHub account. Afterwards, the Repository drop-down will be populated with a list of your GitHub repositories. Here, I’ve selected the uuid repository. Next, you need to tell CodeBuild how to build your project by specifying an image to use. To use an image in Docker Hub, select “Specify a Docker image” for Environment image and choose “Other” for Custom image type. For the Custom image ID, I’m using benramsey/composer-uuid:latest to specify the repository, image name, and image tag. You may place a buildspec.yml file in the root of your repository to specify build commands (similar to a .travis.yml file). Since ramsey/uuid doesn’t have a buildspec.yml file, I’m specifying the Build commands directly. While there is an official Composer image on Docker Hub, it is currently based on the php:7-alpine image (see the Dockerfile for reference). The PHP image using Alpine Linux will not run on AWS CodeBuild. Until this is resolved, I recommend using Rob Loach’s composer/composer image, which is what I have used as the basis for my benramsey/composer-uuid image. Truncated by Planet PHP, read more at the original (another 4504 bytes)[...]

Using GDELT 2 with PHP to Analyze the World! - SitePoint PHP

Fri, 02 Dec 2016 17:00:11 +0000

Are you interested in political world events? Do you want to play with one of the world's largest databases? If you answered either of those questions with a yes, keep reading - this will interest you!

This article follows up on the promise to use GDELT with PHP.

I will show you a simple example of how to use GDELT through BigQuery with PHP, and how to visualize the results on a web page. Along the way, I will tell you some more about GDELT.



GDelt (the "Global Database of Events, Language and Tone") is the biggest Open Data database of political events in the world. It was developed by Kalev Leetaru (personal website), based on the work of Philip A. Schrodt and others in 2011. The data is available for download via zip files and, since 2014, is query-able via Google's BigQuery web interface and through its API, and with the GDELT Analysis Service.
The GDELT Project:

monitors the world's broadcast, print, and web news from nearly every corner of every country in over 100 languages and identifies the people, locations, organizations, counts, themes, sources, emotions, quotes, images and events driving our global society every second of every day, creating a free open platform for computing on the entire world.

In order to experiment with the GDELT dataset online, you need to have a Google account. Go to the BigQuery dashboard.

If you don't have a Google Cloud project yet, you will be prompted to create one. This is required. This project will be your working environment, so you may as well choose a proper name for it.

You can create your own queries via "Compose query". This one, for example:

SELECT EventCode, Actor1Name, Actor2Name, SOURCEURL, SqlDate
WHERE Year = 2016

Continue reading %Using GDELT 2 with PHP to Analyze the World!%

24PullRequests 2016 - Stefan Koopmanschap

Fri, 02 Dec 2016 13:45:00 +0000

Last year I already wrote about different initiatives in the period leading up to Christmas. In one of my talks this year, Level Up Your Team I've been discussing many ways of learning, and for this year I want to highlight one of the initiatives that I participated in last year, and again am trying again this year: 24 Pull Requests.

What is it?

The idea is that you send (at least) one pull request to an open source project in the days leading up to Christmas, starting on December 1st. The website will keep track of your progress and give you a list of suggested projects.

Why would you do it?

The most obvious reason is to contribute something to open source. If you, like me, earn most of your income by using open source code in your projects, this is most certainly a good reason to contribute to open source. But there's more...

When do you learn most? I learn most when I am challenged, when I am pushed out of my comfort zone. This is one of the reasons we get so much positive feedback for WeCamp, because we push people out of their comfort zone in every possible way. That same thing applies with 24 Pull Requests: You are forced to send a pull request to an open source project 24 days in a row. While they can be 24 PRs to the same project, it works better to have a look at the suggested projects and try to contribute to multiple projects, preferably ones that you don't know (that well).

Is it easy?

No. Not every project has a low hanging fruit or easy pick tag, and even if they have them, it may not be easy for someone new to the project/codebase. Also: Actually writing a PR every single day for 24 days is not easy. At least if your calendar is as busy as mine, it's not easy.

Actually last year, I completely failed. I can't find the actual stats anymore on the 24PullRequests website, but I think I sent maybe 5 or 6 pull requests. Time was mostly the reason for this failure, but I tried. And even though I didn't succeed in sending 24 pull requests, I did push myself to contribute to open source, and I did learn about some projects. For instance, I had not looked at Disco until last year. And this year, I've already contributed a simple typo to RMT, which I did not know until yesterday, and I've contributed a bugfix to Bolt, a CMS that I've been using a lot in the past year.

Join in!

So go ahead, start contributing!

PHP version 7.1.0 is released! - Remi Collet

Fri, 02 Dec 2016 05:00:00 +0000

RC6 was GOLD, so version 7.1.0 GA is just released, at planed date. A great thanks to all developers who have contributed to this new major and long awaiting version of PHP and thanks to all testers of the RC versions who have allowed us to deliver a good quality version. RPM are available in the remi-php71 repository for Fedora ≥ 23 and Enterprise Linux ≥ 6 (RHEL, CentOS) and as Software Collection in the remi-safe repository. Read the PHP 7.1.0 Release Announcement. So the tribe get a new member: Also read: New "remi-php71" repository PHP 7.1 as Software Collection Installation : read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions. Replacement of default PHP by version 7.1 installation (simplest): yum-config-manager --enable remi-php71 yum update php\* The update may fail if some installed extensions are not yet available for PHP 7, thus avoid breaking your configuration without information, thanks to ABI compatibility protection (php(zend-abi)). After checking, you may have to remove these extensions before running the update. All the extensions compatible with PHP 7 are also available for PHP 7.1 (excepted phalcon). Parallel installation of version 7.1 as Software Collection (x86_64 only, recommended for tests): yum install php71 To be noticed : EL7 rpm are build using RHEL-7.2 EL6 rpm are build using RHEL-6.8 this version will be the default version in Fedora 26, see PHP 7.1 various extensions are already available, see the PECL extension RPM status page Information, read: Migrating from PHP 7.0.x to PHP 7.1.x UPGRADING UPGRADING.INTERNALS Base packages (php) Software Collections (php70) [...]

PHP 7.1.0 Released - PHP: Hypertext Preprocessor

Thu, 01 Dec 2016 00:00:00 +0000

The PHP development team announces the immediate availability of PHP 7.1.0. This release is the first point release in the 7.x series.PHP 7.1.0 comes with numerous improvements and new features such asNullable typesVoid return typeIterable pseudo-typeClass constant visiblity modifiersSquare bracket syntax for list() and the ability to specify keys in list()Catching multiple exceptions typesMany more features and changes…For source downloads of PHP 7.1.0 please visit our downloads page, Windows binaries can be found on the PHP for Windows site. The list of changes is recorded in the ChangeLog.The migration guide is available in the PHP Manual. Please consult it for the detailed list of new features and backward incompatible changes.Many thanks to all the contributors and supporters!

PHP 7.1.0 Released - PHP: Hypertext Preprocessor

Thu, 01 Dec 2016 00:00:00 +0000

The PHP development team announces the immediate availability of PHP 7.1.0. This release is the first point release in the 7.x series.PHP 7.1.0 comes with numerous improvements and new features such asNullable typesVoid return typeIterable psuedo-typeClass constant visiblity modifiersSquare bracket syntax for list() and the ability to specify keys in list()Catching multiple exceptions typesMany more features and changes…For source downloads of PHP 7.1.0 please visit our downloads page, Windows binaries can be found on The list of changes is recorded in the ChangeLog.The migration guide is available in the PHP Manual. Please consult it for the detailed list of new features and backward incompatible changes.Many thanks to all the contributors and supporters!

Sending PHP Event Messages to Remote Logstash on Windows - SitePoint PHP

Wed, 30 Nov 2016 17:00:53 +0000

By opening this article you've endeavored yourself to expanding your knowledge of PHP applications as part of event-based distributed systems. You'll be given a quick intro into what we are referring to when we say event messages, what Logstash is, and why it is so cool.

If you've already heard of Beats or understand you can run Logstash locally to ship logs to another Logstash instance or directly to a datastore such as Elasticsearch, this article is still for you and will show you an easy-to-configure-and-run, hopefully more effective and certainly fun-to-use alternative.


Quick Intro into Event Messages and Logstash

With event messages, we gather information about events that occur in our applications, be it business-oriented decisions of the applications' users, decisions made by the applications themselves, or their failures. Each event, besides the message it conveys, is typically determined by a timestamp and a type such as informational, warning or error. A record of an event is an event log.

Additionally, there's also Event Sourcing - a somewhat different but also somewhat similar concept which you may want to check out.

There are many tools built specifically for the purpose of shipping logs to datastores for later analysis and making knowledge-based decisions. Logstash is one of them, and because of the vast number of input, output, codec and filter plugins it offers, the most popular. Out of the box, it can read from Heroku app logs, GitHub webhooks or Twitter Streaming API, create new events and send them to Graylog, IRC, or JIRA.

The event messages would ordinarily be of interest to the users of your applications, too. In an application, one page would generate events and another one would display them in an aggregated form.

Let's consider an example where the first page publishes new blog posts and the other one lists all blog posts related to PHP that have been published in the last month. The application could have talked to a relational database directly for both read and write. But with event messages it is decoupled from the database so other subscribers can be added easily, e.g. an email list or a more performant datastore like Elasticsearch.

Publishing Events

For quick comparison, let's first consider event publishing on Linux with Rsyslog, the favorite syslog of many computer systems.

Running this simple oneliner will write "Hello Wold!" to syslog.

php -r "openlog('greeting', LOG_NDELAY, LOG_USER); syslog(LOG_INFO, 'Hello World!');"

Since both Rsyslog and Logstash use RELP, a TCP based protocol for reliable delivery of event messages, sending that message to Logstash requires adding only two short statements to the Rsyslog configuration file.

$ModLoad omrelp
if $source == 'PHP-5.5.37' then :omrelp:centralserv:2514

provided that Logstash is listening on centralserv, port 2514.

Continue reading %Sending PHP Event Messages to Remote Logstash on Windows%