Open Source

Community News: Packagist Latest Releases for 03.29.2014 - Sat, 29/03/2014 - 15:03
Recent releases from the Packagist:

TYPO3: Sane extbase controller names

Planet-PHP - Fri, 28/03/2014 - 23:13

Extbase, TYPO3's new standard framework for writing extensions, has a bunch of characteristics a sane man can not get accustomed to. Today's example is the class names of controllers.

A controller's name is determined by the following scheme:


That's Controller\FooController. ControllerController. controllercontrollercontrollercontroller.

Fix it

Since extbase is a mature framework, there is probably a way to fix this. And there is! Easy as eating a pie.

5. Request

The controller name schema is defined in \TYPO3\CMS\Extbase\Mvc\Web\Request, property $namespacedControllerObjectNamePattern. Since there is no way to inject that property, extend the Request class and overwrite the pattern:

namespace my\extension;
class ExtBase_Request
    extends \TYPO3\CMS\Extbase\Mvc\Web\Request
     * Pattern after which the namespaced controller object name is built
     * @var string
    protected $namespacedControllerObjectNamePattern
        = '@extension\Controller_@controller';
4. ObjectManager

Request objects are created in \TYPO3\CMS\Extbase\Object\ObjectManager::get(), so we need to overwrite this method as well:

