SitePoint PHPQuick Intro: PhpCompatibility for PHPCS – Are You PHP7 Ready? (26.9.2016, 16:43 UTC)

Sooner or later, there will come a time when you will need to migrate your projects to different PHP versions. How will you check if you're compatible with a PHP version different to the one you've been developing on?

One possibility is always to install the version of PHP we want to migrate to, run php -l or something like PHPSA to check for syntax errors, check the PHP documentation for known issues with the migration and hope for the best. Or, we can use some available third party tools to check for PHP version compatibility in our projects.

analyze vector image

Check compatibility with PHPCompatibility

PHPCompatibility is a set of sniffs we can install on top of PHPCS. This tool allows us to check our project's compatibility with both newer and older versions of PHP. If you are not familiar with PHP QA tools, PHPCS is a tool which inspects PHP, JavaScript, and CSS for different code violations based on different sets of coding standards.

The current iteration of PHPCompatibility supports PHP versions up to PHP 7.

Installing PHPCompatibility

PHPCompatibility can be installed via Pear or via Composer. For this particular case, we will install PHPCS using Composer and then deploy our PHPCompatibility coding standards directly on top of it.

For a local installation:

composer require "squizlabs/php_codesniffer=2.*"

After PHPCS is installed, let's move into the PHPCS /Standards folder that's located in /vendor/squizlabs/php_codesniffer/CodeSniffer/Standards and run:

git clone https://github.com/wimg/PHPCompatibility.git

This command will deploy the PHPCompatibility coding standard directly into our standards folder, together with the coding standards already bundled in PHPCS. To check if both PHPCS and PHPCompatibility were successfully installed just run the command:

./vendor/bin/phpcs -i

This will list all the installed standards. We should see PHPCompatibility among them.

For a global installation, the same method is valid, just be sure to use Composer's global require:

composer global require "squizlabs/php_codesniffer=2.*"

and then clone PHPCompatibility into the following folder:

~/.composer/vendor/squizlabs/php_codesniffer/CodeSniffer/Standards

Continue reading %Quick Intro: PhpCompatibility for PHPCS – Are You PHP7 Ready?%

Link
Michelangelo van DamPHP 7 on macOS Sierra (26.9.2016, 12:51 UTC)

PHP 7 on macOS Sierra

Apple has released the latest version of their OS X operating system to the broad public and many have already upgraded their mac devices. But as it goes with each release, Apple likes to do things a bit different making it quite challenging for PHP developers to stay current with the latest PHP version (or other versions).

This version of mac OS (11.12) comes pre-installed with PHP 5.6.24.

PHP 5.6.24 (cli) (built: Aug  8 2016 16:58:37)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies


Good for Apple, but this version reaches end-of-life support by the end of this year, so it would be great if you could upgrade to PHP 7.0 or even play with the latest PHP 7.1 release candidates.

Of course you can always turn to Homebrew, XAMMP or whatever package manager you use for easy installations, but taking the compiling path is just as complicated. The failure is equal in most situations.

Configuring PHP on macOS Sierra triggers the following error:


apxs:Error: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.12.xctoolchain/usr/local/bin/apr-1-config not found!.
configure: error: Aborting


In this version of Apple's OS the Apache Portable Runtime was not included. You need to download it and compile it yourself.

wget http://apache.proserve.nl//apr/apr-1.5.2.tar.bz2
wget http://apache.hippo.nl//apr/apr-util-1.5.4.tar.bz2


Check the checksums!

tar -xjf apr-1.5.2.tar.bz2
tar -xjf apr-util-1.5.4.tar.bz2

cd apr-1.5.2/
./configure
make
make install

cd ../apr-util-1.5.4/
./configure --with-apr=/usr/local/apr
make
make install

sudo mkdir -p /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.12.xctoolchain/usr/local/bin/
sudo ln -s /usr/local/apr/bin/apu-1-config /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.12.xctoolchain/usr/local/bin/apu-1-config
sudo ln -s /usr/local/apr/bin/apr-1-config /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.12.xctoolchain/usr/local/bin/apr-1-config


Now you can hapily compile and run the latest PHP version on the latest OS from Apple. See my previous article Compile PHP 7 on Mac OS X 10.11 "El Capitain" for instructions.


Happy PHP-ing!

Link
SitePoint PHPMail Logging in Laravel 5.3: Extending the Mail Driver (23.9.2016, 16:00 UTC)

Laravel Logo

One of the many goodies Laravel offers is mailing. You can easily configure and send emails through multiple popular services, and it even includes a logging helper for development.

Mail::send('emails.welcome', ['user' => $user], function ($m) use ($user) {
    $m->to($user->email, $user->name)->subject('Welcome to the website');
});

This will send an email to a new registered user on the website using the emails.welcome view. It got even simpler with Laravel 5.3 using mailables (but the old syntax is still valid). Here's an example:

# Generate a new mailable class
php artisan make:mail WelcomeMail

