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.

Kevin Schroeder has a post to his site sharing some helpful tips for monitoring Magento jobs and crons to help provide a bit more information about the job and its current state.

About a month ago a client of mine was lamenting the fact that they didn’t have insight into what was going on with their cron jobs. So I did what any idiot would do and built out a service that does just that. It works with any Magento version, 1 or 2, system crons, and you can use an API to integrate it with your own system with a very minimal amount of work. I call it the 10n Job Health Vault. With Magento 1 or 2 you can have it set up and running in under 5 minutes (minus DI compilation time, of course).

The tool tracks the execution of the job and notifies you if something's wrong and it hasn't finished. This also means it can track the execution time and report back if it's slower than usual. You can find out more information about this Magento monitoring tool on its website.

On the RIPSTech.com site they've posted a warning to the WordPress users out there about a vulnerability that would allow a malicious user to delete any file in the WordPress installation, not just file uploads.

At the time of writing no patch preventing this vulnerability is available. Any WordPress version, including the current 4.9.6 version, is susceptible to the vulnerability described in this blogpost.

For exploiting the vulnerability discussed in the following an attacker would need to gain the privileges to edit and delete media files beforehand. Thus, the vulnerability can be used to escalate privileges attained through the takeover of an account with a role as low as Author, or through the exploitation of another vulnerability/misconfiguration.

The post includes more details around the impact of the issue and where in the code the problem lies. It also offers a temporary "hotfix" as a way around the issue by adding a new filter that uses the basename function to reset the thumbnail data.

On the Hackernoon site today Sebastian De Deyne has written up a tutorial showing you how to use Watchman to automatically run PHPUnit tests for your application when things change. Watchman is a tool from Facebook that watches files and directories for updates and execute actions based on the changes.

Watchman watches files and triggers actions when they change. The reasoning behing choosing Watchman: it’s easy to install, simple to configure, and reliable.

The watchman-make command - which ships with Watchman - is a specialised interface for Watchman to invoke build tools in response to file changes - exactly what we need!

In the setup he creates, Watchman is used to look for changes on files in either the project's src/ or tests/ directories and execute a bash script (code provided) that runs the tests and outputs the results. He walks through each line of the script and Watchman command, explaining how it works and what the option points to. You can see the results here of an edit to a test and the output in a Terminal window once it's saved.

The Exakat.io blog has a post with an interesting method for preventing the execution of multiple instances of a script at once - locking execution with an external indicator (like files, semaphores and streams/sockets).

Like everything, it all started from a simple problem : how to prevent multiple PHP scripts at the same time. And turned into an odyssey of learning, full of evil traps and inglorious victories. In the end, it works, that’s the most satisfying and it possibly matters to no one except me. But "the way is the goal", as said Confucius, so, I decided to share the various findings.

Exakat runs in command line, and it uses a graph database. The database is central to the processing, and it is crucial to avoid running several scripts at the same time : they will write over each other. So, the problem is simple : preventing several instances to run at the same time, on the database. In commandline, there is no web server that may serve as common place between scripts, sharing some memory and implementing a locking system. It requires to use another common ground : the system.

He shares some of the methods he tried to help prevent the simultaneous execution of the Exakat process including:

• file locking using flock
• creating a "lock" file
• making it "crash proof"
• using semaphores
• using a socket for the lock

He describes some of the issues he found when running the tool using locking inside of a Docker container and, finally, the use of sockets and streams to place a "hold" until the script closes (also preventing issues on a crash). He ends the post talking about the "final boss" in his battle for locking support - the handing off of the socket connection to another process between parent and child. The final list in the post is a list of each method he tried, their benefits and downsides (but only in certain situations).

If you've ever wanted to learn about cron jobs, how to set them up and what kind of functionality they provide then the SitePoint PHP blog has the post for you. In this comprehensive guide to cron you learn about these topics and more.

There are times when there’s a need for running a group of tasks automatically at certain times in the future. These tasks are usually administrative, but could be anything – from making database backups to downloading emails when everyone is asleep. [...] This article is an in-depth walkthrough of this program, and a reboot of this ancient, but still surprisingly relevant post.

