PHP ClassesNotable PHP package: Random Access File (30.6.2016, 07:31 UTC)
By Manuel Lemos
Database management systems use special techniques to find records of data very quickly.

One of those techniques is to make each record of data in table have a fixed length, even when some record fields have a variable length.

This way, to read or write specific records in a table, it is just a matter of knowing the record position and multiplying by the length of each record.

This class takes advantage of this technique to efficiently perform several types of operations to manipulate records of data in table files.

Those operations include not only reading and writing records, but also moving records to different positions or even truncate the table files to make them smaller.

Read this article to learn more details about how this notable PHP package works.
Link
Jordi BoggianoTypo Squatting and Packagist (29.6.2016, 19:20 UTC)

Earlier this month an article was published summarizing Nikolai Philipp Tschacher's thesis about typosquatting. In short typosquatting is a way to attack users of a package manager by registering a package with a name similar to a popular package, hoping that someone will accidentally typo the name and end up installing your version of it that contains malware.

The thesis mentions https://packagist.org as a good example as we use vendor namespaces:

[...] it is much more secure, if a package is named ntschacher/GoogleScraper instead of just GoogleScraper. The reason is: If the package name is misspelled and not the author name, this will not have any consequences, because the typo version cannot be registered in this namespace, since this author name is already reserved. [...] Because package names are much longer with two attributes, it is more likely that users will copy and paste the package name instead of remembering it.

Despite this mitigating fact, it is still technically possible to squat the vendor name, so I wanted to take a look at our repository data and see if I could spot any bad actors. I wrote a script that basically does the following: Read the list of all vendor names which have packages with at least 1000 downloads, as the others are unlikely targets or at least low value targets. Check the levenshtein distance of every vendor name against all others. If the distance is 1, then it checks for package names within those two vendors to see if they have any intersecting names. Those are then candidates for being typosquatters.

What did I find? 21 vendor pairs that conflict to some degree. Only one that looked like an actual typosquatting attempt, momolog/monolog, and it even had in the package description that it was a demonstration of typosquatting. I deleted it along with 5 others packages that were useless, but the others are still in place. A lot of it is just due to people renaming their vendor names, or simply people that picked similar names but don't seem to be abusing anything.

In the future it would be nice to automate this, or prevent the creation of vendors that are too similar to popular ones. However it is reassuring to see that there is no widespread abuse going on.

Link
SitePoint PHPDisco with Design Patterns: A Fresh Look at Dependency Injection (29.6.2016, 17:00 UTC)

Dependency Injection is all about code reusability. It's a design pattern aiming to make high-level code reusable, by separating the object creation / configuration from usage.

Illustration of people's outlines dancing in a disco

Consider the following code:

<?php

class Test {

    protected $dbh;

    public function __construct(\PDO $dbh)
    {
        $this->dbh = $dbh;
    }

}

$dbh  = new PDO('mysql:host=localhost;dbname=test', 'username', 'password');
$test = new Test($dbh)

As you can see, instead of creating the PDO object inside the class, we create it outside of the class and pass it in as a dependency - via the constructor method. This way, we can use the driver of our choice, instead of having to to use the driver defined inside the class.

Our very own Alejandro Gervasio has explained the DI concept fantastically, and Fabien Potencier also covered it in a series.

There's one drawback to this pattern, though: when the number of dependencies grows, many objects need to be created/configured before being passed into the dependent objects. We can end up with a pile of boilerplate code, and a long queue of parameters in our constructor methods. Enter Dependency Injection containers!

A Dependency Injection container - or simply a DI container - is an object which knows exactly how to create a service and handle its dependencies.

In this article, we'll demonstrate the concept further with a newcomer in this field: Disco.

For more information on dependency injection containers, see our other posts on the topic here.

As frameworks are great examples of deploying DI containers, we will finish the article by creating a basic HTTP-based framework with the help of Disco and some Symfony Components.

Installation

To install Disco, we use Composer as usual:

composer require bitexpert/disco

To test the code, we'll use PHP's built-in web server:

php -S localhost:8000 -t web

As a result, the application will be accessible under http://localhost:8000 from the browser. The last parameter -t option defines the document root - where the index.php file resides.

Getting Started

Disco is a container_interop compatible DI container. Somewhat controversially, Disco is an annotation-based DI container.

Note that the package container_interop consists of a set of interfaces to standardize features of container objects. To learn more about how that works, see the tutorial in which we build our own, SitePoint Dependency Injection Container, also based on container-interop.

To add services to the container, we need to create a configuration class. This class should be marked with the @Configuration annotation:

<?php
/**
 * @Configuration
 */
 class Services {
    // ...
 }

Each container service should be defined as a public or protected method inside the configuration class. Disco calls each service a Bean, which originates from the Java culture.

Continue reading %Disco with Design Patterns: A Fresh Look at Dependency Injection%

Link
Nomad PHPStatic Analysis for PHP (29.6.2016, 14:03 UTC)

Speaker: Damien Seguy @faguo

The post Static Analysis for PHP appeared first on Nomad PHP.

Link
PHP ClassesPHP Classes Completed 17 Years: A New Type of Classes (29.6.2016, 09:07 UTC)
By Manuel Lemos
The PHP Classes site has just completed 17 years of age. It is a long time for a site that continues to evolve to serve better its users.

The big news this year is about a new project that is being launched in a separate site that aims to help other developers to learn what to do to create their own software product businesses.

Read this article to learn about the latest developments in PHP Classes,] as well the new project about creating software product businesses.
Link
SitePoint PHPHeroku Alternative: Deploy Apps with Dokku on DigitalOcean (28.6.2016, 22:00 UTC)

