I am really proud of this edition, which has been updated completely up to PHP 5.6 (the certification is currently up to 5.5), making it a great desk reference for everything new in PHP.

It includes 3 new chapters, and 2 new appendices, including one on the new debugger added in PHP 5.6, phpdbg — that’s over 80 pages of new content.

All of the new additions indicate which version they were added in, and based on a comprehensive scouring of the NEWS file, I am confident that anything worth mentioning as new in PHP has been included.

It will cover everything from SQL basics, to MySQL Native Driver, making it ideal for all skill levels, and hopefully turning even the most novice user into an accomplished developer.

This book will be published via Leanpub, and I will start making it available as soon as I have some of the beginning chapters completed — currently it’s about 30-35% complete, but the majority of it is intended to end up towards the end of the book.

If you are interested in this book, please show your support by filling out the form — this is crucial for me to gauge interest and pricing.

Xdebug 2.3: Moar var_dump()

London, UK

Friday, February 27th 2015, 08:57 GMT

This is the first article in a series about the new features in Xdebug 2.3, which was first released on February 22nd.

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.

You can include this information, by setting xdebug.overload_var_dump to 2. If the xdebug.overload_var_dump setting is set to 2, the overloaded var_dump() output now looks like:

As you can see, the file name and line number of where var_dump() were called are prepended to the output.

An already existing setting, xdebug.file_link_format, allows you to format file name and line number information so that Xdebug generates a link. This same setting is also respected by the inclusion of the file name and line number in the enhanced var_dump()
output. Setting xdebug.file_link_format to xdebug://%f:%l will then link the file name to xdebug:///home/httpd/html/test/xdebug/overload-var-dump.php:4. If we look at this as an image, we will see:

In a future version of Xdebug, it is likely that I will either wrap in the file name/line number information in the overloaded var_dump(), or change the default value of the setting to 2.

Speaker: Rebecca McGrane @RebeccaMcGrane 30 seconds can end backaches, neck strain, eye fatigue carpal tunnel and other common pains of being a full time programmer, or as I lovingly call mine Code Monkey. In 10 minutes I will share everything you need to know to stop pain, improve your cardiovascular health, boost brain cells (AKA …

Speaker: Ian Littman @iansltx A 500 with blank output is scary. Though the magic of setting exception and error handlers, I’ll show you how to, using PHP’s core error handling functions, turn the White Screen of Death into a prettier, more informative output that’ll help you solve your app’s problems rather than freak out over …

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.

In this article, I want to shine a bit of light over the new cache API. To this end, we are going to look at how we can use it in our custom modules as we are encouraged to do so much more in Drupal 8.

Additionally, I have prepared a little demonstration in the shape of a module you can install for testing the impact of the cache API. It’s a simple page that in its rendering logic makes an external API call (to a dummy JSON endpoint) and caches its results. The page then displays the
actual time it takes for this to happen, contrasting the external call time vs. the cached version time.

The new cache API

Bins

The new cache API (with the default DatabaseBackend storage) is stored in multiple bins which map to tables that start with the prefix cache_. When interacting with the cache, we always start
by requesting a cache bin:

$cache = \Drupal::cache();

Where $cache will be an instance of the DatabaseBackend object that represents the default bin (cache_default). To request a particular bin we pass in the name in the constructor:

$render_cache = \Drupal::cache('render');

Where $render_cache will represent the render cache bin (which is new in Drupal 8 and is supposed to improve render performance across the board).

Another quick fix documented here simple because it may help me (or someone else of course) in the future.

Context

For a project I’m working on right now I need to crop an image using ImageMagick. We’re using the commandline instead of Imagick because we need to execute a custom command with a lot of extra options for this specific action, since the image
will eventually be used for high-quality printing. As I was testing the command, tweaking the parameters, I eventually ended up with an error: