Something that’s tripped up both myself and devs that I’ve worked with is not finding Xdebug profiler files in the expected directory (
/tmp by default).
It usually goes something like this…
xdebug.profiler_enable_trigger = 1to a
?XDEBUG_PROFILE =1in the GET string.
This may be accompanied by running a sanity check, only to be accompanied by more hair pulling…
$ php -r 'var_dump(ini_get("xdebug.profiler_output_dir"));' string(4) "/tmp"
You may have a mysql import fail for any number of reasons. Most recently, I had an import fail with the following error.
ERROR 3 (HY000) at line 270457: Error writing file '/var/lib/mysqltmp/MLTmnake' (Errcode: 28 - No space left on device)
While the error implies that the disk ran out of space during import, the issue was in fact that the disk ran out of inodes.
Regardless of the reason of failure, you likely won’t want to start the import over from the beginning.
Here I’ll provide some tips for resuming the failed import.
Guzzle is the de facto library for doing HTTP requests in PHP. There may be cases where you’d prefer not to disclose your IP address when using it. You may also be using 3rd party tools and not be in a great position to introduce the proxying at an application level.
Fortunately, all you need to do is set the
ALL_PROXY environment variable when running your code.
Recently I registered this site for Brave Rewards.
There were two options for doing this:
.well-known/directory on the website
I decided to opt for the former.
Initially, I thought it was as simple commiting the file to the repo in the specified location. However, after pushing and letting the site build I got a 404 when attempting to access https://maxchadwick.xyz/.well-known/brave-payments-verification.txt.
On February 19, 2015 Magento dropped patch SUPEE-5344. The patch addressed APPSEC-921, a CVSSv3 Severity 9.1 Remote Code Execution vulnerability which later became known as “Shoplift”. The patch was dubbed “Shoplift” in response to a video published by Check Point that showed how it could be used to zero out the price of products on a site and purchase them for free (in other words, steal them).
While this is a novel idea, the reality is that most attackers exploited the vulnerability to implant malware in the victim’s environment, silently stealing their user’s credit card information and sending it to a drop server under their control. They’d also upload backdoors to the victims server…hidden (to the amateur eye) entry points that they could use to re-enter and re-compromise the victim’s site again in the future.
Back in April of 2018 I published a case study demonstrating the (positive) impact the MySQL query cache generally has on application performance and scalability for Magento. A recent issue at work has further highlighted this. I posted a quick update about it on Twitter:
Biggest Black Friday / Cyber Monday issue so far caused by Amasty module preventing query cache from being used efficiently. I've said it before but very opposed to query cache deprecation in MySQL 8.0— Max Chadwick (@maxpchadwick) November 26, 2018
Here I’ll share full details on the incident…