When Heroku announced their (quite reasonable) new limits for free apps, I realized that I would have to find another source of hosting for all the small, low-traffic projects that I currently have running on Heroku. Way back in the day, Heroku was totally free for apps that only required one dyno, but after years of abuse from jerks like me, they dropped that to eventually allowing free apps to run for 18 out of 24 hours per day (which is ok for low-traffic prototypes) and as of June 1, granting a shared pool of free hours.

Since I have such an unreasonable number of apps running on Heroku, I thought it was high time to try out Dokku. Dokku is a Heroku-like tool that allows you to deploy complex apps by simply pushing with Git. It supports Heroku buildpacks directly, so you can transition existing apps without difficulty, and has a number of plugins for datastores and other components. And, thankfully, Digital Ocean provides a pre-installed Dokku image that will spare you the trouble of installing Dokku yourself; you can just spin up a server and start Dokku-ing right away! This article will walk you through setting up a Dokku server on DigitalOcean with your own root domain and deploying a simple static site to it.

Differences between Dokku and Heroku

  • Dokku requires at least some comfort level with running your own servers; you may have to modify nginx configurations, manually configure some plugins, or turn to the system tools for debugging.
  • Dokku utilizes Docker, which is a fine platform but can add an extra layer of complexity to a server install.
  • Dokku requires root access to a VPS to install plugins, run commands, etc.

In short, you're going to need to do a bit more command line setup on Dokku than Heroku --- nothing you can't pick up along the way, but you might need to do some light reading.

Creating a Dokku Server on DigitalOcean

DigitalOcean logo

First, log in to DigitalOcean and follow this link to create a new server on DigitalOcean using the preinstalled Dokku app. Dokku requires at least 1GB of RAM, but $10/mo to host all your stuff is a pretty small price.

For your hostname, enter the base domain you want to use to host your apps. Default Dokku apps will appear at . (for example, myapp.example.com). Make sure you own this domain and register it if you need to!

Continue reading %Heroku Alternative: Deploy Apps with Dokku on DigitalOcean%

Link
SitePoint PHPSourcehunt: PHP7-Only Alternative to Laravel, HPKP, and More (28.6.2016, 17:26 UTC)

Time to promote some open source projects again!

Sourcehunt logo

paragonie/hpkp-builder [15 ★]

This library aims to make it easy to build HTTP Public-Key-Pinning headers in your PHP projects, and requires at least PHP 7.

HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.

Read more about HPKP here.


Rican7/incoming [137 ★]

Incoming is a PHP library designed to simplify and abstract the transformation of loose, complex input data into consistent, strongly-typed data structures.

// Create our incoming processor
$incoming = new Incoming\Processor();

// Process our raw form/request input into a User model
$user = $incoming->process(
    $_POST,            // Our HTTP form-data array
    new User(),        // Our model to hydrate
    new UserHydrator() // The hydrator above
);

Explaining it to any great detail is outside the scope of this short post, but in essence it allows us to precisely define what kind of input information goes through and hydrates our model, rejecting, filtering, or transforming everything else.

It's like Fractal, backwards. (Fractal makes sure the output matches a set structure, rather than input)

The library currently has one outstanding issue - and it's a discussion around a feature - but could definitely use some users and feedback! Maybe even a SitePoint post about it?

Continue reading %Sourcehunt: PHP7-Only Alternative to Laravel, HPKP, and More%

Link
Voices of the ElePHPantInterview with Dave Stokes (28.6.2016, 09:00 UTC) Link
Remi ColletPHP version 7.0 in Fedora 25 (28.6.2016, 07:43 UTC)

FESCO have approved, for Fedora 25 the upgrade from PHP 5.6 to PHP 7.0.

 

For memory, this is the result of lot of work, started more than 1 year ago:

And since, each minor release have been published in the repository on upstream announcement day.

Since yesterday, PHP version 7.0.8 is the version available in Fedora rawhide. It will be used for PHP stack QA.

Notice, removed extensions and packages:

  • php-ereg
  • php-mssql
  • php-mysql
  • php-pecl-jsonc (but php-json is back)
  • php-pecl-mongo (php-pecl-mongodb is under review)
  • php-pecl-xhprof
  • php-pecl-mysqlnd-ms
  • php-pecl-mysqlnd-qc
  • php-xcache

Some others will probably be removed later by their owner. For now, all compatible extensions have been updated: amqp, apcu, apfd, event, fann, geoip, gmagick, http, lorde_lz4, igbinary, json_post, libsodium, libvirt, lzf, mailparse, memcache, memcached, msgpack, oauth, pq, propro, raphf, redis, rrd, selinux, smbclient, solr2, ssdeep, ssh2, twig, uuid, xattr, xdebug, xmldiff, yac, yaml, zip, zmq.

Now, we have to manage and fix all the problems detected by Koschei in the php group.

And of course, I have already start working on PHP 7.1 which will probably be proposed for Fedora 26.

So things happen here first, in remi repository, which is used as upstream for Fedora and later for RHEL and CentOS.

Great thanks to my employer, and to everyone using my packages, and helping me to make this possible.

Link
PHP ClassesFast Debugging of PHP Code Using PHPEd Part 3: Remote Debugging and Remote Projects (28.6.2016, 06:33 UTC)
By Cyril Ogana
IDEs are good to help debugging your code before it goes to production, but sometimes you need to find bugs in your code that cause problems and can only be observed in production. This is one case on which remote debugging is necessary.

IDEs like PHPEd support remote debugging. You do not need to download the project files from the production server to debug your project remotely. Thanks to the remote projects feature of PHPEd, it can retrieve only the server files that you need to debug so you can start debugging remote projects very quickly.

Read this article to learn how to setup and use PHPEd to debug remote projects running in production server for instance.
Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP