The HHVM blog has a new post today sharing the results of their first open source lockdown. During this time they worked to improve not only HHVM itself but how well it supports other open source projects using it as a platform.

The HHVM team has concluded its first ever open source performance lockdown, and we’re very excited to share the results with you. During our two week lockdown, we’ve made strides optimizing builtin functions, dynamic properties, string concatenation, and the file cache. In addition to improving HHVM, we also looked for places in the open source frameworks where we could contribute patches that would benefit all engines. Our efforts centered around maximizing requests per second (RPS) with WordPress, Drupal 7, and MediaWiki, using our oss-performance benchmarking tool.

They share some of the benchmark improvements made by the updates during the session including performance boosts for WordPress & MediaWiki. They also talk about the community involvement during the event and updates made to their own tooling too. The post then spends some time talking about their methodology on development and testing during the lockdown and how the results compare pre- and post-lockdown. The remainder of the post looks at some more specific issues and covers a few technical notes about software used and how the results were reported.

Derick Rethans has posted a new article in his series highlighting some of the changes in the latest release of Xdebug (v2.3). In this new post he talks about some of the improvements in the trace file functionality.

Trace files are a way to document every function call, and if you enable it, variable assignment and function's return values — including when these functions were called, and how much memory PHP was using at the moment of function entry (and exit). Xdebug 2.3 adds a new type of parameter rendering for stack traces and function traces through the xdebug.collect_params setting.

This new setting allows much more information to be reported back in the trace results, adding on a serialized version of the value of variables. He also shows the output results (human-readable) that shows the memory usage and time index for the execution. He also shows the new handling to include return values in the trace output using the "xdebug.trace_format" handling.

In the latest in his series covering some of the improvements in the latest Xdebug release, Derick Rethans has posted this new article detailing some of the performance enhancements related to remote debugging that come with this new version.

This is the fourth article in a series about new features in Xdebug 2.3, which was first released on February 22nd. In this article we are looking at the improvements towards "remote" debugging.

The updates include showing the values of user-defined constants, being able to set an exception breakpoint on all exceptions and additional features around debugging the exceptions themselves. The output now includes the exception's error code and which exception the flow was broken on (though in his example of PHPStorm, the IDE won't report that information back). The last change he mentions is a change that reverts the output to a log if it can't write to a socket (usually SELinux related).

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.

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.

As well as massive performance improvements, PHP 7's change / feature list is already looking great. You can find most of the features that have been accepted or are under discussion on the PHP Dev Wiki: RFCs section. But what changes would make a difference to you? What would you really like to see make it in (already suggested or a new suggestion)?

Here's just a few of the suggestions made by fellow Reddit users:

fixing inconsistencies in naming

sandboxed eval

a complete rework of the standard library

the introduction of generics

adding enum functionality

type aliasing

stack traces for fatal errors

Check out the full post for more ideas and feedback from other members of the community too. It's an interesting list of suggestions, some that are even already in the works.

The Acquia blog (of the Drupal community) has posted another in their series of guest posts with members of the wider PHP community. In this latest post well known PHP speaker and developer Michelangelo van Dam talks about PHP as a language that's "Under the Hood, Running the Web".

Most non-technical people out on the Web haven't heard of PHP before. They might not have even heard of many of the products that were built with this technology like Drupal, Magento, or WordPress. And together with other products built with PHP, these run about 83% of all internet web applications. The technology of PHP is very important to an enormous number of businesses, governments, and organisations around the world, so even though people might not be familiar with the language itself, there’s a very good chance they’ve used it online today.

He talks about the recent movements in the PHP community to be more standards-driven and focusing on better performance overall (both in applications and the language itself). He points to the work the Drupal community has done adopting Symfony components and the gains it gives them. He also mentions the huge impact things like Composer and the PHP Framework Interoperability Group have had on the PHP community and ecosystem.

Yes, the future of PHP looks very promising and the community is on a roll. [...] With strong communities working hard on each technological level and better able to cooperate than ever before, PHP will prevail where other technologies have failed. And let's have fun while we’re at it!

In the latest post to the SitePoint PHP blog Adedayo Adeniyi talks about Joomla's "coming of age" and some of the changes that have come/are coming in the latest versions.

Over the years, there has been a healthy rivalry between the main CMSes in use on the planet: WordPress, Drupal, and Joomla!, and all three have hosts of die-hard fans that would pitch for their favorites over the others any day. Don’t worry, I’m not about to add to the high pile of subjective CMS comparison posts available on the web. Instead, I will briefly review all the recent changes in Joomla! that have modernized it for the present day developer – from version 3.0 onwards (currently 3.3).

She talks about some of the most recent changes including easier updating, the tool being mobile friendly out of the box and more flexible user access handling. She also mentions the improvements in "developer friendliness" and that it's become a good bit more security-conscious. Other topics mentioned include the JED (Joomla Extension Directory), smart search/tagging and improved database handling.

On the HHVM blog today they've posted some updates about the language that helps power the HHVM (HipHop Virtual Machine), Hack, and the most recent changes and improvements made to the language.

One thing we haven’t talked about much is the progress and evolution of the language itself. We’ve been busy driving the language forward, improving its PHP base as well as adding new features requested inside and outside Facebook to further increase developers’ productivity. But unless you’re the sort of person that reads every commit going into the HHVM github repository or every change to our docs site, you probably have no idea about any of these changes since we haven’t talked much about them yet.

This post is a "kickoff" of a series of posts they'll be doing covering some of the major changes to the language including:

Chances are if you have been in web development for any amount of time you have done some work with PHP and maybe it was a great experience like it was for me, or perhaps it was hours and hours of digging through WordPress code to figure out why a plugin wasn’t working. [...] A friend from U of W was giving me a hand setting up the catalog and introduced me to PHP. He was able to build the whole catalog, at least a basic first version, in one afternoon. You can imagine I was pretty excited about something that I thought was going to be weeks of cutting and pasting being done in a few short lines of PHP code. From then I was hooked.

He looks at a brief history of PHP, from its beginnings as a set of simple scripts by Rasmus Lerdorf out to the current push and support of the language by big companies like Facebook. Despite all of this, he points out that PHP "went wrong" somewhere along the way thanks to things like bad tutorials and practices. He talks about the GoPHP5 initiative and some of the signs of improvement in PHP: frameworks, Composer, the FIG and the "PHP renaissance." He looks into the future and sees only improvement thanks to better tutorial content (on various sites) and the increased amount of cooperation between developers wanting to make the language better.