How should I log a PHP array?
If you work as a PHP developer this is probably a question you’ve asked yourself before. There are quite a few guides you’ll find online in regards to this subject.
print_rto gracefully debug PHP
Typically, they point to PHP’s
Unfortunately, they’re wrong
PSA: print_r() for logs sucks...— Max Chadwick (@maxpchadwick) November 30, 2016
So why, exactly, does
print_r suck for logging? Allow me to elaborate.
Recently, I caught wind of an issue which was reported by the client as follows…
Customers are getting error screens stating that their request was blocked.
At first glance, it smelled like an issue at the WAF (web application firewall).
A quick call with our hosting provider later, we confirmed that requests were, indeed, violating the WAF’s “max header size” policy. Let’s take a look at the what and the why.
The plugin was spurred by my own contemplation about removing the
/blog prefix from the URLs on this blog, an action which, at the time of writing this, I still haven’t taken. If you just up and change URLs, you’ll wind up with a bunch of backlinks that 404.
jekyll-redirect-from can help with creating redirects, however it requires updating the front matter on all existing posts with a
redirect_from element referencing the old URL. Doing this manually is a lot of work, and error prone. So
jekyll-migrate-permalink was born as an attempt to make this process less painful.
While Ruby isn’t my most comfortable language, I decided to build it as a custom command Jekyll plugin (rather than e.g. writing in PHP, which I work with every day). The benefit of writing the tool as a Jekyll plugin is that it allows access to the same primitives Jekyll uses when it compiles a site.
In the process I hit quite a few stumbling blocks. While other types of plugins just allow you to drop an
.rb file into a
_plugins folder in the root of the site, with commands, your plugin needs to be turned into a Gem. Maybe I just don’t know the right terms to Google, but I had a lot of trouble finding resources to help me through the process. Now that I’ve released the plugin, I decided to publish a guide for creating a simple custom command Jekyll plugin, putting everything I learned into one place.
After reading through the beginning of Andrew Blum’s, Tubes last night, I decided to spend some time today playing with
traceroute. I was initially exposed to the tool via Pingdom’s root cause analysis feature, which captures a
traceroute when it detects a downtime incident for diagnostic purposes. In the past, I’ve always been a bit confused about how to actually interpret the
traceroute results. But, as of today, I feel pretty good about my understanding. In this post, I’ll share what I’ve learned for anyone else struggling to make sense of
The majority of what I do in my day job involves maintaining inherited software. As a result, I spend a lot of time debugging. If you program for a living, there’s a pretty high chance you’re in the same camp.
To get to the bottom of some of the nastiest issues, one practice that has, time and time again, proven itself invaluable is keeping detailed notes throughout a debugging session. In this post, I’ll explain to you how this has helped me, and then offer some note-keeping tips.
Recently, I’ve been giving some thought to the risks associated with the “Miscellaneous HTML” and “Scripts and Style Sheets” (a.k.a. “Miscellaneous Scripts” in Magento 1) features in Magento. For those who don’t know, these are two text fields that accept any arbitrary input which is then rendered globally in the footer or header (respectively).
This was mainly spurred by Willem de Groot’s findings on credit card skimming. These fields are typically implicated in these types of exploits. I took Twitter to voice some initial thoughts on the matter.
My Tweet there was just something that had popped into my head, but at this point, I’ve had more time to think on the matter and wanted to share my thoughts.