Christoph Rumpel, the lead developer on the BotMan PHP chatbot project, has a new post to his site sharing an "ultimate debugging guide" for those having issues with their use of the package.

Starting with BotMan to create chatbots is easy, but dealing with bugs is not. Since there are many external services like Facebook, Telegram or Slack involved, lots of things can and will go wrong. I have run into so many of these bugs and don't want you to struggle with them as I did. So here is my ultimate debugging guide.

The post is broken down into a few different sections, likely related to the questions most asked by users of the BotMan tool:

• My Chatbot Does Not Respond, What Is Wrong?
• Facebook Webhook Setup
• Code Update/Changes Are Not Shown
• The Loop Problem
• Laravel Dump Server

Each item in the list comes with a description of the issue, possible steps to resolve it and some links to other tools/resources that can help.

On his site Matthew Weier O'Phinney has a new post sharing a method he's worked up for creating a Docker image for PHP from an Alpine image that included the "tidy" PHP extension.

I've been working on building PHP Docker images for the purposes of testing, as well as to potentially provide images containing the Swoole extension. [...] This week, I decided to see if I could build Alpine-based images, as they can greatly reduce the final image size. And I ran into a problem.

One of the test-beds I use builds RSS and Atom feeds using zend-feed. When I tried one of these images, I started getting failures. [...] During an initial search, this appeared to be a problem due to libxml2 versions. [...] I realized [after debugging] that the problem was the content — which was being massaged via the tidy extension before being passed to DOMDocument::loadXML(). For some reason, the content generated was not valid XML!

In order to solve this issue (after spending a good deal of time debugging it) he went on a hunt to figure out the previous version. Once he found that it was just a few simple lines in his Dockerfile to include the right version and install it using the apk package manager (example of this is included).

On the Laravel News site they have a post about the Laravel Telescope beta that's just been announced. Laravel Telescope is an introspection and debugging tool that integrates with your Laravel application to provide details gathered during execution and issues along the way.

The first beta release of Laravel Telescope is now out and available for everyone. If you are not familiar with Telescope here is the quick overview:

Laravel Telescope is an elegant debug assistant for the Laravel framework. Telescope provides insight into the requests coming into your application, exceptions, log entries, database queries, queued jobs, mail, notifications, cache operations, scheduled tasks, variable dumps and more. Telescope makes a wonderful companion to your local Laravel development environment.

You can get the beta by installing it through Composer.

You install it the same way you'd install any other Laravel package via a composer require for laravel/telescope and run the installation and migration steps using the artisan command. This tool is only for Laravel applications and is tightly integrated with the tool. For more information on Telescope, check out its GitHub repository.

Derick Rethans has a new post with his own suggestion about using the right debugging tools to help track down a problem (based on some of his own experience debugging the MongoDB PHP extension).

A while ago, we updated the MongoDB PHP driver's embedded C library to a new version. The C library handles most of the connection management and other low level tasks that the PHP driver needs to successfully talk to MongoDB deployments, especially in replicated environments where servers might disappear for maintenance or hardware failures.

After upgrading a related library, he ended up with a failing test related to Atlas connectivity. He walks through the process he took to try and debug the issue using GDB to see where the execution was failing using various techniques. This included looking through the backtrace and, not noticing anything out of the ordinary, going for a walk. Upon returning he noticed an odd line in the backtrace that, after some additional tracking using a GDB helper, showed the problem to be with how the query options are defined and not reset in a loop.

On the Codewall.co.uk site they've posted another tutorial that will help you set up a part of your PHP development environment: XDebug and the IDE NetBeans.

NetBeans is a fantastic free IDE for not just PHP, but other languages like HTML, JavaScript, C++ and more. For PHP it comes highly prepared for being your predominant development environment. It has a whopping list of features that turbo-charge your programming like it’s auto-complete ability to name just one. A PHP development environment isn’t complete unless you have the power to debug the code you write, in this tutorial, you’ll learn how to correctly set that up.