namespace my\extension;
class ExtBase_ObjectManager
    extends \TYPO3\CMS\Extbase\Object\ObjectManager
    public function get($objectName)
        $arguments = func_get_args();
        if ($objectName == 'TYPO3\\CMS\\Extbase\\Mvc\\Web\\Request') {
            $arguments[0] = '\\my\\extension\\ExtBase_Request';
        return call_user_func_array(array('parent', 'get'), $arguments);
3. Web\RequestBuilder

The object manager is instantiated in \TYPO3\CMS\Extbase\Mvc\Web\RequestBuilder, again without an official way to override it. Let's extend the class just to change a line in the docblock:

namespace my\extension;
class ExtBase_WebRequestBuilder
    extends \TYPO3\CMS\Extbase\Mvc\Web\RequestBuilder
     * @var \my\extension\ExtBase_ObjectManager
     * @inject
    protected $objectManager;
2. FrontendRequestHandler

Our web request builder comes from an @var annotation in \TYPO3\CMS\Extbase\Mvc\Web\FrontendRequestHandler. Another extended class:

namespace my\extension;
class ExtBase_FrontendRequestHandler
    extends \TYPO3\CMS\Extbase\Mvc\Web\FrontendRequestHandler
     * @var \my\extension\ExtBase_WebRequestBuilder
     * @inject
    protected $requestBuilder;
    public function getPriority()
        //more than the parent >
1. TypoScript

The frontend request handler class can finally be configured via TypoScript, without extending another class:

plugin.tx_myextension {
    mvc.requestHandlers {
        my\extension\ExtBase_FrontendRequestHandler = my\extension\ExtBase_FrontendRequestHandler

We're done! In 5 easy steps we got proper controller class names that don't drive us mad when thinking of them.

Categories: Open Source, PHP Community Can anyone suggest a php ecommerce solution that isn't terrible? - Fri, 28/03/2014 - 19:56

Over on there's a good discussion (with plenty of feedback) to a user looking for "a PHP ecommerce solution that isn't terrible" to replace their aging implementation.

I've been using Lemonstand V1 for a couple of years now, it's been really decent, though they're zoning it out to make way for V2. They're moving to a cloud hosted monthly cost, without a lot of core features from V1, which means my agency needs to find an alternative. Obviously the one that stands out is Magento, but I've logged in and clicked around and looks so bad. [...] I have recently found "" which seems to show usage stats for different ecommerce systems, though I cannot seem to find anything very good on that list which looks reliable. The most promising thing I could find was called "Sylius" ( which looks fantastic, BUT, it's newish, and there are no docs, it's not being supported by a company, it's only being held up by the community. Can anyone suggest any other alternatives to look into?

The comments to the post range from suggestions of other solutions to attempts to reinforce ones already mentioned:

  • "I'd go with the biggest names in eCommerce for PHP. That will give you the most leverage. We run our own ecommerce software and when your missing a community, features, and market share, it will be a ruff battle selling customers on your solution who are aware of software like Magento."
  • "No, sorry. No joke. Every ecommerce solution I touched is terrible. And Magento is hell."
  • "Drupal with the Ubercart module is pretty nice."
  • "You have checked out OpenCart, haven't you?"
  • "WooCommerce has been pretty good if you're on WordPress. Actually similar to Magento."
  • "In my experience none stand above the rest and all have their drawbacks, especially when you just need to getting something slightly custom up and running. We most recently used CS Cart and it was not terrible."

Check out the post for more feedback and suggestions.


Three Devs and a Maybe Podcast: Web Application Security - Part 2 - Fri, 28/03/2014 - 18:36

The Three Devs and a Maybe podcast has release their latest episode today - Web Application Security - Part 2 (Episode #17).

This week we wrap-up the top ten security risks compiled by OWASP, with discussion on topics including CSRF (Cross Site Request Forgery) and Known Component Vulnerabilities. Also included this week is a brief introduction to Hack and are thoughts on the programming language Go.

If you missed the first part of the series, you can find part one here. You can listen to this latest show by downloading the mp3 or you can subscribe to their feed and get this and other episodes as they're released.


Why your current developer is terrible

Planet-PHP - Fri, 28/03/2014 - 18:30

Earlier today I got pointed on Facebook to this article by Shamoon Siddiqui on I would very much recommend this article to both developers and managers. This is an excellent read. It also made me think about my role.

First of all: I’ve been on both sides of the above story. I’ve been the new developer hating on the previous developer, and I’ve been the guy who left hearing stories about the new developer. And to be honest: When you’re a new developer looking at an existing codebase, you’ll spot a lot of bad things. You’ll probably also spot a lot of things that you think are bad things, but are simply different than how you would’ve solved it. There is a difference!

My current role is different. As a consultant, I come into companies with existing teams (or sometimes just a single developer). I’m still in the same role though: I am the “new guy” coming in and spotting weaknesses, errors, problems etc. The difference, however, is that I’m there for this specific reason: I’m usually called in to help improve a codebase, fix a project, etc.

Over the past years of doing this work, I’ve also found out that there are many reasons why the codebase is, let’s say, suboptimal. This has to do with many things, but interestingly, very often it has very little to do with actual technical causes. Just to list a few:

  • The developer presented himself or herself as a senior, while they were actually not that senior
  • The management was not able to make decisions, causing developers to have to switch between tasks and solutions constantly
  • The developer(s) and management don’t communicate well
  • Sales and delivery are two seperate isolated parts of the company

There are more reasons, but the above are the most common reasons I’ve encountered so far. Let me dive into all of those a bit more.


I’ve seen it happen many times: A new developer is hired by a company. Their CV looks impressive: 8 years of experience with PHP. Definitely a senior developer! And since we need to focus on good quality, we need a senior! Then once the developer starts, it turns out the developer isn’t all that senior. Tasks take longer than expected, the software contains more bugs than expected, what happened?

Now, the first problem is: What is the definition of a senior developer? To me, a senior developer is not necessarily someone with lots of years experience. You could have 8 years of experience building websites and CMS’es for customers, but when you join a company building enterprise-level e-commerce solutions, you’re not a senior. Sure, you know PHP and you’ve solved the CMS-problem over and over, but what’s your experience with payment systems? Invoicing? E-commerce has a completely different set of problems to solve. Some solutions that work for a CMS might not work for E-commerce. Seniors know this. They don’t know the solution to all the problems, but they know the solution is not always the same. They communicate well, can explain a problem, and know where to look for a solution. A senior knows (s)he doesn’t know everything.

When hiring a developer, don’t blindly look at how many years of experience the candidate has with PHP (or whatever language you work with). Also have a look at the variation of the projects the developer has worked on. Unless, of course, your company operates in the same business as this developer with 8 years of experience in a specific field. Then you do want to hire the developer. Well, if everything else checks out.

Decisions, focus and quality

Talk to any developer and ask them what is one of the biggest causes of bad code, and they’ll tell you it is a lack of focus. Not being able to focus on a single task from start to finish ensures the code that is being delivered is of less quality than it could be.

One important reason for a lack of focus is not the fact that your developer checks their Facebook or Twitter regularly, or that they go out for some football or play on the gaming console three times a day. No, it’s usually that your developer(s) are not protected from distraction caused by the business.

When I worked at a product-focussed company years ago, we had this issue. On a regular basis, while working on a feature, someone would stand at the desk of a random developer and ask them to “quickly do this” or “fix this bug, it’s highly critical!”. Because of this, we never made our planning and the amount of bugs in our code was sometimes unacceptable.

Our team lead then made the best decision ever: He told us to redirect everyone to him. He would then decide on the

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

Categories: Open Source, PHP Community

Image Scraping with Symfony’s DomCrawler

Planet-PHP - Fri, 28/03/2014 - 18:00

A photographer friend of mine implored me to find and download images of picture frames from the internet. I eventually landed on a web page that had a number of them available for free but there was a problem: a link to download all the images together wasn’t present.

I didn’t want to go through the stress of downloading the images individually, so I wrote this PHP class to find, download and zip all images found on the website.

How the Class works

It searches a URL for images, downloads and saves the images into a folder, creates a ZIP archive of the folder and finally deletes the folder.

The class uses Symfony’s DomCrawler component to search for all image links found on the webpage and a custom zip function that creates the zip file. Credit to David Walsh for the zip function.

Coding the Class

The class consists of five private properties and eight public methods including the __construct magic method.

Continue reading %Image Scraping with Symfony’s DomCrawler%

Categories: Open Source, PHP Community

Matthew Weier O'Phinney: Apigility: Using RPC with HAL - Fri, 28/03/2014 - 17:48

Matthew Weier O'Phinney has a new post sharing some of the details about using RPC and HAL in the Apigility API tool from Zend. HAL stands for "Hypermedia Access Language" and basically provides a way to define objects in an API and what they relate to.

A few days ago, we released our first beta of Apigility. We've started our documentation effort now, and one question has arisen a few times that I want to address: How can you use Hypermedia Application Language (HAL) in RPC services? Hypermedia Application Language is an IETF proposal for how to represent resources and their relations within APIs. Technically, it provides two mediatypes, application/hal+json and application/hal+xml; however, Apigility only provides the JSON variant.

He introduces some of the basics of HAL and includes an example of JSON output showing metadata about the current object such as a full link to the resource. He also includes an example of the "embedded" data, additional related data, other objects, with their own structure and links. He also briefly mentions what RPC is and how it works before getting into how to set up the endpoints in your Apigility API with the help of "ContentNegotiation" functionality.


Liip Blog: HHVM and New Relic - Fri, 28/03/2014 - 16:04

In this new post to the Liip blog Christian Stocker talks about how they use the popular application and server monitoring service New Relic with the HHVM (despite no official support).

As discussed in one of my last blog posts, we really like New Relic for performance metrics and use it a lot. Unfortunately there isn't an extension for HHVM (yet) and HHVM is becoming an important part in our setup. But - a big great coincidence - New Relic released an Agent SDK and with that, an example extension for HHVM and WordPress. That was a great start for me to get behind the whole thing.

He talks about writing a HHVM extension and includes an example of the implementation. Christian also talks about the challenges around profiling data and finding out where the requests "spend their time" in the execution. There's two solutions he suggests, but they each have their tradeoffs (a recompiled/patched version or a performance hit). He provides the extension they've built in this github repository.


Community News: Packagist Latest Releases for 03.28.2014 - Fri, 28/03/2014 - 15:06
Recent releases from the Packagist:

TYPO3: Well-formed fluid templates

Planet-PHP - Fri, 28/03/2014 - 07:50

The Fluid template engine - developed for the Flow3 project - is used more and more in TYPO3's core and extensions.

Fluid templates look like XML. Every functionality is implemented as a custom XML tag or tag attribute - very unlike e.g. Smarty or Twig which invented a terse template markup language that's easy to write.

Basic fluid functionality is wrapped in tags that are prefixed with f:, like or

Unfortunately, fluid's inventors did not follow the way of XML to the end: Most fluid templates are not even well-formed.


This is a typical "partial" template:

{namespace f=TYPO3\CMS\Fluid\ViewHelpers}


Several problems make the file non-wellformed:

  1. XML declaration missing
  2. XML requires a single root tag, but the template contains multiple
  3. Namespace prefix f is not defined

Let's fix the issues:

<?xml version="1.0" encoding="utf-8"?>


The XML is well-formed now. Unfortunately, the rendered template is broken:

<?xml version="1.0" encoding="utf-8"?>
Headline 1

Text 1

<?xml version="1.0" encoding="utf-8"?>
Headline 2

Text 2


The fluid template engine renders both XML declaration and the additional root tag, although we neither want nor need it. Depending on the context of our partial, we might even get invalid html.

Attempt to fix

To get rid of the root tag in our output, we could try to use a tag with an always-true condition:

<?xml version="1.0" encoding="utf-8"?>



Let's render it and ... congratulations, you just ran into bug #56481:

#1237823695: Argument "xmlns:f" was not registered

But even if my patch gets merged some day, the XML declaration will still get rendered.

Fixing broken output

Fluid's tag supports a section attribute. It simply says that a certain section within the given template shall be rendered instead of the whole file:


Now we just have to wrap our partial's html code with a section tag:

<?xml version="1.0"?>



That's it. You can use that solution for templates and partials - but not for layouts.

Why? Why do I want well-formed fluid templates?

Well-formed XML can be validated automatically through git pre-commit hooks. Utilizing them lets developers spot errors earlier.

Categories: Open Source, PHP Community

Azure Web Sites – Continuous Deployment with Staged Publishing

Planet-PHP - Thu, 27/03/2014 - 23:04

In the beginning of the year Windows Azure Web Sites team has released a preview of the Staged Publishing functionality. The Staged Publishing allows you to create a staging site slot where you can publish a new version of the website and then test it before swapping to the production environment. This feature together with Continuous Deployment via GitHub, BitBucket or DropBox enables some very powerful deployment scenarios.

However the preview release did not provide the optimal experience for enabling Continuous Deployment (CD) for staging site. User had to configure a non-trivial workaround as described in blog post by Rick Rainey. Recently the Azure Web Sites team has released an update that fixes that problem and makes the setup of the CD with staged publishing very simple. This blog post describes how to enable CD from git repository located on BitBucket.

First, in order to use staged publishing you need to scale your web site to Standard mode:

After that you will be able to enable staged publishing:

When staged publishing is enabled you will see the staging site slot in portal.

Select it and then click on “Set up deployment from source control”:

In my case I created a repository on BitBucket where I have one simple php page just for demo purposes:

The repository gets synchronized with the staging site slot and then when I browse to it I get the result of executing the PHP script that was checked in to my repository.

The script detects whether it runs in production or staging slot by checking the Host header of the request:

<title>My first PHP page</title>
echo "<h1>Hello World! This is a new version!</h1>";

$host = $_SERVER['HTTP_HOST'];
$is_production = TRUE;
if (strpos($host, 'staging') !== FALSE)
$is_production = FALSE;

if ($is_production === TRUE)
echo "<h2>This code is running in production.</h2>";
echo "<h2>This code is running in staging.</h2>";

Now that I have tested the script in staging environment I can swap it to production environment.

After that when I browse to the production site I get the expected result:

Now let’s assume that I want to deploy a new version of my script. I make a change in the script, check it in and push it to the BitBucket repository. After that I go back

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

Categories: Open Source, PHP Community

SitePoint PHP Blog: Getting Started with PHP Extension Development via PHP-CPP - Thu, 27/03/2014 - 19:15

On the SitePoint PHP blog today there's a new tutorial from Taylor Ren showing you how to get started with PHP-CPP for creating PHP extensions. PHP-CPP is a C++ library that makes it simpler (and faster) to create PHP-specific extensions.

In your dealings with PHP, you may come to consider writing a PHP extension yourself. [...] When it comes to choosing a tool to build PHP extensions, we see two different approaches: use more pro-PHP semantics, like Zephir or use more pro-C/C++ semantics, like PHP-CPP, which will be addressed in this article. For me, the main drive to select the second approach is simple: I started my programming hobby with C/C++, so I still feel more comfortable writing those lower level modules in C/C++. PHP-CPP's official site gives a few other reasons to do so.

He walks you through the installation of the library (for now, just a git clone) and getting the needed environment set up to be able to compile and test out the extension. He helps you set up the "skeleton" files for the extension, including some sample content. He includes code for a typical "Hello World" example extension as well as its use in a sample PHP script.


Ralph Schindler: Authentication & Authorization in Apigility - Thu, 27/03/2014 - 18:04

Those interested in the Apigility project from Zend might want to check out this new post from Ralph Schindler on how it handles authentication and authorization for all of the requests.

Apigility takes a lightweight, layered, yet extensible approach to solving both problems of authentication and authorization. The infrastructure is already in place and ready to be configured to use, or for more advanced use cases: to be extended. Many of these feature can be easily explored through the Apigility user interface.

He gets into authentication first, defining it briefly before getting into the Apigility-specific implementation. He talks about the three methods (HTTP basic, HTTP digest and OAuth2) and mentions where it falls in the execution as well as some screenshots of its setup. Following this he talks about the other half of the equation, authorization. He covers the "Authentication" header, the identity types and where you can find the configuration settings. He finishes off the post with an in-depth look at the different components, events and services/models that make up the authentication and authorization system and make it work.


Matthew Turland: Travis and Composer and virtPHP, oh my! - Thu, 27/03/2014 - 17:28

Matthew Turland has a new post today to his site looking at the combination of three different technologies - TravisCI, Composer and VirtPHP - and an odd error he was getting from his build about a missing requirement "php".

In the first build, everything worked fine under 5.4 and 5.5, but upon getting to the composer install instruction to install project dependencies and PHPUnit, the job for 5.3 failed with some rather unintuitive output from Composer that implied it didn't recognize the platform package requirement that I'd provided for the minimum PHP version. [...] Since the cause of my issue wasn't immediately obvious from Composer's output, my first thought was that I needed to begin my attempt at troubleshooting the issue by replicating it on my local machine.

This is where VirtPHP came in. This tool provides an environment where you can install and configure multiple PHP configurations and switch between them easily. It provides a "glue" between the phpenv and php-build projects to make management of the results simpler. He talks about how he configured and set up his environments...and figured out his Composer problem.


ClearCode: Symfony - Project Tamed - Thu, 27/03/2014 - 16:44

On the ClearCode blog today there's a new post for the Synfomy2 users out there with some recommendations about taming your project to make it more manageable and maintainable.

When managing projects based on Symfony2, from the technical side, it is a good idea to establish a set of rules for the project. If you haven't established and implemented such rules yet, then they should be created as soon as possible. Why? Well, no matter how many people are working on the project, the code needs to look like it was written by one person. [...] Symfony documentation doesn't specifically focus on this issue, and the bundles that are written by the community have their own set of rules. [...] Learning from mistakes as you go along cannot only be costly, but also time consuming. It is good to have a starting point, something that at least has worked for someone else. This is how the idea to share the guidelines on the Taming Symfony Project came about.

They list out some of the guidelines of the project centered around various aspects of the implementation and the directory structure. They also talk about standards around the use of Doctrine, Twig and Services.


HHVM and New Relic

Planet-PHP - Thu, 27/03/2014 - 16:04

As discussed in one of my last blog posts, we really like New Relic for performance metrics and use it a lot. Unfortunately there isn't an extension for HHVM (yet) and HHVM is becoming an important part in our setup. But - a big great coincidence - New Relic released an Agent SDK and with that, an example extension for HHVM and WordPress. That was a great start for me to get behind the whole thing.

I had mainly two goals for this. Have an API compatible extension to the official New Relic PHP extension, so that we can use the same code for the Zend PHP Engine and HHVM. In our Symfony2 projects, we use the Ekino New Relic Bundle and we didn't want to have to change that. And as a bonus, make profiling as informative as possible so that we can see which part of the call takes how long.

Writing hhvm extension is surprisingly easy (at least if you have a template ;)), you can even write the easy stuff in PHP (or Hack) and only for the more advanced stuff switch to C++, see newrelic.php as an example of that.

New Relic is continuously adding new features to their Agent SDK and today, we're almost API complete (the only important thing missing is being able to change the license key or the appname from within HHVM).

If you want to use New Relic on your HHVM server, just compile and install the extension from and you're good to go. You can send attributes, errors and it will also send the time your requests needed.

Profiling data

Of course, one of the main features of New Relic is to see, where your requests spend their time. That needed a little bit more work. And I came up with two solutions.

Solution 1 needs a patched and recompiled HHVM and hooks into the HOTPROFILING of HHVM. This is disabled by default, so you have to enable this with cmake -D HOTPROFILER:BOOL=ON . before compiling HHVM (you also have to do that, if you want to use xhprof). And of course my patched HHVM, which adds the possibility to send profiling data to New Relic. You can then enable it with newrelic_profiling_enable($level) in your code, where level is the amount of levels (depth) you want to collect. If you set that too high, you won't see everything.

If you enable profiling with newrelic_profiling_enable(), it will make your requests approx. 20-50% slower (but still much faster than with Zend PHP), so it's advised not to use that all the time. If you don't use that call, I couldn't see any performance difference to an HHVM without HOTPROFILER compiled in (I'm sure there is, but it must be really low).

Solution 2 doesn't need a patched HHVM (just the HHVM New Relic extension), but will make it much slower (2-3 times as slow, depending on how many function calls you have). It uses the HHVM function fb_setprofile, which will get called on every function request and collects data this way. It's also enabled with newrelic_profiling_enable($level), the extension automatically chooses the better option.


With this new relic extension and the patched HHVM, we can now collect almost the same data into New Relic as with the official PHP extension, which helps a lot in finding performance problems and bottlenecks. It's not perfect yet, but we will get there (unless New Relic publishes an official HHVM extension before that, which would be great of course as well).

I also want to thank New Relic for their quick support and fixing when I had questions or found something dubious. Really appreciated (but of course it would sometimes have been easier, if the source code to the Agent SDK was available ;))

Feel free to use and extend the extension and patches of course are always welcome.

Categories: Open Source, PHP Community

Community News: Packagist Latest Releases for 03.27.2014 - Thu, 27/03/2014 - 15:02
Recent releases from the Packagist:

Travis and Composer and virtPHP, oh my!

Planet-PHP - Thu, 27/03/2014 - 02:26

I recently ran into an issue with one of my repos on GitHub when integrating it with Travis. When I installed dependencies with Composer and ran the PHPUnit tests on my local system running Ubuntu 13.10 and its stock PHP 5.5.3 apt package, they passed. However, I’d configured Travis to also do this under current 5.3 and 5.4 versions as well.

In the first build, everything worked fine under 5.4 and 5.5, but upon getting to the composer install instruction to install project dependencies and PHPUnit, the job for 5.3 failed with some rather unintuitive output from Composer that implied it didn’t recognize the platform package requirement that I’d provided for the minimum PHP version.

Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package php could not be found in any version, there may be a typo in the package name.

Side note: While Travis does support Composer, the version of it available by default when running a job is frequently behind the current build. I’ve brought this up with them, but it doesn’t seem they’ve addressed it as of this writing. In any case, it’s easy enough to work around by including a composer self-update instruction as part of the build like so. This ensures that you won’t be affected by any recently fixed bugs in Composer.

Since the cause of my issue wasn’t immediately obvious from Composer’s output, my first thought was that I needed to begin my attempt at troubleshooting the issue by replicating it on my local machine. My second thought was that seemed like an abysmally miserable prospect, as it would require that I have several different versions of PHP installed other than the current one on my system.

I’d heard recently about a new project recently via Twitter called virtPHP that purported to be PHP’s answer to virtualenv for Python or rvm for Ruby. Thinking that my situation seemed a great use case for it, I proceeded to install it.

First, you have to read a bit past the cursor installation instructions on the landing page of virtPHP’s web site, particularly the “Using phpenv and php-build” section of virtPHP’s README file including the portion on package requirements. virtPHP doesn’t accomplish this great feat all on its own. It actually builds on two other existing projects by Christoph Hochstrasser, phpenv and php-build, and functions (in a rather PHP-like vein) more like glue to make working with these projects and managing what they produce easier. More specifically, it provides support for things like differing per-project PHP, PECL, and PEAR configurations.

In reality, all I ended up

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

Categories: Open Source, PHP Community
Syndicate content