// app/Mail/WelcomeMail.php

class WelcomeUser extends Mailable
{

    use Queueable, SerializesModels;

    public $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }

    public function build()
    {
        return $this->view('emails.welcome');
    }
}

// routes/web.php

Route::get('/', function () {
    $user = User::find(2);

    \Mail::to($user->email)->send(new WelcomeUser($user));

    return "done";
});

Laravel also provides a good starting point for sending mails during the development phase using the log driver, and in production using smtp, sparkpost, mailgun, etc. This seems fine in most cases, but it can't cover all the available services! In this tutorial, we're going to learn how to extend the existing mail driver system to add our own.

To keep our example simple and straightforward, we're going to log our emails to a DB table.

Continue reading %Mail Logging in Laravel 5.3: Extending the Mail Driver%

Link
Nomad PHPRobust Second-factor Authenticationwith PHP (23.9.2016, 15:19 UTC)

December 2016 - US
Presented By

Tim Lytle
December 15, 2016
20:00 CST

The post Robust Second-factor Authentication
with PHP
appeared first on Nomad PHP.

Link
Christian Weiskeshpub - micropub client for the shell (23.9.2016, 11:52 UTC)

Over the last weeks I have been working on shpub, a Micropub client for the shell. It allows you to publish blog posts, replies/coments and likes from the shell or programmatically.

Instagram

I wrote it because I needed a way to archive Instagram posts to a self-hosted blog. The internet-hater Instagram requires one to get approval for API clients, and only approves those that fall into a very narrow set of categories.

But thanks to the great new all-is-javascript world, Instagram data don't have to be scraped at all - simply adding ?__a=1 to one of its URLs gives you the data in JSON. Downloading all data wasn't a problem now, I only had to find a way to put the photos and videos into a blog now..

I first experimented with wp-cli, the WordPress command line interface. It kind of worked, but the theme didn't look nice, and there were some limitations I could not get around. Known on the other hand had all features I needed, a nice-looking layout - and no own API, but a Micropub endpoint.

Micropub

Micropub is a protocol for creating, updating and deleting all types of content on a server: Blog posts, replies/comments, likes, bookmarks, event reservations and more. It's backed by the W3C and currently in Draft status.

The goal is to have a standardized API to post content to your website, and you may use the client that's most suited for the job.

Currently we have generic clients like Quill, feed readers like Woodwind that have in-built commenting support, very specific ones like the Pushup-counter iOS app, an XMPP bot and more. See the Micropub client list for more information.

There are even services that act as Micropub client. For example, OwnYourGram instantly posts your own Instagram images to your blog. OwnYourCheckin does the same for Fourquare checkins.

On the other hand, there are micropub endpoints that act as proxy for other websites: silo.pub allows you to use a Micropub client to write comments on Github, Facebook or Twitter.

shpub

I needed a way to send Micropub requests to the Known instance, and there was no tool for it. So I sat down and wrote shpub with the goal to make a command line interface I can use from my instagram2micropub script.

During the process I learned a lot, found many bugs in Known's micropub endpoint and in the Wordpress micropub endpoint, and got to know Known's internals.

After some documentation work, the IndieWeb wiki now has a comparison of Micropub servers and Micropub clients.

shpub was the second Micropub client to support Media endpoints, and is - as far as I know - the only one that supports updates. It's almost feature-complete and works fine with instagram2micropub.

Get it from its homepage or github.

Link
PHP ClassesPHP and JavaScript Innovation Award Report September 2016 Edition - June 2016 nominees (23.9.2016, 07:41 UTC)
By Manuel Lemos
This is the September edition of the Innovation Award podcast hangout recorded by Manuel Lemos and Arturs Sosins to comment on the outstanding features of all the past month nominees and winners PHP and JavaScript packages, the prizes that the authors earned, starting with the nominees from the month of June 2016.

Listen to the podcast, or watch the hangout video to learn why the nominated packages were considered to be innovative, as well the current rankings of the Innovation Award Championship by author and by country.
Link
Nomad PHPRFCs of the Future: Array of Hope (21.9.2016, 20:39 UTC)

Speaker: Cal Evans @calevans In this episode of RFCs From the Future, we take a look at three RFCs that attect how arrays work in PHP 7.1

The post RFCs of the Future: Array of Hope appeared first on Nomad PHP.

Link
PHP ClassesHow Can I Get Users to Try my Software Product for the First Time (21.9.2016, 10:36 UTC)
By Manuel Lemos
Before you announce the software product that you developed, nobody knows about it. Actually if you are starting in the business, maybe nobody knows you yet.

So you need to start attracting people to at least try your product, demonstrate that you understand about the user problems and how your product can solve them.

Watch this video of a consulting session to learn about means to start attracting a list of people potentially interested in your product, so you can sell it later to them.
Link
Planet PHPPHP-FIG Alternatives: The Pros and Cons of Various Visions - SitePoint PHP (20.9.2016, 18:00 UTC)

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry's article, and offer two other possible futures for the FIG.

