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.

Link
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

fields:
    name:
        label: Name
        type: text
        required: true
    ingredients:
        label: Ingredients
        type: repeater
        prompt: Add new ingredient
        form:
            fields:
                ingredient:
                    label: Ingredient
                    type: text
                how_much:
                    label: How much
                    type: number
                unit:
                    label: Unit
                    type: dropdown
                    options:
                        spoon: Spoon
                        ounce: Ounce
                        # etc

ingredients

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

Link
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 […]
Link
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%

Link
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.

Requirements

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

Technologies

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!

Reusability

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)

Link
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 https://mwop.net by .
Link
SitePoint PHPOctoberCMS CRUD – Building a Team/Project Management Plugin (27.1.2016, 17:00 UTC)

So far, we covered different aspects of OctoberCMS. This is a follow up article to discover how to use OctoberCMS for CRUD applications and take a detailed view at how to work with models, relations and controllers. Let’s get started.

OctoberCMS logo

Requirements

I will assume you already know how to set up a working installation of OctoberCMS. If not, you can check out the introduction article, or read the installation section in the documentation.

What We're Building

We are going to build a project management plugin where you can add different users to teams and assign them to projects. You can check the final result on GitHub, and feel free to suggest edits or additions to the plugins.

Setting up the Plugin

Let’s start by using the create:plugin scaffolding command to create the initial plugin structure, and define the Plugin::pluginDetails method with our plugin details.

php artisan create:plugin rafie.sitepointDemo

// Plugin.php

public function pluginDetails()
{
    return [
        'name'        => 'Project management',
        'description' => 'Manage your teams and projects.',
        'author'      => 'RAFIE Younes',
        'icon'        => 'icon-leaf'
    ];
}

Continue reading %OctoberCMS CRUD – Building a Team/Project Management Plugin%

Link
PHP ClassesPHP Articles and Reviews Report January 2016 Edition (27.1.2016, 07:02 UTC)
By Manuel Lemos
This is the December edition of the podcast hangout recorded by Manuel Lemos and Arturs Sosins to comment on the latest outstanding PHP Articles and Reviews published recently.

They commented on articles about detecting user location with IP2Location database, common PHP security issues and remedies, writing consistent PHP code, creating animated GIF images from online videos, getting automatic responses from a SMS gateway service, interacting with user site Telegram users, performing phone number verification, using the official Google search API, and creating a WordPress plugin using OOP.

They also commented on the review of PHP AJAX Cookbook book.

Listen to the podcast, or watch the hangout video to learn more about these PHP articles and reviews.
Link
Stefan KoopmanschapThe Sprint Demo (26.1.2016, 19:15 UTC)

The new year also brought a new customer for me: At the start of January I started at the Digital Solutions Center of Schiphol Airport. They have an awesome project going on, and I operate in one of the two scrum teams there.

When you're starting with a new customer that has adapted Scrum (or any form of agile), it is always interesting to see how they adopted it. Interpretation and implementation of scrum and other agile methodologies differs greatly amongst different customers. I've had customers where it worked really well, and I've seen customers where scrum was only an excuse to be able to switch priorities or scope whenever they felt like it. No, I won't mention names ;)

Overall Schiphol gets agile. Not just the developers, but throughout the organization you'll see scrum boards in the hallways or in offices. It is awesome to see this work not just inside development teams. But there's one thing I've been most impressed with from the start: The sprint demo.

To give you some context: Just about every scrum/agile project I've worked on in the past had the same form of demo: One person would start in front of a crowd of stakeholders, team members and other interested people and run through the features that were delivered in the most recent sprint. The meetings were usually boring and one-way traffic: There was little interaction because of the way the meeting was set up.

In some projects, this was recognized and stakeholders were encouraged to speak up and give feedback. So now we got feedback, which was good, but the meetings could still sometimes be really boring, or break into useless discussions between stakeholders about implementation details or even worse: internal policy decisions.

Sprint Demo, photo by Paul Nieuwdorp

Schiphol got this and took on a new style of sprint demo. Instead of having a single person present the new stories that were delivered, stakeholders are split up in smaller groups. Several team members work together (or split the group up even more) to present the stories that were completed. Some of the team members present the features while others are standing there with sticky notes to write down any feedback from the stakeholders. Stakeholders are also encouraged to take the mobile devices that are on tables throughout the area to test all of the delivered mobile stories. Throughout the demo, the groups switch to other screens/devices to see other new features. At the end of the demo most people have seen all new features and have been able to give feedback on them.

Sprint Demo, photo by Paul Nieuwdorp

One of the most important reasons to take an agile approach is to have a good, short feedback cycle: To gather feedback from the stakeholders, the business owners, and possibly even your users. By taking this more interactive approach, it is much easier to get good feedback from all parties involved. But it also ensures a good, informal contact between the development team(s) and the stakeholders. Because the groups are smaller and the whole setup is not about one-way communication, people (even team members) feel free to offer their comments, to give that feedback that you as a team need to improve the product and to ensure you build the software according the expectations and wishes of the stakeholders. And that is eventually what the agile approach is about: Building the things that people want, not what they think they want. Because the groups are smaller, there is also less useless discussion. If a discussion happens, it is usally about the new feature and not about internal policies or decisions.

I've found this form of sprint demo to be much more in the spirit of scrum and agile, and I've been impressed at the way both teams handle the demo, and the way it is received by the stakeholders. The feedback we get is valuable and the time we spend on the demo feels well spent.

So have a look at your sprint demo. See how it works right now, and have a good look at how you can improve. The above may not work for every organization, but I sure am impressed how well it works within Schiphol.

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