convenient

vendor/magento/framework/Logger/Monolog.php

    public function addRecord($level, $message, array $context = [])
    {
        $context[uniqid('trace')] = (new \Exception())->getTraceAsString();

convenient

You can apply custom patch files as a post composer script

https://support.magento.com/hc/en-us/articles/360005484154-Create-a-patch-for-a-Magento-2-Composer-installation-from-a-GitHub-commit

Use the attached patch files to correct this issue.

mkdir -p patches/composer/magento/module-staging/
nano patches/composer/magento/module-staging/fix-staging-test.patch

convenient

cut -f 5- -d ':' /var/www/vhosts/project.com/var/log/system.log | sort -n | uniq -c | sort -nr | head -20


Get all 404 requests from log
`lecli query --loggroup bes_web --leql 'where(status=404 AND request!=/(.*?)favicon.ico/)' -r 'last 1 hour'`
`grep -Eo ".{0,255}query" 404.log | sed -e 's/\", "query//' | cut -d ":" -f9 | sed 's/^.//'`


cat reqs.log | sed -e 's/.*userAgent...//' -e 's/.referer.*..//'

convenient

cat /var/log/httpd/access.SSL.log | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20

convenient

phpbrew install 5.3.26 +default +dbs +apxs2
phpbrew ext install iconv
phpbrew ext install gd
phpbrew ext install xdebug 2.2.3

#nano /home/luker/.phpbrew/php/php-5.3.26/var/db/xdebug.ini
xdebug.remote_host = 127.0.0.1
xdebug.remote_enable = 1
xdebug.remote_port = 9000
xdebug.remote_handler = dbgp

convenient

<?php
error_reporting( error_reporting() & ~E_NOTICE & ~E_WARNING);

/**
 * @param SimpleXMLElement|bool $element
 * @return string
 */
function loadedOkay($element)
{
    if ($element === true) {

convenient

cd ~/path/to/folder/ && find . -name '*.php' | sort -d | xargs md5sum

#files with spaces
cd . && find . -name '*.mp3' | xargs -d '\n' md5sum | sort -k 3

convenient

We've been having some issues with setup scripts causing an issue when updating CMS blocks, throws an exception and fails the deployment. The issue was related to using the Mage::getModel('cms/block')->load() function which actually does an is_active filter in the background. Meaning if you try and update a cms block that the client has actually marked as in_active, you're code assumes it is creating a new one instead of updating.

To get around this you HAVE to use collections.

The script below was an example for a particular project, in which each store had its own CMS block with the same identifier. The key ingredient is how the CMS block is updated within the second loop.

convenient

select IF(count(schedule_id) = 0, 'stuck', 'okay') as crons from cron_schedule where finished_at is not null and finished_at >= DATE_SUB(NOW(), INTERVAL 2 HOUR);

convenient

select count(*) from catalog_product_index_price_cl where version_id > (select version_id from enterprise_mview_metadata where changelog_name='catalog_product_index_price_cl');