| /* | |
| * IMPORTANT: The queries below are written for Magento Enterprise. If you're going to run them on Magento Community, you need | |
| * to replace all instances of ".row_id" with ".entity_id". See this for context: http://magento.stackexchange.com/questions/139740/magento-2-schema-changes-for-ee-catalog-staging | |
| * | |
| * When importing products in Magento 2, if you specify store view codes in the store_view_code column, product data will be set at | |
| * both the global scope as well as the specific store view scope. This is not ideal because now you have duplicate | |
| * data at two different scopes that shouldn't actually be duplicated. The scripts below clean up this data by finding | |
| * data set at specific store view scopes and if it's an exact match to the data set at the global store view, then it | |
| * deletes the data set at the specific store view scope. | |
| * |
I have a client using this extension, and we recently discovered a big performance issue.
Description: The query generated by the \Amasty\Fpc\Model\ResourceModel\Activity::matchUrl method runs a query on a table that is missing an index.
Here is a screenshot showing the slow query:
Once the client added a MySQL index for the table, the slow query went away:
| Index:/src/view/frontend/web/template/shipping-address/address-renderer/default.html | |
| IDEA additional info: | |
| Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP | |
| <+>UTF-8 | |
| =================================================================== | |
| diff --git a/src/view/frontend/web/template/shipping-address/address-renderer/default.html b/src/view/frontend/web/template/shipping-address/address-renderer/default.html | |
| --- a/src/view/frontend/web/template/shipping-address/address-renderer/default.html | |
| +++ b/src/view/frontend/web/template/shipping-address/address-renderer/default.html (date 1709742374536) | |
| @@ -11,6 +11,11 @@ | |
| <div class="shipping-address-item" css="'selected-item' : isSelected() , 'not-selected-item':!isSelected()"> |
For future reference:
I just had to troubleshoot a script that ran so long that it eventually died without any relevant errors ([pid 6048:tid 139809649469184] (104)Connection reset by peer: [client 184.4.89.70:0] FastCGI: comm with server "/var/run/a49982b9-remi-safe-php81.fcgi" aborted: read failed, referer was getting written to the Apache error logs).
Thankfully I was able to reproduce the issue locally. Here are the steps I took in Warden to troubleshoot:
In pub/index.php I added this line: set_time_limit(15); above the $bootstrap->run($app);
cd <PATH TO MAGENTO 2 DIRECTORY>
See this Github comment thread for any issues or additional context for getting Warden running on Windows with WSL 2.
The instructions below cover how to install Warden on Windows, using WSL 2.
Ubuntu 20.04 program that will have been installed in the step above (If you want to be able to copy/paste, see here. Going forward, this article assumes you will run all commands inside of the Ubuntu terminal
This document covers how to export Jira tickets to PDF from the on-premise version of Jira. For the cloud version of Jira, you can write a script to download Word versions of each issue (e.g., https://krakencommerce.atlassian.net/si/jira.issueviews:issue-word/DMC-95/DMC-95.doc) and you don't need this approach.
https://krakencommerce.atlassian.net/browse/DMC-1
https://krakencommerce.atlassian.net/browse/DMC-2
This basic script crawls a Magento 1 or Magento 2 website and logs the prices, SKUs, and product urls to a CSV file. This script was put togther for a company that had consent from the website(s) being scraped. Please use responsibility.
This script uses https://scrapy.org/
This script was tested on macOS Mojave, but it should run on any *NIX system.
You can tweak the body.css code to match the specific CSS selectors on the site you're crawling. See this documentation. When you're testing this script, refer to the command above the def parse_item line to learn how to run the code for only a single product.
See also this alternative approach: https://gist.github.com/cmtickle/8900629447429126ffd7ff84e56ec780#to-patch-code-in-appcode
If you need to patch an M2 extension that isn't available to be installed via Composer, and you're concerned about losing edits directly to files in app/code/<Vendor> directory, you can install and then patch the extension locally using these steps:
Copy the extension into an arbitrary folder location like app/code/packages/VendorName/ModuleName (this assumes this module has a composer.json file with the package name of vendorname/module-modulename)
Run this command to add your custom package location to the composer repositories list:
composer config repositories.vendorname/module-modulename path app/packages/VendorName/ModuleName
Require the extension:
| #!/bin/bash | |
| # stop on errors | |
| set -e | |
| # turn on debugging if you're running into issues | |
| #set -x | |
| # Static variables | |
| ENVIRONMENT=$1 | |
| RED='\033[0;31m' | |
| NC='\033[0m' # No Color |
| #!/bin/bash | |
| # stop on errors | |
| set -e | |
| # turn on debugging if running into issues | |
| #set -x | |
| # This script sends a nightly email, showing errors, grouped and sorted by count. | |
| # Getting these errors emailed can be especially useful for the first few weeks after launching a new Magento site. | |
| # Assumptions: |