Cal EvansIt’s the Booze Talking: Podcasters on Podcasting (7.7.2015, 05:00 UTC) Link
PHP ClassesReview: Modern PHP (7.7.2015, 04:12 UTC)
Modern PHP
Title
Reviewer
Dave Smith
Category
PHP books
Publisher
O'Reilly
Author
Josh Lockhart
Summary
This book, Modern PHP, is well thought out, well laid out, well written and chock full of relevant information for PHP developers.

If you are new to PHP development, you will first want to read a book that covers the basics and then definitely get this one to bring those basic concepts up to date. For everyone else, I recommend you get this book in your library right away.

It takes valuable time to keep up to date with the latest and greatest changes in each new PHP release.

If you are like me, you will take a quick look at the change log, make a note of something that looks interesting and then have only a short amount of time to skim through those interesting bits.

In his new book, Modern PHP, Josh Lockhart has done the in depth analysis work for us.
Link
SitePoint PHPHow to Build Multi-step Forms in Drupal 8 (6.7.2015, 16:00 UTC)

In this article, we are going to look at building a multistep form in Drupal 8. For brevity, the form will have only two steps in the shape of two completely separate forms. To persist values across these steps, we will use functionality provided by Drupal’s core for storing temporary and private data across multiple […]

Continue reading %How to Build Multi-step Forms in Drupal 8%

Link
Lorna MitchellPHP 7 Benchmarks (6.7.2015, 13:30 UTC)

If you know anything at all about PHP7, you probably know it's fast. But did you know how fast? The alpha is out and looks very robust, so I decided I would create a new set of benchmarks to include it. Graphs first, disclaimers later :)

This graph shows the time it takes for each version of PHP to perform the same task, on average, with oldest PHP on the left and moving forward in time.

php-70-alpha-benchmarks

The benchmark is the Zend/bench.php that lives in the PHP sourcecode (run ten times for each version of PHP using the php7dev VM on an average laptop, and then the mean result for each version calculated). The script runs through a series of taxing algorithms, giving a sense of how quickly a series of computational instructions can be executed. So by this measure, PHP 7 is much quicker than any of the PHP 5 family. Looking at the adoption rates of PHP , many readers may well be on PHP 5.3 which is why it's included in the graph (if you're still on PHP 5.2, then you need to go back to my 5.4 benchmarks to see that in context of the other versions) - but the performance increase will be remarkable for all PHP 5 applications when they adopt the new platform. The absolute numbers here don't mean a lot but the relative performance of the various versions should hold true.

What About Real PHP Applications?

Real PHP applications will always vary but already there is a lot of data available - the best set by far is in Rasmus' slides, where he shows a selection of open source projects and measures the requests/sec that they can handle on various versions of PHP. You can find those here: http://talks.php.net/fluent15#/drupalbench (and keep arrowing right).

Basically: it's fast. So fast that all anyone can talk about is how fast it is. For a language which has seen such impressive speed improvements in the lifetime of the PHP 5 branch, this blowing me away :)

How Realistic Is It To Upgrade?

Realistic. The PHP 5 to PHP 7 platform upgrade is going to be easier than the PHP 4 to 5 upgrade was, and many applications did that successfully. I'd also say that going from PHP 5.5 or PHP 5.6 to PHP 7 is easier than going from PHP 5.2 to PHP 5.3.

To upgrade: your first step is to get to PHP 5.5 or PHP 5.6. Seriously. No PHP 7 for you unless you go there first.

What Should I Do Now?

PHP 7 isn't stable but it still absolutely needs your input, no matter who you are or what your skill level.

  • Try running your application and all its tests on PHP 7 - it's the master branch of https://github.com/php/php-src/. A really easy way to get started is to use the ready-made VM here: https://github.com/rlerdorf/php7dev.
  • If you find bugs, report them. Try to work out if it's in a library or in PHP itself, and TELL US. That's what the alpha release is for and your effort will literally change the world :)
  • Check what extensions your application uses, then make sure they are listed here https://github.com/gophp7/gophp7-ext/wiki/extensions-catalog. If not, add them. If they're not ready for PHP 7 yet, we have lots of resources to help you to compile the extension yourself and help us work out what needs doing to make sure they are ready for when you will need them.

PHP 7 is looking great, but it won't be successful without our input. Yes, the benchmarks are impressive, but if you're still reading, thankyou. The input of the community to do simple, non-scary-internal-C-code things, just to run code and verify what does and doesn't work, will make the difference between a smoother, sooner launch, and a disaster. Let's get to it.

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Link
Davey ShafikChanges to Engine Exceptions in PHP 7.0alpha2+ (6.7.2015, 11:13 UTC)

Pre-Release Software

This blog post is about PHP 7.0 which at the time of writing is currently pre-release software (7.0.0alpha2) and subject to change.

