blog.phpdeveloper.org » PHPComposer Dependency Woes (15.5.2012, 21:35 UTC)

I spent the better part of this afternoon trying to figure out why a Composer installation wasn’t working and finally figured out the problem…it wasn’t mine.

First, a little context – I’m currently working on a testing presentation for some folks at work and I wanted to show them how to work with the Behat testing tool to create some handy functional/integration tests for our framework-based apps. I threw together a little framework (yes yes, I know) and got the PHPUnit tests set up and running in no time. When it came to the Behat tests, though, no matter what I did, I was still having a problem:

PHP Fatal error:  Class 'Goutte\Client' not found in /www/htdocs/testing-examples/app/vendor/behat/mink/src/Behat/Mink/Driver/Goutte/Client.php on line 13

No matter how I tried to configure the composer install, it always gave me this message. I tried everything I could think of and, finally, at the suggestion of Rafael Dohms, checked out the github repository for the Goutte client (a href=”http://github.com/fabpot/goutte”>here). As it turns out, in the past day or so, there’s been a large change where Fabien implemented composer support on the repo.

Apparently this was what broke things – thankfully not something obvious I was missing.

So, how did I solve it so I could see the lovely green of passing tests again? Well, if you’re familiar with composer, you know there’s a composer.lock file that’s created after you install. When you run the “composer install” and it fetches from “fabpot/goutte”:”*”, you get this latest version that has the issues. A quick modification of the composer.lock file takes care of that though:

{
    "package": "fabpot/goutte",
    "version": "master-dev",
    "source-reference": "5ecceb7c28a428fb93f283982cc4f5edfd96630b"
},

See that “source-reference” setting? Well, that can either point to the branch or version you want to pull from or it can point to a specific commit. In my case, I just pulled the hash for the commit before all of the changes and dropped it in there. Then it’s just a matter of running a “composer install” to get the code from this commit instead. Don’t run an update though – that will wipe out your manual changes to the lock file and you’ll be back to square one.

Hope this helps someone out there who might be dealing with a similar issue regarding brokenness on an external lib!

Link
Ulf WendelSome throttling for PECL/mysqlnd_ms 1.4 (15.5.2012, 13:11 UTC)
Users of MySQL Replication sometimes throttle client requests to give slaves time to catch up to the master. PECL/mysqlnd_ms 1.4, the current development version, features some throttling through the quality-of-service filter and global transaction identifier (GTID). Both the plugins client-side GTID emulation and the MySQL 5.6 built-in GTID feature can ...
Link
Fabien PotencierSami: Yet another PHP API documentation generator (15.5.2012, 11:58 UTC)

Today is my "let open source some of my private Github repositories" day, and more specifically, I'm releasing a bunch of code related to documentation.

Earlier today, I've released the Sphinx extensions I'm using to generate the Symfony documentation.

And now, I'm releasing my API documentation generator. Yes, I know that PHP already has a bunch of such generators, but I started to work on this project several years ago, when the only viable option was the old phpdocumentor.

Nowadays, phpDocumentor version 2 is probably the best option out there as it has a good architecture, it works fine, it is extensible, and quite a few big PHP projects is already using it. And that's fine. I don't want to compete with it, I don't want to replace it, I'm just open sourcing some code used by Symfony, Twig, and Silex because I'm not comfortable with closed-source software. And to be totally honest and transparent, I have not released the code before because it was not "good enough".

With this disclaimer out of the way, let's see what makes Sami "different" (compared to phpdocumentor)?

  • It uses a PHP file for configuration to give a very flexible way of tweaking the API generation;

  • It uses Twig for templating;

  • It uses a dependency injection container (Pimple) to let you override any internal class;

  • It only works with PHP 5.3 (but it can generate documentation for PHP 5.2 projects);

  • It uses the excellent PHP Parser project for PHP code parsing;

  • It is able to manage versions of your code to generate documentation for all of them in a single tree (without the overhead of re-parsing everything for each version of course).

Curious about what Sami generates? Have a look at the Symfony API.

Installation

First, get Sami from Github (or integrate it as a dependency in your project Composer file -- you are using Composer, right?):

https://github.com/fabpot/Sami
 

You can also download an archive from Github.

As Sami uses Composer to manage its dependencies, installing it is a matter of running composer:

$ composer.phar install

Check that everything worked as expected by executing the sami.php file without any arguments:

$ php sami.php

Configuration

Before generating documentation, you must create a configuration file. Here is the simplest possible one:

<?php
 
return new Sami\Sami('/path/to/symfony/src');
 

The configuration file must return an instance of Sami\Sami and the first argument of the constructor is the path to the code you want to generate documentation for.

Actually, instead of a directory, you can use any valid PHP iterator (and for that matter any instance of the Symfony Finder class):

<?php
 
use Sami\Sami;
use Symfony\Component\Finder\Finder;
 
$iterator = Finder::create()
    ->files()
    ->name('*.php')
    ->exclude('Resources')
    ->exclude('Tests')
    ->in('/path/to/symfony/src')
;
 
return new Sami($iterator

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

Link
Cal EvansInterview with Derick Rethans (15.5.2012, 05:00 UTC)

Blog:http://derickrethans.nl/
Twitter: @derickr

Show Notes:

Sponsored by:
Engine Yard

Link
blog.phpdeveloper.org » PHPQuick and Dirty REST Security (or Hashes For All!) (14.5.2012, 21:44 UTC)

So in working up a new RESTful service I’ve been tinkering with, I wanted to provide some kind of “authentication” system for it. I started to look into OAuth, but got a bit overwhelmed by everything that was involved with it. Looking for something a bit more lightweight (and simpler to implement a bit more quickly) I came across this older article with a suggestion of a private key/hash combination. I figured that could do the job nicely for a first shot, so I set to implementing it.

On the Server Side

I’m using the FuelPHP framework for this one, but that’s really only giving me a structure to work in and pull the request information from. This would work in most major frameworks (and even outside of one if you you’re a “do it my way” kind of developer). First off, let’s start with the controller side:

<?php
class Controller_User extends Controller_Rest
{
    protected function validateHash()
    {
        $request = file_get_contents('php://input');
        $requestHeaders = apache_request_headers();

        if (!isset($requestHeaders['X-Auth']) || !isset($requestHeaders['X-Auth-Hash'])) {
            $this->response('fail!',401);
        } else {
            // we have the headers - let's match!
            $user = Model_User::find()->where('public_key',$requestHeaders['X-Auth'])->get_one();

            if ($user !== null) {
                $hash = hash_hmac('sha256',$request,$user->private_key);
                return ($hash == $requestHeaders['X-Auth-Hash']) ? true : false;
            } else {
                return false;
            }
        }
    }

    public function post_index()
    {
        // return the user details here....
    }

    public function router($resource, array $arguments)
    {
        if ($this->validateHash() == false) {
            $resource = 'error';
            $arguments = array('Not Authorized',401);
        }

        parent::router($resource,$arguments);
    }
}
?>

There’s a lot going on here, so let me walk you through each of the steps:

  1. First off, we’re making a RESTful service, so we’re going to extend the Controller_Rest that Fuel comes with. It has some handy special routing. Our POST request in the example below would try to hit the “post_index” method and have its hashes checked in the process.
  2. Next up is the “validateHash” method – this is where the hard work happens:
    • The request and headers are read into variables for easier use ($request and $requestHeaders).
    • It then checks to be sure that both of our required headers are set (X-Auth and X-Auth-Hash). There’s nothing magical about these header names, so they can be switched out depending on need and naming preference.
    • If they’re there, the next step is to find the user based on the public key that was sent. This value is okay to openly share because, without the private key to correctly hash the data, your requests will fail.
    • The hash_hmac function is then used (with the “sha256″ hash type) to regenerate the hash off of the contents of the request and the private key on the found user.
  3. If all goes well, the request continues on and the “post_index” method is used. If it fails, however, the check in the “route” method of the controller makes a switch. It changes the currently requested resource to “/error/index” instead of what the user wants. This seamlessly shows the user a “Not Authorized” error message (401) if the hash checking fails.

A Client Example

Now, to help make it a bit clearer, here’s an example little script showing a curl request using the hashes:

<?php

$privateKey = 'caa68fb2160b428bd1e7d78fcf0ce2d5';
$publicKey  = '01fa456c4e2a2bc13e5c0c4977297fbb';

$data = '{"username":"happyFunBall"}';
$hash = hash_hmac('sha256',$data,$privateKey);

$headers = array(
    'X-Auth: '.$publicKey,
    'X-Auth-Hash: '.$hash
);

$ch = curl_init('http://mysite.localhost:8080/user');

curl_setopt($ch,CURLOPT_HEADER,true);
curl_setopt($ch,CURLOPT_HTTPHEADER,$headers);
curl_setopt($ch,CURLOPT_POSTFIELDS,$data);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);

$result = curl_exec($ch);
curl_close($ch);

print_r($result);
echo "\n\n";
?>

You can see that both the public and private keys are specified (but on the PHP side, not visible to the user) and are sent as the “X-Auth*” headers as a part of the request. In this case, we’re POSTing to the &

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

Link
Sean CoatesPHP as a templating language (14.5.2012, 15:06 UTC)

There’s been quite a bit of talk, recently, in PHP-land about templates and the ramifications of enforcing “pure” PHP scripts by preventing scripts from entering HTML mode. I’m not quite sure how I feel about this RFC, but it got me thinking about the whole idea of using PHP for templating in modern web apps.

For many years, I was a supporter of using PHP as a templating language to render HTML. However, I really don’t buy into the idea of adding an additional abstraction layer on top of PHP, such as Smarty (and many others). In the past year or so, I’ve come to the realization that even PHP itself is no longer ideally suited to function as the templating engine of current web applications — at least not as the primary templating engine for such apps.

The reason for this evolution is simple: modern web apps are no longer fully server-driven.

PHP, as you know, is a server technology. Rendering HTML on the server side was fine for many years, but times have changed. Apps are becoming more and more API-driven, and JSON is quickly becoming the de facto standard for API envelopes.

We can no longer assume that our data will be rendered in a browser, nor that it will be rendered exclusively in HTML. With Gimme Bar, we render HTML server-side (to reduce page load latency), in JavaScript (when adding or changing elements on an already-rendered page), in our API (upcoming in a future enhancement), in our iPhone app, and certainly in other places that I’m forgetting.

Asset rendering in Gimme Bar can be complicated — especially for embed assets. We definitely don’t want to maintain the render logic in more than one place (at least not for the main app). We regularly need to render elements in both HTML and JavaScript.

This is precisely why we don’t directly use PHP to render page elements anymore. We use Mustache (and Mustache-compatible Handlebars). This choice allows us to easily maintain one (partial) template for elements, and we can render those elements on the platform of our liking (which has been diversifying more and more lately, but is still primarily PHP and JavaScript).

Rendering elements to HTML on the server side, even if transferred through a more dynamic method such as via XHR, really limits what can be done on the display side (where “display side” can mean many things these days — not just browsers).

We try hard to keep the layers our web applications separated through patterns such as Model/View/Controller, but for as long as we’ve been doing so, we’ve often put the view bits in the wrong place. This was appropriate for many years, but now it is time to leave the rendering duties up to the layer of your application that is actually performing the view. This is often your browser.

For me, this has become the right way to do things: avoid rendering HTML exclusively on the server side, and use a techonology that can push data rendering to your user’s client.

Link
Lorna MitchellSpeaking at OSCON 2012 (14.5.2012, 07:22 UTC)

In July, I'm speaking at OSCON. Actually I have a few interesting speaking engagements coming up, and I haven't got around to adding upcoming dates to my blog yet but I'll be at phpDay in Verona next week with a talk on API Design and DPC in Amsterdam in June with a tutorial on Web Services and a talk on what OAuth is actually for.

OSCON is special because I have always wanted to go and never imagined it would actually happen. Every year I read the list of sessions from the year before, and decide that I absolutely must submit to the call for papers, regardless of how small I think my chances of being accepted are! I've submitted a couple of times in the past, excluding last year because I was newly freelance (OSCON does not cover any speaker expenses at all, they just give you a conference pass. That's kind of hard going for those of us self-funding halfway across the world, and last year, I just couldn't do it. This year I still can't really justify it but I'm going anyway!)

I have two talks, both of them brand new, and I'm excited about them both!

PHP 5.4 Features You'll Actually Use

When I told one of my local user groups (how excellent to have more than one local user group!) about this talk they said "that'll be a short talk" and I am a little worried they are right! Cool new array syntax, traits, and a web server ... am I missing anything important? To make this even easier and more fun, Rasmus has the slot immediately before mine and his abstract includes "a detailed review of new PHP 5.4 features". I feel like a spare part and I haven't even written the talk yet!

Get Some Rest: Best RESTful API Practices

This one will be lots of fun, because I firmly believe in writing services that make users, rather than textbooks, very happy. Which means that I do break the rules and I think there are times when that's acceptable. I suspect that there will be heckling, flaming, and foaming at the mouth involved but hey, I'm not there to be popular! Honestly, I love REST, I think it's possible to take it too far, and I'm only a little bit scared to say that in public :)