Fist fight illustration

PHP-FIG 3.0: Too Revisionary?

I have stated elsewhere that what I have called the "founding" vision of the FIG was to focus on member projects, find commonalities among them, and codify those commonalities. Larry condemns my statement as "revisionist history" and asserts the true founding intent was more in line with what I have called the "grand" vision (that is, an overarching standards group for all PHP coders, member projects or not).

To support his position, Larry quotes David Coallier's post of Brett Bieber's meeting notes.

The goal of this meeting was to develop a set of common standards which PHP projects can strive towards adopting.

Each project may have specific standards which may extend and further define how these standards should be used, but the goal being a set of PHP standards provided as a resource for all PHP developers.

Larry also draws from Travis Swicegood saying something similar. I will quote a little more of Travis's post than Larry did:

Below is what my vision is. It’s my vision and mine alone, but this is where I’m coming from. ... I’d love to see an officially sanctioned standard come out of our work. ... When code is published for public consumption in a year, I would love it if the first comment on blog posts or mailing list messages announcing the new code is "wow, that’s great, but you should run it through phpcs."

At first, this appears to be substantial evidence of Larry's claim. However, one should remember that a "goal going into" a meeting is not the same thing as a "result coming out of" a meeting.

So it may well be true that some of the participants had something more like the "grand" vision in mind when they first arrived. But, having been at that initial meeting myself, I personally recall the decision by the end was not to pursue the "grand" vision. Instead, it was to adopt the more limited, "for the group members" approach.

To provide more support than my own memory of the discussion, I submit the following:

  • Travis himself says in the same post linked above, "We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects."

  • Cal Evans, also present at the meeting, presents a summary narrative:

    • "To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way and we'd like you to do it to.'" (Does that mean Larry has it right after all? No, Cal corrects himself in a later email, stating "That should have read: To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way.'")

    • In that same later email, Cal also says, "This group is not setting itself above all others saying we know best. We are trying to find common ground between a lot of projects so that PHP developers world-wide can move between the code in those projects and not have to re-learn standards each time. ... While I would love to see the the standards agreed upon by this group be widely adopted by the PHP community at large, that is not a goal of the group."

  • Matthew Weier O'Phinney says, "We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. ... Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. ... If anything, we're keeping a very close eye on the community, and involving them as much as possible

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

Link
SitePoint PHPPHP-FIG Alternatives: The Pros and Cons of Various Visions (20.9.2016, 18:00 UTC)

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry's article, and offer two other possible futures for the FIG.

Fist fight illustration

PHP-FIG 3.0: Too Revisionary?

I have stated elsewhere that what I have called the "founding" vision of the FIG was to focus on member projects, find commonalities among them, and codify those commonalities. Larry condemns my statement as "revisionist history" and asserts the true founding intent was more in line with what I have called the "grand" vision (that is, an overarching standards group for all PHP coders, member projects or not).

To support his position, Larry quotes David Coallier's post of Brett Bieber's meeting notes.

The goal of this meeting was to develop a set of common standards which PHP projects can strive towards adopting.

Each project may have specific standards which may extend and further define how these standards should be used, but the goal being a set of PHP standards provided as a resource for all PHP developers.

Larry also draws from Travis Swicegood saying something similar. I will quote a little more of Travis's post than Larry did:

Below is what my vision is. It’s my vision and mine alone, but this is where I’m coming from. ... I’d love to see an officially sanctioned standard come out of our work. ... When code is published for public consumption in a year, I would love it if the first comment on blog posts or mailing list messages announcing the new code is "wow, that’s great, but you should run it through phpcs."

At first, this appears to be substantial evidence of Larry's claim. However, one should remember that a "goal going into" a meeting is not the same thing as a "result coming out of" a meeting.

So it may well be true that some of the participants had something more like the "grand" vision in mind when they first arrived. But, having been at that initial meeting myself, I personally recall the decision by the end was not to pursue the "grand" vision. Instead, it was to adopt the more limited, "for the group members" approach.

To provide more support than my own memory of the discussion, I submit the following:

  • Travis himself says in the same post linked above, "We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects."

  • Cal Evans, also present at the meeting, presents a summary narrative:

    • "To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way and we'd like you to do it to.'" (Does that mean Larry has it right after all? No, Cal corrects himself in a later email, stating "That should have read: To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way.'")

    • In that same later email, Cal also says, "This group is not setting itself above all others saying we know best. We are trying to find common ground between a lot of projects so that PHP developers world-wide can move between the code in those projects and not have to re-learn standards each time. ... While I would love to see the the standards agreed upon by this group be widely adopted by the PHP community at large, that is not a goal of the group."

  • Matthew Weier O'Phinney says, "We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. ... Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. ... If anything, we're keeping a very close eye on the community, and involving them as much as possible

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

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