• kalnoy/nestedset (v2.4.0) Nested Set Model for Laravel 4
  
  
• liftkit/database (v1.1.0-alpha) Database library for LiftKit
  
  
• lavender-commerce/l

The GoPHP7 project has posted their initiative to try to improve the world of PHP for extensions and make them "first class citizens of the PHP community".

The goals of gophp7(ext) [are to]: get PHP extensions running "out of the box" when PHP7 is released (no lag time), make extensions in general easier to install and use (binaries, ppas), get more people involved in extension maintenance (and travis/appveyor running on them all, killing off bugs), get more documentation written for extension writing and codify some of the "best practices" of extension writing and design (a la PSR).

They're asking for help from anyone interested, even if you don't know C (what PHP extensions are written in). The project asks for just 30 minutes a day to help achieve their goals. The page also lists out the different ways you can help including cataloging the work that needs to be done on the catalog page and working on the development systems for PHP7 to make working with the extensions easier.

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

As is mentioned in this new post to the Laravel News site, the Homestead development environment now comes with support for the Blackfire.io profiler.

Blackfire Profiler by SensioLabs automatically gathers data about your code's execution, such as RAM, CPU time, and disk I/O. Homestead makes it a breeze to use this profiler for your own applications. All of the proper packages have already been installed on your Homestead box, you simply need to set a Blackfire ID and token in your Homestead.yaml file

With the configuration set up, the only installation the user needs to make is setting up the companion extension (Chrome) for your browser.

Derick Rethans has a new post to his site starting a series of posts about the new features of Xdebug 2.3. In this new post he talks about an improvement that's been made to the output provided by var_dump with more information than before.

One of the new features relates to one of the first things that I added in the original Xdebug: making the var_dump() output "pretty". Xdebug replaces PHP's standard var_dump() function with its own version, as long as the xdebug.overload_var_dump setting is not set to 0. [...] Xdebug 2.3 enhances the overloading of var_dump() with the inclusion of the file name and line number where var_dump() is called at. This has been a long standing feature request.

He provides a few sample screenshots comparing the old and new output formats and mentions another handy setting, xdebug.file_link_format, that makes the resulting filename a link in a browser and lets you customize the format.

• playground/design (2.3.5) Playground Design Module
  
  
• playground/translate (2.0.5) Playground Translate Module
  
  
• corpsee/php-applicat

• PHP.net: PHP 5.6.6 is available
• Site News: Popular Posts for the Week of 02.20.2015
• NetTuts.com: When You're Hacked in WordPress: Staying Safe Later On
• Full Stack Radio: 10: Type Safety Roundtable with Ryan Tablada and Matt Machuga
• Community News: Latest PEAR Releases for 02.23.2015
• SitePoint PHP Blog: Introduction to Silex - A Symfony Micro-framework
• HHVM Blog: Announcing a Specification for Hack
• Community News: Packagist Latest Releases for 02.21.2015
• Magenticians: On Magento 2 being "open source" - the post-mortem
• Barry vd. Heuvel: CSRF Protection in Laravel explained

On the SitePoint PHP blog today there's a new tutorial (by Daniel Sipos) talking about the Drupal 8 cache and showing how to use it in an example, caching the latest post data pulled from the Drupal content.

Drupal 8 comes with many improvements over its predecessor we have grown to both love and hate. Next to prominent systems such as Views in core, configuration management or a useful translation service, there are also less known changes but that are equally important to know and use. One such improvement has been the cache API that solves many performance problems we have in Drupal 7.

They start with a basic introduction to the new cache handing and how the caches are separated out into different "bins" rather than all stored in one place. He includes sample code showing how to: save data to the cache, getting information back out and invalidating the cache to be handled by garbage collection. He also covers the cache tags, a feature that allows you to "tag" items across multiple caches and remove/invalidate them all at the same time. He wraps up the post getting into the more practical example showing the caching at work in a controller caching the contents of the posts to the Drupal site.

In his latest entry Benjamin Eberlei shows how he integrated Symfony and Webpack, a tool that makes it simpler to package up multiple assets (like Javascript or CSS files) and reduce them down to combined files, reducing the overhead on page loads.

Asset Management in Symfony2 is handled with the PHP based library Assetic by default, however I have never really connected to this library and at least for me it usually wastes more time than it saves. [...] While researching about React.JS I came across a tool called Webpack which you could compare to Symfony's Assetic. It is primarily focussing on bundling Javascript modules, but you can also ship CSS assets with it.

He talks about some of the main benefits to using the Webpack tool including a built-in web server to serve up the assets and a "hot reload" plugin that refreshes when assets change. He then gets into a more practical example, showing how the tool works with a typical asset structure in a Symfony application. He shows how it uses the internal server to prevent the need for a complete rebuild each time. He also shows how to install and configure it through Symfony and loading the Javascript file in your Twig template. Finally he shows how to run a build, the resulting output and the integration he mentioned with React.js.

Stephan Hochdörfer has a quick post showing how he has PHPunit up and working on an HHVM instance. His problem was that the tests were actually executing using the "php" binary, not the HHVM one.

For quite some time we run the unit tests for our libs and tools against PHP and HHVM, at least that is what I thought up to now. As it turns out I missed a minor detail. [...] What happens now is that Phing is executed via HHVM but PHPUnit will still be executed via the PHP binary because the PHPUnit shell script will look for the php binary in the PATH configuration. Since we run HHVM side-by-side with PHP on our Jenkins build nodes I was not able to point /usr/bin/php to /usr/bin/hhvm - which would be the easiest and cleanest solution. I

He shares the workaround he created, creating a symbolic link between the hhvm and php binaries and then executing the Phing task to run the tests. This is being run via Jenkins and uses it's "WORKSPACE" as a container so the main "php" binary isn't overwritten.