OSCON Conversations

OSCON does a cool thing where it opens the comments on a talk page immediately - which means that you can already go and ask questions, make requests, or leave comments on either my PHP 5.4 talk or the RESTful one and let me know what you do (and perhaps do NOT) want to hear. If you're going to OSCON or are just interested in the topics, I'm interested to hear your thoughts, either over here in the comments or over on the talks themselves!

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

Link
Mayflower Blog - PHPMagento CE 1.7 forked on GitHub (12.5.2012, 15:08 UTC)

[This blog post is also available in German.]

 

Yesterday, it was the news of the day: Magento CE 1.7 was forked on GitHub by some community people. After the spectacular departure of Yoav Kutner, then-CTO at Magento (TechCrunch reported), it was just a matter of time until Magento was forked. Indeed, as Vinai Kopp pointed out on twitter, there have been some forks of Magento already (project agent-ohm, a fork of Magento 1.3), but Mage+ seems to be another case.

What are the reasons of the fork of Magento? And what's in it for the Magento community?


Continue reading "Magento CE 1.7 forked on GitHub"
Link
Lukas SmithQuery parameter handling in Symfony2 (12.5.2012, 14:02 UTC)

So this topic has been going back and forth in my head a lot over the last months: how do we best handle query parameters in Symfony2? Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines. Now thanks to Alexander we have a solution that works. But there is the big question if this is really the right approach. For now ignore the fact that it only works with annotations for now, because that is fixable. But it does point to the question if this shouldn't be integrated into the routing configuration itself by adding query support for our implementation of uri-templates.