After covering some of the prerequisites they break down the process into a few steps:

• Download XDebug
• Configuring XDebug in the PHP.ini file
• Checking configuration has been activated
• Configuring NetBeans to use the xDebug module

The last step in the process is an example of actually running the debugger and debugging some code with a breakpoint (and the resulting output)

In a quick post to the Laravel News site they mention another new feature coming in the v5.7 release of the framework: the addition of the dump server for debugging output.

At Laracon US 2018 Taylor Otwell announced that Laravel Dump Server would come packaged with Laravel in version 5.7! It will be a development dependency in laravel/laravel composer file.

Starting in Laravel 5.7 you’ll get this command out-of-the-box that allows you to dump data to the console or an HTML file instead of to the browser.

The post outlines what the "dump server" provides and provides an example of the command used to start it up. You can find out more about the dump server in this previous article.

Following up from his previous post about setting up Docker running PHP-FPM and Nginx on Windows 10, Pascal Landau has published the second part of the series taking things a step further and introducing (and integrating) PhpStorm and Xdebug for local development debugging.

In the second part of this tutorial series on developing PHP on Docker we're taking a good hard look at PhpStorm, Xdebug and how to run and debug scripts from within PhpStorm on Docker.

[...] The setup that I am going to use is for demonstration purposes only! I do not recommend that you use it "as is" as your development setup. [...] There will be a another part of this series that will deal with all of those (and some more common) problems and aims at providing a consistent development environment for all developers in a team (regardless of the OS they are using).

He then walks through the process from setup through actual script debugging:

• setting up the Docker containers/configuration
• allowing the PHP container to connect over port 2375
• running a PHP script on this container
• building a "workspace" container for Xdebug

For each step he provides the configuration changes needed, commands and screenshots of the settings panels to ensure its easy to follow along.

On the CodeWall site there's a tutorial posted showing the VS Code users out there how to set up debugging with XDebug for your PHP-based projects.

VSCode is great, the fact that it can work with a vast amount of languages help’s it cater for everyone’s taste. One special tool that comes with VSCode is the Debug feature and when configured correctly, is a dream to use. If you’ve previously worked with Visual Studio 2017 for example, you will know what I mean. This guide will go through how to set-up the PHP xDebug module to work in tandem with VSCode, completely enabling full-on functional debugging across your application.

The tutorial is broken into a few main sections: getting the basics ready, configuring the editor and an example of it in use. It provides screenshots of the editor as it goes along and links to other helpful resources (like the XDebug Chrome helper) to make the process as painless as possible.

In a post to his site Joe Ferguson, the maintainer on the Laravel Homestead project, has announced a change in the 7.1.0 version: compatibility with Zend's Z-Ray debugging tool.

Since the release of Homestead version 7.1.0 and base box version 5.1.0 Homestead now supports the Zend Z-Ray plugin for PHP 7.2. You can start leveraging the power of Z-Ray in your application with a small changes to your Homestead project.

He includes the instructions to help you upgrade your current installation to this latest versions and the configuration changes required. He also walks through the commands you'll need to use and the resulting output so you can be sure you're on the right track. The end result integrates Z-Ray directly into the site without any additional work.

On his site Derick Rethans, lead on the Xdebug project, has posted about the release of the latest version of the popular PHP debugging tool: Xdebug 2.6.

I have just released Xdebug 2.6. Xdebug 2.6 adds supports for PHP 7.2 (and drops support for PHP 5), and adds a whole bunch of new features. This article describes these new features.

Among the items he details are changes around:

• Garbage Collection Statistics
• Profiler Enhancements
• Remote Debugging Improvements
• Behavioural Changes

There are also some smaller improvements in the output of the tool allowing for custom filenames, superglobal details and the inclusion of assign-by-reference assignments. You can find out more about this latest version and get the latest from the main Xdebug site. If you'd like to show appreciation for all the hard work Derick has put into the tool, you should consider becoming a patron to show your support.