Comment transférer le site Magento 2 de Localhost vers le serveur ?

Le processus de transfert d'un site basé sur Magento 2 d'un hôte local à un autre ne prend pas beaucoup de temps. Cependant, il comporte un certain nombre de détails et d'aspects particuliers qui doivent être pris en considération avant de se lancer dans le processus.

Dans cet article de blog, nous rendrons le transfert d'un site Magento 2 de localhost vers un serveur aussi simple que Lego. Ayons un aperçu.

Principales étapes

Pour commencer, examinons les principales étapes du transfert :

1. Vérification de l'intégrité du site Magento 2 sur l'hôte actuel (A) ;
2. Préparation de l'hôte distant (B) ;
3. Vérification de l'hôte distant (B) ;
4. Préparer les données pour le transfert ; 4.1. Vidage de fichier ; 4.2. Vidage de la base de données ;
5. Transfert de données;
6. Déballage des données ; 6.1. Déballage des fichiers ; 6.2. Importation de bases de données ;
7. Accéder à la correction des données sur l'hôte distant (B) ;
8. Correction des autorisations d'accès aux fichiers et répertoires ;
9. Procédures standards avant de lancer Magento ;
10. Vérifications des performances de Magento sur l'hôte distant (B) ;
11. Solution des problèmes fréquents.

Facile comme Lego : instructions étape par étape

1. Vérification de l'intégrité du site Magento 2 sur l'hôte actuel

Tout est facile ici : exécutez et vérifiez. Habituellement, une commande (cycle complet) doit être créée à ces fins. Puis vérifier:

• chercher;
• pages produits,
• catégories,
• compte du client.

Il s'agit d'une étape importante car elle vous permet d'éviter de vous débattre avec des questions concernant le moment exact où quelque chose a cessé de fonctionner après le passage à un nouvel hôte. De plus, cela vous évitera d'avoir à traiter les problèmes de base de l'hôte qui peuvent être résolus à l'avance (A).

Je vous encourage à NE PAS transférer à moitié l'exploitation de Magento sans aucun besoin urgent. Il est beaucoup plus facile de traiter tous les problèmes sur l'hôte actuel (A) avant de commencer le processus de transfert. Éprouvé et testé ― cela vous fera gagner du temps et vous fera gagner du temps.

2. Préparation de l'hôte distant (B)

Le serveur sur lequel la copie Magento est déployée doit répondre aux exigences minimales de votre version de Magento.

Étudiez la documentation officielle pour en savoir plus sur ces exigences : https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

L'environnement doit être configuré avant de passer aux étapes suivantes du processus de transfert (serveur Web avec un hôte virtuel, PHP, base de données).

Malheureusement, la configuration de chaque partie séparée dépasse le cadre de cet article. Cependant, vous pouvez facilement trouver les informations supplémentaires requises sur le Web. Donc, cela ne devrait pas poser de difficulté.

Je recommande de porter une attention particulière à la présence des extensions PHP requises.

Si vous avez des questions sur une étape de ce tutoriel, veuillez laisser un commentaire. Je ferai de mon mieux pour répondre à toutes.

3. Vérification de l'hôte distant (B)