While this at first seems like the right place for this sort of configuration, it raises the questions of its own since path parameters (i.e. /{foo}) should be handled differently than query parameters (i.e. /{?bar}). For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

Feedback much appreciated!

Update: I have just merged the change to FOSRestBundle.

Link
NelmioNelmio is coming to a conference near you (11.5.2012, 10:19 UTC)

Here is a quick update on conferences we will attend and speak at in the next couple months. If you are attending any, feel free to come and say hi!

Next week our entire team will be at jsDay and phpDay in Verona, Italy. If you haven’t got tickets yet, hurry up because it is about to be sold out.

Pierre will talk about Backbone.js, Igor has two talks about realtime apps with websockets and the Silex microframework and I myself will be talking about managing your dependencies with Composer.

In June there are two notable events. The first is SwissJeese. A local JavaScript-oriented conference co-organized by Pierre that will be in Bern. It is free and on a Saturday so there is really no excuse not to come if you have an interest in JavaScript. Register for free on eventbrite!

The second a week later is Symfony Live in Paris which we are always looking forward to.

If you get a chance to go to both phpDay and Symfony Live, you can follow Igor’s second talk about Silex, which will be more advanced given the audience is already more familiar with the Symfony Components. If you miss Verona you can catch up on my Composer talk in Paris as well. William will hold an introduction to the Propel2 ORM and even you have no interest in PHP I will present the Redis key-value store so you can come anyway ;)

We sure hope to see some old friends and make new ones there, so if you were hesitant to come, just register before it’s too late!

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