While updating my PHP 7 talk “What to Expect When You’re Expecting: PHP 7″ for the DutchPHP Conference 2 weeks ago I noticed a small but significant change to the new Engine Exceptions feature in the newly release alpha 2.

Prior to alpha 2 and as per the Engine Exceptions RFC the exception hierarchy looked like this:

BaseException (abstract)
 ├── Exception extends BaseException
      ├── ErrorException extends Exception
      └── RuntimeException extends Exception
 └── EngineException extends BaseException
      ├── TypeException extends EngineException
      ├── ParseException extends EngineException
      └── AssertionError extends EngineException

The primary reason for doing this was to ensure two things:

  1. That \EngineException‘s didn’t get caught in pre-.7.0 catch-all blocks (i.e. catch (\Exception $e) { } to preserve backwards compatible behavior (fatal erroring appropriately
  2. That it was possible to build new catch-all blocks for all both old and new exceptions using catch \BaseException $e) { }

However, for alpha2 this hierarchy changed. Engine Exceptions lost their “Exception” suffix, and became \Error and and \*Error exceptions, and the abstract \BaseException class was changed to a \Throwable interface. This makes the new exception hierarchy look like this:

Throwable interface
 ├── Exception implements Throwable
      ├── ErrorException extends Exception
      └── RuntimeException extends Exception
 └── Error implements Throwable
      ├── TypeError extends Error
      ├── ParseError extends Error
      └── AssertionError extends Error

With these changes, you still cannot create your own exception hierarchy as you cannot implement \Throwable, you must still extend from \Exception or \Error exceptions (or their children), however you can extend \Throwable and (while still extending \Exception or \Error) implement that new interface.

Personally, I prefer this hierarchy, but, as with any pre-release software: everything is subject to change!

Edit:
As pointed out to me on Twitter, there is an RFC for this change: Throwable interface RFC

Link
Matthias NobackIntroducing the SymfonyBundlePlugins package (6.7.2015, 09:38 UTC)

Bundles, not extensible

A (Symfony) bundle usually contains just some service definition files as well as some configuration options which allow the user of that bundle to configure its behavior (e.g. provide server credentials, etc.). Bundle maintainers usually end up combining lots of these options in one bundle, because they all belong to the same general concept. For example, the NelmioSecurityBundle contains several features which are all related to security, but are code-wise completely unrelated. This means that this one package could have easily been split into several packages. Please note that I'm not making fun of this bundle, nor criticizing it, I'm just taking it as a nice example here. Besides, I've created many bundles like this myself.

The common reuse principle

Moving out functionality is great for the overall design of your packages. If you've heard about the package design principles, you may know about the Common reuse principle, which offers a guideline for splitting packages: if part of a package could be used without the rest of the package, then create a separate package for it.

For regular (library) packages, it's quite easy to follow the Common reuse principle. For bundles, it's much harder, because you can't easily split the container Extension class and the Configuration class. In the case of the NelmioSecurityBundle, the Configuration class defines configuration options for all the separate parts of that bundle.

nelmio_security:
    signed_cookie:
        ...
    encrypted_cookie:
        ...
    clickjacking:
        ...
    external_redirects:
        ...
    csp:
        ...
    ...

The NelmioSecurityExtension class wires all the service definitions and thus contains knowledge about all the separate security-related features of the bundle.

This poses several problems:

  1. If the bundle maintainer wants to implement some other security-related behavior, they'd have to modify both the Extension class and the Configuration class, but the rest of the package won't be touched. This means these classes themselves don't respect the open/closed principle: behavior can't be changed without actually modifying the code.
  2. If someone else, who isn't part of the bundle maintainer's organization, wants to add security-related behavior to the bundle, they should either submit a pull request, or create their own bundle. The first option isn't a good one, because the maintainer may not agree about adopting that new behavior, or they don't accept pull requests at all. The second option isn't good either, since the bundle you just created, doesn't make sense on its own - it's basically an extension for the existing bundle. Finally, the configuration values would not be at the same location as the "main" bundle's, which is inconvenient for users.

Pondering these issues, I came to the conclusion that it might be really useful to have some kind of plugin or extension system for bundles. If the maintainer of the "main" bundle would allow users to register plugins, that bundle would basically become extensible. The plugin would be able to add configuration options in the same configuration tree as the main bundle. Then you can have:

  1. A separate definition for the configuration nodes of the plugin,
  2. A separate load() function to load and configure service definitions just for a particular plugin,
  3. Separate packages for bundle plugins (optional).

Introducing the SymfonyBundlePlugins library

Now it's time to introduce the SymfonyBundlePlugins library which offers the functionality described above. If you want to install it in your project, run composer require matthiasnoback/symfony-bundle-plugins.

The main bundle registers itself as a "bundle with plugins" by extending from the BundleWithPlugins class (let's just take the NelmioSecurityBundle again as an example):

use Matthias\BundlePlugins\BundleWithPlugins;

class NelmioSecurityBundle extends BundleWithPlugins
{
    protected function getAlias()
    {
        return 'nelmio_security';
    }
}

Now, each of the separate features of this bundle can be defined as a plugin by creating classes for them which implement Bundle

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

Link
Fabien Potencier"Create your Own Framework" Series Update (4.7.2015, 22:00 UTC)

Three years ago, I published a series of articles about how to create a framework on top of the Symfony components on this blog.

Along the years, its contents have been updated to match the changes in Symfony itself but also in the PHP ecosystem (like the introduction of Composer). But those changes were made on a public Github repository, not on this blog.

As this series has proved to be popular, I've decided a few months ago to move it to the Symfony documentation itself where it would be more exposed and maintained by the great Symfony doc team. It was a long process, but it's done now.

Enjoy the new version in a dedicated documentation section, "Create your PHP Framework", on symfony.com.

Link
SitePoint PHPTurning a Crawled Website into a Search Engine with PHP (3.7.2015, 16:00 UTC)

In the previous part of this tutorial, we used Diffbot to set up a crawljob which would eventually harvest SitePoint’s content into a data collection, fully searchable by Diffbot’s Search API. We also demonstrated those searching capabilities by applying some common filters and listing the results.

Diffbot Logo

In this part, we’ll build a GUI simple enough for the average Joe to use it, in order to have a relatively pretty, functional, and lightweight but detailed SitePoint search engine. What’s more, we won’t be using a framework, but a mere total of three libraries to build the entire application.

You can see the demo application here.

This tutorial is completely standalone, and as such if you choose to follow along, you can start with a fresh Homestead Improved instance. Note that in order to actually fully use what we build, you need a Diffbot account with Crawljob and Search API functionality.

Bootstrapping

Moving on, I’ll assume you’re using a Vagrant machine. If not, find out why you should, then come back.

On a fresh Homestead Improved VM, the bootstrapping procedure is as follows:

composer global require beelab/bowerphp:dev-master
mkdir sp_search
cd sp_search
mkdir public cache template template/twig app
composer require swader/diffbot-php-client
composer require twig/twig
composer require symfony/var-dumper --dev

In order, this:

  • installs BowerPHP globally, so we can use it on the entire VM.
  • creates the project’s root folder and several subfolders.
  • installs the Diffbot PHP client, which we’ll use to make all calls to the API and to iterate through the results.
  • installs the Twig templating engine, so we’re not echoing out HTML in PHP like peasants :)
  • installs VarDumper in dev mode, so we can easily debug while developing.

Continue reading %Turning a Crawled Website into a Search Engine with PHP%

Link
Lorna MitchellPHP 5.4 and Short Tags (3.7.2015, 09:07 UTC)

PHP 5.4 isn't exactly new; in fact the opposite is true! PHP 5.4 is end of life, but as our adoption rates show, as a community, PHP people aren't especially good at upgrading! I'm getting lots of questions now because some of the hosting providers, notably including Acquia's hosting, are finally upgrading away from those 5.2 and 5.3 offerings.

One thing in particular is tripping people up: the short open tag. I've had a few questions on this so here's the advice I am giving to clients and friends.

What Actually Changed

The short_open_tag configuration directive was removed, but the short echo syntax <?= is always available.

How To Upgrade Your Codebase

  • If you have <?= in your templates, leave it alone, those will still work
  • If you have short tags <? in your code, including in any of your libraries, then you need to do a global find-and-replace and turn them all into <?php

If you have short tags somewhere in your codebase, you probably won't get errors, you'll just suddenly start seeing PHP code in your output as PHP doesn't recognise the tag and therefore doesn't evaluate the code! To find them, try searching for <? followed by a whitespace character.

Hopefully that helps; there are a few gotchas to getting upgraded from older versions (especially from PHP 5.2) but this particular gotcha really isn't a problem and the instructions here should see you through.

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Link
Anna FilinaConverting a Joined Resultset Into a Hierarchy (2.7.2015, 20:45 UTC)

I needed nested resultsets in some projects. I’ve seen a lot of StackOverflow chatter which essentially pointed people towards Doctrine or Propel ORMs, which was overkill when you didn’t want mapping or even model classes.

I built a very small function that will transform joined results into a hierarchy. This avoids using heavy ORMs if you just need this small feature. It’s 74 lines of code and really easy to use. Since it’s open source, feel free to improve it.

You’d give it a statement like this:

SELECT album.id AS albums__id, photo.id AS albums__photos__id
FROM album
LEFT JOIN photo ON photo.album_id = album.id;

and it will produce something this:

stdClass Object
    (
        [albums] => Array
            (
                [1] => stdClass Object
                    (
                        [id] => 1
                        [photos] => Array
                            (
                                [1] => stdClass Object
                                    (
                                        [id] => 1
                                    )
                            )
                    )
            )
    )

Optionally, you can replace stdClass by your own classes with just a single parameter.

It’s on my GitHub. All the documentation is there.

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