docker exec <container> \
mysqldump \
--user=<username> \
--password=<password> \
--single-transaction \
<db_name> | gzip > <dump_name>.sql.gz
Magento 2.3.7 and 2.4.2 ship with composer v2 support out of the box but as far as I can see the only thing that needs to happen is to use some more modern versions of certain composer plugins which are used by certain dependencies of Magento.
This means we should be able to add composer v2 support to older Magento2 versions as well if we get a bit creative.
See below for diffs of the composer.json
files you can apply to your projects, be sure to keep a mental note of these things, they will need to maintained by yourself in case newer versions of these modules are released. And if one day you update to Magento 2.3.7 or 2.4.2 or higher, you can remove these changes again.
composer require cweagans/composer-patches
- Create your patch file as normal (referencing the paths to file in /vendor) and put it in a '.patches' folder at the top level of your code base.
- Edit composer.json to apply the patch(es) as below (this goes at the first level of composer.json) :
"extra": {
"magento-force": "override",
"enable-patching": true,
"patches-file": "composer.patches.json"
},
{ | |
"info": { | |
"_postman_id": "ac491bb7-de4a-4258-b717-ba80070f50fe", | |
"name": "Magento", | |
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" | |
}, | |
"item": [ | |
{ | |
"name": "Mine / Me", | |
"item": [ |
-- MySQL dump 10.13 Distrib 5.7.19-17, for debian-linux-gnu (x86_64) | |
-- | |
-- ------------------------------------------------------ | |
-- Server version 5.7.19-17 | |
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; | |
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; | |
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; | |
/*!40101 SET NAMES utf8 */; | |
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; |
The purpose of this SQL script is to clean up a Magento 1.x database by deleting orphaned
records from database tables which cause foreign key contraint failures. This happens when
at some point in time records where deleted from the database while FOREIGN_KEY_CHECKS = 0
and the person performing the delete operations failed to delete all related records
pertaining to related tables of the primary table.
This script can be helpful when encountering foreign key constraint failures using the Data Migration Tool to migrate your
# To be pasted in ~/.profile | |
vagrant() { | |
if [[ $@ == "halt all" ]]; then | |
command vagrant global-status | grep running | colrm 8 | xargs -L 1 -t vagrant halt | |
else | |
command vagrant "$@" | |
fi | |
} |
$ git remote rm origin | |
$ git remote add origin [email protected]:aplikacjainfo/proj1.git | |
$ git config master.remote origin | |
$ git config master.merge refs/heads/master |
There are certain files created by particular editors, IDEs, operating systems, etc., that do not belong in a repository. But adding system-specific files to the repo's .gitignore
is considered a poor practice. This file should only exclude files and directories that are a part of the package that should not be versioned (such as the node_modules
directory) as well as files that are generated (and regenerated) as artifacts of a build process.
All other files should be in your own global gitignore file:
- Create a file called
.gitignore
in your home directory and add any filepath patterns you want to ignore. - Tell git where your global gitignore file is.
Note: The specific name and path you choose aren't important as long as you configure git to find it, as shown below. You could substitute
.config/git/ignore
for.gitignore
in your home directory, if you prefer.