Avant de transférer Magento, assurez-vous qu'il fonctionne sur le nouvel hôte et que l'hôte lui-même fonctionne correctement. Tout d'abord, vérifiez que le serveur Web répond à l'adresse indiquée (nous supposons que l'hôte a déjà été configuré).

Dans mon exemple, j'utilise le chemin standard disponible juste après l'installation d'Apache2 sur le serveur Linux :

> /var/www/html

 sudo -u apache echo "<?php phpinfo();?>" > /var/www/html/index.php

*Ici et plus loin, les commandes seront exécutées à partir des utilisateurs correspondants si nécessaire. Si la commande est exécutée sans nom d'utilisateur, l'exécution de la commande doit être entendue à partir de l'utilisateur actuel et de la disponibilité des autorisations correspondantes.

Si aucune erreur n'apparaît après l'exécution de cette commande, alors tout s'est bien passé et votre fichier `index.php` doit être disponible à l'adresse suivante : {host}/index.php. Le résultat dans votre navigateur devrait ressembler à ceci (bien que cela dépende encore beaucoup de votre version de PHP) :

Si quelque chose s'est mal passé et que vous ne voyez pas d'informations sur votre version de PHP, veuillez adresser un guide correspondant sur la configuration d'un serveur Web dont vous avez besoin.

De plus, je vous recommande d'étudier les journaux à l'avance - cela vous fera gagner beaucoup de temps.

Ensuite, vérifiez que le service de base de données a été lancé et fonctionne correctement :

 mysql -u root -p

Par conséquent, vous devriez vous connecter avec succès à MySQL. Utilisez la commande `exit` pour quitter.

* Entrez le nom d'utilisateur et le mot de passe que vous avez utilisés lors de la configuration de MySQL.

De plus, après vous être connecté à MySQL avec succès, vous devrez vérifier les bases de données existantes.

 SHOW databases;

Les noms des bases de données que vous prévoyez de transférer ne doivent pas être les mêmes que ceux qui existent déjà sur le nouveau serveur. S'il existe des bases de données similaires, ce problème doit être résolu manuellement en supprimant une base de données existante mais non utilisée, par exemple, ou en renommant une base de données Magento que vous avez l'intention de transférer. Notez que vous devez obligatoirement saisir le nom modifié dans le fichier de configuration de l'environnement Magento `app/etc/env.php`.

Votre résultat devrait se présenter comme suit :

De plus, vous devez vérifier que le service lui-même a été lancé et écoute le port standard à l'aide de l'utilitaire netstat :

 netstat -vulntp | grep -i mysql

Votre résultat ressemblera à ceci :

 > tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3366/mysqld

4. Préparer les données pour le transfert

4.1. Vidage de fichier

Avant de créer un vidage de fichier, je vous encourage fortement à retirer tous les fichiers inutiles du répertoire Magento, s'il y en a, c'est-à-dire les anciens vidages, le cache, les journaux, etc.

 rm -rf var/cache/* var/page_cache/* var/generation/* var/composer_home/cache/* var/log/* pub/static/*

Cela vous permettra de raccourcir le processus. En plus de vous éviter de transférer des fichiers inutiles, vous éviterez d'utiliser l'espace serveur sans besoin particulier.

*Ne supprimez PAS de force `.htaccess` et d'autres fichiers cachés, si vous utilisez le serveur Web Apache2 (la commande `rf` ne les supprime pas par défaut). Ces fichiers sont nécessaires au bon fonctionnement de Magento.

Maintenant, allez dans le répertoire où se trouve notre Magento sur le serveur local (A). Dans mon exemple, c'est :

 > /Users/sergei/PhpstormProjects

Le répertoire avec Magento est nommé sous aws-botapi .

Créons une archive pour son transfert ultérieur vers l'hôte distant (B):

 tar -zcf aws-botapi.tar.gz aws-botapi

Vous devez vérifier que l'archive a été créée :

 ls -la aws-botapi.tar.gz

4.2. Vidage des bases de données

S'il existe plusieurs bases de données distinctes organisées localement sur votre site Magento, elles doivent toutes être transférées. Dans mon exemple, deux bases de données sont utilisées. Vous pouvez les trouver dans les configurations de l'environnement Magento `app/etc/env.php` dans la section `db => connection => `.

Maintenant, videz toutes les bases de données :

 mysqldump -u root -p db1 | gzip > ./db1.sql.gz mysqldump -u root -p db2 | gzip > ./db2.sql.gz

*Utilisez des informations telles que le nom d'utilisateur de la base de données et le nom de la base de données.

5. Transfert de données

Transférez le dump des fichiers Magento à l'aide de l'utilitaire `scp` (copie via ssh) ou utilisez tout autre moyen à votre convenance (par exemple, copie via `ftp`):

 scp -i ~/.ssh/myprivatekey.pem aws-botapi.tar.gz [email protected]:/home/ec2-user

Où,

a) -i ~/.ssh/myprivatekey.pem est le chemin vers la clé privée pour la connexion (ignorez ceci si vous utilisez uniquement un mot de passe) ;

b) ec2-user est le nom d'utilisateur pour la connexion ;

c) 52.12.187.98 est l'adresse du serveur ;

d) /home/ec2-user est le chemin absolu sur le serveur, vers lequel nous copions les fichiers.

*Si vous utilisez un port différent du port standard, n'oubliez pas de l'identifier à l'aide d'un paramètre distinct (par exemple, `-P 6000` pour le port 6000).

Une fois la copie terminée, vous verrez une ligne du type :

 > aws-botapi.tar.gz 100% 312MB 4.3MB/s 01:11

Répétez les mêmes actions pour le vidage des fichiers :

 scp -i ~/.ssh/myprivatekey.pem db1.sql.gz [email protected]:/home/ec2-user scp -i ~/.ssh/myprivatekey.pem db2.sql.gz [email protected]:/home/ec2-user

6. Déballage des données

6.1. Déballage des fichiers

Sur le serveur (B), naviguons vers le répertoire dans lequel nous avons copié les archives. Décompressons les fichiers Magento dans le répertoire de l'hôte local :

 > tar -zxf aws-botapi.tar.gz -C /var/www/html/

Assurez-vous de vérifier que les fichiers ont été correctement décompressés :

 ls -la /var/www/html

Si les fichiers Magento ont été décompressés dans le sous-répertoire, transférez-les à l'aide des commandes `mv` ou `cp`.

6.2. Importation de bases de données

Connectez-vous à MySQL sur le serveur (B) :

 mysql -u root -p

Maintenant, créons une nouvelle base de données :

 CREATE DATABASE IF NOT EXISTS db1 CHARACTER SET utf8 COLLATE utf8_general_ci;

*Le résultat devrait ressembler à ceci :

 > Query OK, 1 row affected (0.01 sec)

Effectuez les actions similaires au cas où vous auriez d'autres bases de données.

Ensuite, importez les bases de données depuis le dump :

 gunzip < /home/ec2-user/db1.sql.gz | mysql -u root -p db1 gunzip < /home/ec2-user/db2.sql.gz | mysql -u root -p db2

Connectez-vous à MySQL :

 mysql -u root -p

et vérifiez que toutes les bases de données sont présentes :

 SHOW databases;

La liste de toutes les bases de données doit être disponible, y compris la nôtre :

 +--------------------+ | Database | +--------------------+ | db1 | | db2 | | information_schema | | mysql | | performance_schema | +--------------------+ 5 rows in set (0.00 sec)

Sélectionnez la base de données que nous venons d'importer :

 USE db1;

et vérifier la présence de tables :

 SHOW tables;

Dans le cas où les tables n'ont pas été créées ou sont vides, vérifiez le fichier de vidage lui-même et répétez tout le processus à l'exception de l'étape lors de la création d'une nouvelle base de données (car elle existe déjà).

7. Accéder à la correction des données sur l'hôte distant (B)

Les principales données qui doivent être modifiées dans Magento après avoir été transférées sont 1) les URL de base et 2) les clés d'accès à MySQL :

Modification des URL de base

Vous devrez modifier tous les anciens chemins dans la table `core_config_data`. Pour commencer, localisons ces champs en utilisant la requête 'value' qui inclut l'ancienne adresse. Supposons que l'ancienne adresse du site Web était '1001101010.com', alors la commande de recherche ressemblera à ceci :

 SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G

*`\G` à la fin de la requête au lieu de `;` rendra les enregistrements plus lisibles.

** N'oubliez pas d'utiliser `table_prefix` avant les noms de table s'il a été installé.

Le résultat ressemblera à ça :

 mysql> SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G *************************** 1. row *************************** config_id: 2 scope: default scope_id: 0 path: web/unsecure/base_url value: http://1001101010.com/

 *************************** 12. row *************************** config_id: 2401 scope: default scope_id: 0 path: web/secure/base_url value: https://1001101010.com/ *************************** 13. row *************************** config_id: 2402 scope: default scope_id: 0 path: web/secure/base_link_url value: https://1001101010.com/ 13 rows in set (0.00 sec)

À ce stade, notre objectif est de remplacer l'ancienne adresse par une nouvelle. Pour cela, assurons-nous qu'il doit bien être changé dans toutes les lignes (c'est le cas la plupart du temps sauf pour quelques rares cas impliquant la configuration de modules tiers) et exécutons la requête suivante :

 UPDATE `core_config_data` SET `value` = replace(value, '1001101010.com', 'mynewdomain.com') WHERE `value` LIKE '%1001101010.com%';

Il remplacera toutes les occurrences des lignes `1001101010.com` dans le champ `value` par la ligne `mynewdomain.com`.

Le résultat devrait être à peu près le suivant (le nombre de lignes doit être égal) :

 > Query OK, 13 rows affected (0.00 sec) > Rows matched: 13 Changed: 13 Warnings: 0

La requête suivante :

 SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G

Maintenant, il est temps de procéder à l'édition du fichier de l'environnement `app/etc/env.php` (depuis la racine de Magento ; dans l'exemple, c'était `/var/www/html/`).

Ouvrons-le dans un programme d'édition de texte (j'utilise Nano même si c'est sûrement une question de préférences personnelles).

 nano /var/www/html/app/etc/env.php

Modifiez ensuite les données dans `'db' => 'connection'` en spécifiant les données exactes du nouveau serveur dans les champs 'username' et 'password'.

* IMPORTANT ! Si votre base de données se trouve sur un serveur distant, il n'est pas nécessaire de modifier les données. La seule chose que vous devez faire est de vous assurer que le serveur actuel a accès à cette base de données distante. (Par exemple, qu'il a été ajouté à la liste blanche du pare-feu sur le serveur de base de données).

Utilisez la valeur 'localhost' dans le champ 'host' pour comprendre si la connexion est locale ou non.

Ensuite, enregistrez le fichier.

8. Correction des autorisations d'accès aux fichiers et répertoires

Afin de configurer avec précision les autorisations d'accès, vous devez savoir à partir de quel utilisateur et avec quel groupe votre serveur Web s'exécute.

Le plus souvent, il s'agit soit de "apache" pour CentOS, soit de "www-data" pour Ubuntu. En règle générale, le nom d'utilisateur est égal au nom du groupe. Cependant, sur différents serveurs, cela peut différer.

La commande suivante vous aidera à le comprendre :

 ps aux | egrep '(apache|httpd)'

Par conséquent, dans la première colonne, vous verrez nom d'utilisateur (le nom du groupe est probablement le même. Cependant, si vous n'êtes pas sûr, utilisez la commande `groups apache`, où `apache` est le nom d'utilisateur afin de Vérifiez-le).

La première chose après cela, nous devrons transférer tous les fichiers et répertoires à l'intérieur de Magento à l'utilisateur du serveur Web (c'est `apache` dans l'exemple. Pour l'utilisateur `www-data` remplacez simplement `apache: apache` par ` www-data:www-data`, et de même pour les autres) :

 sudo chown -R apache:apache /var/www/html

Ensuite, vérifiez si les modifications ont été appliquées ou non :

 ls -la /var/www/html

Tous les fichiers et répertoires (à l'exception du parent marqué comme `..` doivent avoir un utilisateur et le groupe `apache` (si `www-data` est un utilisateur de serveur Web dans votre système, il doit être marqué comme un propriétaire):

Désormais, il est nécessaire de configurer avec précision les autorisations d'accès aux fichiers et répertoires Magento. Selon la documentation, la configuration suivante est fortement recommandée :

*Toutes les commandes doivent être exécutées à partir de la racine Magento!, systématiquement 1 après 1. Dans l'exemple, la racine Magento sur le serveur est `/var/www/html`.

Utilisez la commande `pwd` pour vérifier l'emplacement actuel.

 find var generated vendor pub/static pub/media app/etc -type f -exec chmod u+w {} + find var generated vendor pub/static pub/media app/etc -type d -exec chmod u+w {} + chmod u+x bin/magento

* Si l'utilisateur actuel n'a pas les autorisations nécessaires pour exécuter ces commandes, utilisez la commande `root ` de l'utilisateur (commande `sudo`, comme `sudo find …`)

9. Procédures standard avant de lancer Magento

Il est temps de vérifier que Magento se lance depuis la ligne de commande. Pour commencer, testons la sortie standard des commandes auxquelles vous avez accès :

* Désormais, après la configuration des autorisations, tout accès à Magento sera effectué à partir du même utilisateur de serveur Web qui génère des fichiers, des fichiers de cache, des statiques, etc. Si vous ignorez cela, Magento peut cesser de fonctionner et vous serez obligé de restaurer les autorisations encore une fois (l'étape précédente dans ces lignes directrices).

**Pour un fonctionnement précis, vous devrez trouver le bon interpréteur php sur votre serveur. Habituellement, l'alias ` php` fait référence à la version à jour. Cependant, vous devrez souvent indiquer le chemin complet, comme `/usr/bin/php72` par exemple.

*** Ici et plus loin, toutes les commandes Magento seront exécutées à partir du répertoire racine de Magento sur le serveur (B).

 sudo -u apache php bin/magento list

Cela rendra la liste avec les commandes disponibles dans la ligne de commandes :

Si tout s'est bien passé, vous pouvez passer aux commandes suivantes :

*Si avant le transfert vous n'avez pas effacé les répertoires avec le cache et les fichiers générés, c'est le bon moment pour le faire en utilisant la commande suivante :

 sudo rm -rf var/cache/* var/page_cache/* var/generation/*

 sudo -u apache php bin/magento setup:upgrade

Vous pouvez éviter d'exécuter cette commande, mais je recommande toujours de vous assurer que tous les modules sont écrits et qu'aucune erreur ne se produit. En conséquence, vous verrez une liste avec les modules qui ont été traités, sans voir d'erreurs dans le processus.

Effectuez une compilation afin de générer les fichiers Magento nécessaires :

 sudo -u apache php bin/magento setup:di:compile

*À ce stade, il est essentiel de détecter toutes les erreurs qui se sont produites. Sinon, Magento ne fonctionnera pas correctement. Si aucune erreur n'a été trouvée, alors tout est parfait. ?

Ensuite, générez des statiques ( si le mode production est activé. Pour vérifier votre mode actuel, utilisez la commande suivante :

 sudo -u apache php bin/magento deploy:mode:show

 sudo -u apache php bin/magento setup:static-content:deploy

*Pour générer des statiques pour une locale spécifique, spécifiez-la en tant que paramètre après la commande. Par exemple, `sudo -u apache php bin/magento setup:static-content:deploy ru_RU` sera utilisé pour les paramètres régionaux russes.

Toutes nos félicitations! Vous avez transféré avec succès votre boutique Magento2 de localhost pour fonctionner correctement sur un nouveau serveur. Maintenant, ouvrez-le dans un navigateur en saisissant une nouvelle adresse !

10. Dépannage : problèmes fréquents

Numéro 1

Problème:

Si lors de la copie de l'archive, vous recevez un message du genre :

 scp: /var/www/html/aws-botapi.tar.gz: Permission denied

Ensuite, vous devez vérifier où vous avez copié l'archive sur le serveur en premier lieu. Il est fort probable que l'utilisateur qui a l'intention de se connecter n'ait pas les permissions pour faire un enregistrement dans ce répertoire (`/var/www/html` dans l'exemple).

La solution:

Cela peut être résolu en changeant le répertoire dans lequel vous essayez de copier lors de l'exécution de la commande ` scp ` ou en vous connectant au serveur et en ajustant les autorisations d'accès à ce répertoire pour l'utilisateur actuel :

`sudo chown -R ec2-user /var/www/html` (rendre un utilisateur propriétaire du répertoire `/var/www/html` et de tous les fichiers et répertoires inclus), ou

`sudo chmod -R o+w /var/www/html` (permet à tous (`o-ther`) de faire un enregistrement (`w-rite`) dans le répertoire `/var/www/html`).

Utilisez ces commandes avec prudence car elles influencent directement la sécurité de votre système.

Numéro 2

Problème:

Si lors de l'importation de bases de données, l'erreur suivante se produit `ERROR 1049 (42000): Unknown database 'db1'` (où `db1` est le nom d'une base de données), alors votre base de données n'a pas été créée.

La solution:

Essayez d'accéder à `mysql` et recréez cette base de données une fois de plus.

Numéro 3

Problème:

Si lors du changement de propriétaire de fichiers et de répertoires, vous voyez la commande `chown: invalid user: … `, alors vous avez probablement mal spécifié l'utilisateur du serveur Web sur votre serveur.

La solution:

Consultez les guides correspondants sur la configuration du serveur dans votre système ou utilisez l'utilitaire `ps aux` pour déterminer le bon utilisateur.

Numéro 4

Problème:

S'il y a des erreurs PHP lors du démarrage de Magento sur un nouveau serveur (en règle générale, cela signifie l'absence de certaines extensions PHP)…

La solution:

Cela peut être résolu par l'installation des extensions manquantes.

a) `L'extension json de PHP est requise pour utiliser NormalizerFormatter de Monolog` ―

L'extension *php-json* est manquante ;

b) `Erreur fatale PHP : Erreur non interceptée : Classe 'DOMDocument' introuvable dans …` ―

L'extension *php-xml* est manquante ;

c) `Erreur fatale PHP : classe 'IntlDateFormatter' introuvable dans …` ―

L'extension *php-intl* est manquante.

Numéro 5

Problème:

Si des extensions PHP sont manquantes lors de l'exécution de la commande `composer update`, vous verrez les erreurs suivantes :

Par exemple,

`phpunit/phpunit 6.5.14 requiert ext-mbstring * -> l'extension PHP demandée mbstring est manquante sur votre système.`

La solution:

Pour faire face à de telles erreurs, vous devez simplement installer les extensions PHP auxquelles le compositeur fait référence. Par exemple, `yum install php-mbstring`.

Une liste complète des extensions requises pour votre version de Magento 2 se trouve dans la documentation officielle.

Conclusion

Vous êtes prêt! Dans cet article, j'ai fait de mon mieux pour présenter des étapes faciles à suivre pour transférer votre site Magento 2 de localhost vers le serveur.

Si vous avez encore des questions ou souhaitez partager votre opinion, n'hésitez pas à utiliser la section des commentaires ci-dessous. Je ferai de mon mieux pour répondre à toutes les questions et préoccupations!