They start by going through some of the basic terminology and syntax, where the cron files live and what a typical file format looks like. Also included are instructions on:

• how to edit the cron correctly (crontab)
• the structure of each cron entry
• how to have it run at the time you want
• editing another user's crontab
• cron permissions
• redirecting output

They also talk about executing PHP in a cron job, how to prevent overlaps with a "lock" file . There's also a mention of Anacron as a replacement for cron and a few helpful hints to help you debug when things go wrong.

In his latest post Juozas Kaziukenas shares a video of his "From PHP to Machine Code" talk he presented at the PHP UK Conference earlier this year (2016).

I recently gave a talk at a few conferences titled “From PHP to Machine Code”. It explains how compilers and interpreters work in general, where are the performance gains to be found and how I applied all of that to build PyHP. PyHP is a little toy project which showcases the basics of taking source code of a programming language and executing it.

As I mention a few times in the talk, it is completely and utterly useless for practical use, but it’s one of the fundamental skill-sets for any programmer. I think knowing how a bunch of text makes a computer do things at the low level is required knowledge for everyone.

The video of the presentation is embedded in the post or you can watch it directly over on YouTube if you'd like. In it he walks you through the entire process that happens from the time the PHP is executed all the way down to opcodes and bytecodes.

Johannes Schlüter has a post to his site that talks about references in PHP 7 and how they're "still bad" based on some of his previous findings.

I'm known for telling "Don't use references" (also as video) as those cause different problems (i.e. with foreach) and hurt performance. The reason for the performance loss is that references disable copy-on-write while most places in PHP assume copy-on-write. Meanwhile we have PHP 7. In PHP 7 the internal variable handling changed a lot among other things the reference counting moved from the zval, the container representing a variable, to the actual element. So I decided to run a little test to verify my performance assumption was still valid.

He includes his testing code that calls a function (strlen) in a loop and compares the handling against two methods, one passing by reference the other not. The results are shown in time taken to execute. He compares the results for PHP 5 and PHP 7, noting that PHP 7 is marginally better when passed by value, by-reference is still about the same.

The Zend Developer Zone has posted a tutorial showing you the basics of creating a plugin for Z-Ray, the tool from Zend that provides details and metrics around the execution of your application.

One of the great things about Z-Ray is the ability to extend it to display any info you want about your app. This is done by creating plugins. In this tutorial I’m going to describe how to create a new Z-Ray plugin. I’ll be supplying code snippets to insert in the various plugin files but of course feel free to replace it with your own code when possible.

They start by describing how Z-Ray shows its data and offering two options - the default panel or a custom panel. They choose the custom panel and show you how to:

• create the template for the panel
• make the module directory and zray.php
• and Modules.php file to define the plugin

There's also a section on how the Z-Ray plugin traces through the execution of your application, illustrating with a DummyClass. They include the code to set up the Trace and define which methods and actions to watch. Finally they relay this information back out to the custom panel view via Javascript collection and the code to show the results.

The Platform.sh blog has a post showing you how to create flamegraphs with XHProf for your application's execution and overall performance. A "flamegraph" is just a different sort of graph stacking up the execution times for the methods and functions in your application so they look more like a "flame" than just numbers.

One of the most frequent needs a web application has is a way to diagnose and evaluate performance problems. Because Platform.sh already generates a matching new environment for each Git branch, diagnosing performance problems for new and existing code has become easier than ever to do without impacting the behavior of a production site. This post will demonstrate how to use a Platform.sh environment along with the XHProf PHP extension to do performance profiling of a Drupal application and create flamegraph images that allow for easy evaluation of performance hotspots.

While they show it at work on a Platform.sh instance, the method can be altered slightly to work with your own application with the right software installed. Their example uses the brendangregg/FlameGraph library to do the majority of the graphing work. He shows how to have the code switch on XHProf during the execution and where to put the file for later evaluation. They include the resulting directories and files created from the execution and how to view the resulting (SVG-based) graphs directly in a browser.