Come trasferire il sito Magento 2 da Localhost al server?

Il processo di trasferimento di un sito basato su Magento 2 da un host locale a un altro non è un processo che richiede tempo. Tuttavia, ha una serie di dettagli essenziali e aspetti speciali che dovrebbero essere presi in considerazione prima di immergersi nel processo.

In questo post del blog, renderemo il trasferimento di un sito Magento 2 da localhost a server facile come Lego. Diamo un'idea.

Passi principali

Per cominciare, diamo un'occhiata ai passaggi principali del trasferimento:

1. Controllo di integrità del sito Magento 2 sull'host corrente (A);
2. Preparare l'host remoto (B);
3. Controllo host remoto (B);
4. Preparare i dati per il trasferimento; 4.1. dump di file; 4.2. dump del database;
5. Trasferimento dati;
6. Disimballaggio dei dati; 6.1. Disimballaggio dei file; 6.2. Importazione di banche dati;
7. Accedere alla correzione dei dati sull'host remoto (B);
8. Correzione dei permessi di accesso a file e directory;
9. Procedure standard prima del lancio di Magento;
10. Controlli delle prestazioni di Magento sull'host remoto (B);
11. Soluzione di problemi frequenti.

Facile come Lego: linee guida dettagliate

1. Controllo di integrità del sito Magento 2 sull'host corrente

Qui è tutto facile: corri e controlla. Di solito, per tali scopi dovrebbe essere creato un ordine (ciclo completo). Quindi controlla:

• ricerca;
• pagine dei prodotti,
• categorie,
• conto del cliente.

Questa è una fase importante in quanto ti consente di evitare di lottare con domande relative a quando esattamente qualcosa ha smesso di funzionare dopo essere passato a un nuovo host. Inoltre, questo ti salverà dalla necessità di affrontare i problemi di base dell'host che possono essere risolti in anticipo (A).

Vi incoraggio a NON trasferire a metà un operante Magento senza alcuna necessità urgente. È molto più semplice affrontare tutti i problemi sull'host corrente (A) prima di avviare il processo di trasferimento. Dimostrato e testato: questo ti farà risparmiare tempo e dolore al collo.

2. Preparare l'host remoto (B).

Il server su cui è distribuita la copia di Magento deve soddisfare i requisiti minimi per la tua versione di Magento.

Studia la documentazione ufficiale per saperne di più su questi requisiti: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

L'ambiente deve essere configurato prima di procedere ai passaggi successivi del processo di trasferimento (server web con host virtuale, PHP, database).

Sfortunatamente, la configurazione di ogni parte separata va oltre i limiti di questo articolo. Tuttavia, è possibile trovare facilmente le informazioni aggiuntive richieste sul Web. Quindi, non dovrebbe essere di difficoltà.

Consiglio di prestare particolare attenzione alla presenza delle estensioni PHP richieste.

In caso di domande su qualsiasi passaggio di questo tutorial, lascia un commento. Farò del mio meglio per rispondere a tutti.

3. Controllo host remoto (B)

Prima di trasferire Magento, assicurati che funzioni sul nuovo host e che l'host stesso funzioni correttamente. Innanzitutto, controlla che il web-server risponda all'indirizzo indicato (supponiamo che l'host sia già stato configurato).

Nel mio esempio, utilizzo il percorso standard disponibile subito dopo l'installazione di Apache2 sul server Linux:

> /var/www/html

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

*Qui e oltre, i comandi verranno eseguiti dagli utenti corrispondenti, se necessario. Se il comando viene eseguito senza un nome utente, l'esecuzione del comando deve essere intesa come dall'utente corrente e dalla disponibilità di eventuali autorizzazioni corrispondenti.

Se non vengono visualizzati errori dopo aver eseguito questo comando, è andato tutto bene e il tuo file `index.php` deve essere disponibile al seguente indirizzo: {host}/index.php. Il risultato nel tuo browser dovrebbe assomigliare a questo (anche se molto dipende ancora dalla tua versione di PHP):

Se qualcosa è andato storto e non vedi informazioni sulla tua versione di PHP, ti preghiamo di indirizzare una guida corrispondente sulla configurazione di un server web di cui hai bisogno.

Inoltre, ti consiglio di studiare i registri in anticipo: questo ti farà risparmiare un sacco di tempo.

Successivamente, verifica che il servizio database sia stato avviato e funzioni correttamente:

 mysql -u root -p

Di conseguenza, dovresti connetterti correttamente a MySQL. Usa il comando `exit` per uscire.

* Inserisci login e password che hai utilizzato durante la configurazione di MySQL.

Inoltre, dopo aver effettuato correttamente la connessione a MySQL, è necessario controllare i database esistenti.

 SHOW databases;

I nomi dei database che si intende trasferire non devono essere gli stessi di quelli già esistenti sul nuovo server. Nel caso ci siano database simili, questo problema dovrebbe essere risolto manualmente eliminando un database esistente ma non utilizzato, ad esempio, o rinominando un database Magento che si intende trasferire. Nota che devi necessariamente inserire il nome modificato nel file di configurazione dell'ambiente Magento `app/etc/env.php`.

Il tuo risultato dovrebbe apparire come segue:

Inoltre, dovresti verificare che il servizio stesso sia stato avviato e ascolti la porta standard utilizzando l'utilità netstat :

 netstat -vulntp | grep -i mysql

Il tuo risultato apparirà come segue:

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

4. Preparare i dati per il trasferimento

4.1. File dump

Prima di creare un dump di file, ti consiglio vivamente di rimuovere tutti i file non necessari dalla directory Magento, se ce ne sono, ad esempio vecchi dump, cache, log, ecc.

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

Ciò ti consentirà di abbreviare il processo. Oltre a salvarti dal trasferimento di file non necessari, eviterai di utilizzare lo spazio del server senza particolari necessità.

*NON eliminare forzatamente `.htaccess` e altri file nascosti, se si utilizza il server web Apache2 (il comando `rf` non li elimina per impostazione predefinita). Questi file sono necessari per il corretto funzionamento di Magento.

Ora vai alla directory in cui si trova il nostro Magento nel server locale (A). Nel mio esempio è:

 > /Users/sergei/PhpstormProjects

La directory con Magento è denominata sotto aws-botapi .

Creiamo un archivio per il suo ulteriore trasferimento all'host remoto (B):

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

Dovresti controllare che l'archivio sia stato creato:

 ls -la aws-botapi.tar.gz

4.2. Scarico database

Se ci sono diversi database separati che sono organizzati localmente sul tuo sito Magento, allora tutti devono essere trasferiti. Nel mio esempio vengono utilizzati due database. Puoi trovarli nelle configurazioni dell'ambiente Magento `app/etc/env.php` nella sezione `db => connection => `.

Ora, scarica tutti i database:

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

*Utilizzare informazioni come nome utente del database e nome del database.

5. Trasferimento dati

Trasferisci il dump dei file Magento usando l'utilità `scp` (copiando tramite ssh) o usa qualsiasi altro mezzo a tuo piacimento (ad esempio, copiando tramite `ftp`):

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

Dove,

a) -i ~/.ssh/myprivatekey.pem è il percorso della chiave privata per la connessione (ignoralo se usi solo la password);

b) ec2-user è il nome utente per la connessione;

c) 52.12.187.98 è l'indirizzo del server;

d) /home/ec2-user è il percorso assoluto sul server, in cui copiamo i file.

*Se utilizzi una porta diversa da quella standard, non dimenticare di identificarla utilizzando un parametro separato (ad esempio, `-P 6000` per 6000 porte).

Dopo aver completato la copia, vedrai una riga del tipo:

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

Ripeti le stesse azioni per il dump dei file:

 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. Disimballaggio dei dati

6.1. Decompressione dei file

Sul server (B), andiamo alla directory in cui abbiamo copiato gli archivi. Decomprimiamo i file Magento nella directory dell'host locale:

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

Assicurati di controllare che i file siano stati decompressi correttamente:

 ls -la /var/www/html

Se i file Magento sono stati decompressi nella sottodirectory, trasferiscili usando i comandi `mv` o `cp`.

6.2. Importazione di banche dati

Connetti a MySQL sul server (B):

 mysql -u root -p

Ora creiamo un nuovo database:

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

*Il risultato dovrebbe assomigliare a questo:

 > Query OK, 1 row affected (0.01 sec)

Fai le azioni simili nel caso tu abbia altri database.

Quindi, importa i database dal 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

Connettiti a MySQL:

 mysql -u root -p

e verifica che tutti i database siano presenti:

 SHOW databases;

L'elenco di tutti i database deve essere disponibile, incluso il nostro:

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

Seleziona il database che abbiamo appena importato:

 USE db1;

e verifica la presenza dei tavoli:

 SHOW tables;

Nel caso in cui le tabelle non siano state create o siano vuote, controllare il file dump stesso e ripetere l'intero processo ancora una volta tranne il passaggio in cui è stato creato un nuovo database (poiché esiste già).

7. Accedere alla correzione dei dati sull'host remoto (B)

I dati principali che dovrebbero essere modificati in Magento dopo essere stati trasferiti sono 1) URL di base e 2) chiavi di accesso a MySQL:

Modifica degli URL di base

Dovrai cambiare tutti i vecchi percorsi nella tabella `core_config_data`. Per cominciare, localizziamo questi campi utilizzando la query "value" che include il vecchio indirizzo. Supponiamo che il vecchio indirizzo del sito Web fosse "1001101010.com", quindi il comando di ricerca apparirà come segue:

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

*`\G` alla fine della query invece di `;` renderà i record meglio leggibili.

** Non dimenticare di usare `table_prefix` prima dei nomi delle tabelle se è stato installato.

Il risultato sarà più o meno così:

 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)

A questo punto, il nostro obiettivo è cambiare il vecchio indirizzo con uno nuovo. A tal fine, assicuriamoci che venga effettivamente modificato in tutte le righe (lo è la maggior parte delle volte tranne alcuni rari casi che coinvolgono la configurazione di moduli di terze parti) ed eseguiamo la seguente query:

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

Sostituirà tutte le occorrenze delle righe "1001101010.com" nel campo "value" nella riga "mynewdomain.com".

Il risultato dovrebbe essere circa il seguente (il numero di righe dovrebbe essere uguale):

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

La seguente richiesta:

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

Ora è il momento di procedere alla modifica del file dell'ambiente `app/etc/env.php` (dalla radice di Magento; nell'esempio era `/var/www/html/`).

Apriamolo in un programma di modifica del testo (io uso Nano anche se è sicuramente una questione di preferenze personali).

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

Quindi modifica i dati in `'db' => 'connessione'` specificando i dati accurati dal nuovo server nei campi 'nome utente' e 'password'.

* IMPORTANTE! Se il database si trova su un server remoto, non è necessario modificare i dati. L'unica cosa che devi fare è assicurarti che ci sia accesso dal server corrente a quel database remoto. (Ad esempio, che è stato aggiunto alla whitelist del firewall sul server di database).

Utilizza il valore 'localhost' nel campo 'host' per capire se la connessione è locale o meno.

Quindi, salva il file.

8. Correzione dei permessi di accesso a file e directory

Per impostare con precisione i permessi di accesso, devi sapere da quale utente e con quale gruppo viene eseguito il tuo server web.

Più frequentemente, è `apache` per CentOS o `www-data` in Ubuntu. Di norma, il nome utente è uguale al nome del gruppo. Tuttavia, su server diversi, ciò potrebbe differire.

Il seguente comando ti aiuterà a capirlo:

 ps aux | egrep '(apache|httpd)'

Di conseguenza, nella prima colonna vedrai il nome utente (è probabile che il nome del gruppo sia lo stesso. Tuttavia, se non sei sicuro, usa il comando `groups apache`, dove `apache` è il nome utente per controlla).

La prima cosa dopo questo, dovremo trasferire tutti i file e le directory all'interno di Magento all'utente del server web (è `apache` nell'esempio. Per l'utente `www-data` sostituisci semplicemente `apache:apache` con ` www-data:www-data`, e analogamente per altri):

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

Successivamente, controlla se le modifiche sono state applicate o meno:

 ls -la /var/www/html

Tutti i file e le directory (tranne quello principale contrassegnato come `..` devono avere un utente e il gruppo `apache` (se `www-data` è un utente del server web nel tuo sistema, allora dovrebbe essere contrassegnato come proprietario):

Ora è necessario impostare accuratamente i permessi di accesso ai file e alle directory di Magento. Secondo la documentazione, la seguente configurazione è altamente raccomandata:

*Tutti i comandi devono essere eseguiti dalla radice Magento!, costantemente 1 dopo 1. Nell'esempio, la radice Magento sul server è `/var/www/html`.

Usa il comando `pwd` per controllare la posizione corrente.

 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

*Se l'utente corrente non ha i permessi per eseguire questi comandi, usa il comando `root` ( `sudo`, come `sudo find …`) dell'utente

9. Procedure standard prima di avviare Magento

È ora di verificare che Magento si avvii dalla riga di comando. Per cominciare, testiamo l'output standard dei comandi a cui hai accesso:

*Ora, dopo aver impostato i permessi, qualsiasi accesso a Magento sarà effettuato dallo stesso utente del server web che genera file, file di cache, statici, ecc. Se ignori questo, Magento potrebbe smettere di funzionare e sarai costretto a ripristinare i permessi ancora una volta (il passaggio precedente in queste linee guida).

**Per un funzionamento accurato, dovrai trovare l'interprete php giusto sul tuo server. Di solito, l'alias `php` si riferisce alla versione aggiornata. Tuttavia, dovrai spesso indicare il percorso completo, come ad esempio `/usr/bin/php72`.

***Qui e oltre, tutti i comandi Magento verranno eseguiti dalla directory principale di Magento sul server (B).

 sudo -u apache php bin/magento list

Questo renderà l'elenco con i comandi disponibili nella riga di comando:

Se tutto è andato a buon fine, puoi procedere agli ulteriori comandi:

*Se prima del trasferimento non hai cancellato le directory con la cache e i file generati, questo è il momento giusto per farlo usando il seguente comando:

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

 sudo -u apache php bin/magento setup:upgrade

Puoi evitare di eseguire questo comando, ma ti consiglio comunque di assicurarti che tutti i moduli siano scritti e che non si verifichino errori. Di conseguenza, vedrai un elenco con i moduli, che sono stati elaborati, senza vedere alcun errore nel processo.

Esegui la compilazione per generare i file Magento necessari:

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

*A questo punto, è fondamentale rilevare tutti gli errori che si sono verificati. In caso contrario, Magento funzionerà in modo improprio. Se non sono stati trovati errori, allora tutto è semplicemente perfetto. ?

Quindi, genera statics ( se la modalità di produzione è abilitata. Per verificare la modalità corrente, utilizzare il comando seguente:

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

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

*Per generare dati statici per una locale specifica, specificarlo come parametro dopo il comando. Ad esempio, `sudo -u apache php bin/magento setup:static-content:deploy ru_RU` sarà usato per la locale russa.

Congratulazioni! Hai trasferito con successo il tuo negozio Magento2 da localhost per operare correttamente su un nuovo server. Ora aprilo in un browser inserendo un nuovo indirizzo!

10. Risoluzione dei problemi: problemi frequenti

Problema n. 1

Problema:

Se durante la copia dell'archivio si riceve un messaggio del tipo:

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

Quindi dovresti controllare dove hai copiato l'archivio sul server in prima istanza. È molto probabile che l'utente che intende connettersi non abbia i permessi per creare un record in questa directory (`/var/www/html` nell'esempio).

Soluzione:

Questo può essere risolto cambiando la directory in cui si tenta di copiare eseguendo il comando ` scp ` o collegandosi al server e regolando i permessi di accesso a questa directory per l'utente corrente:

`sudo chown -R ec2-user /var/www/html` (rende un utente proprietario della directory `/var/www/html` e di tutti i file e le directory inclusi), oppure

`sudo chmod -R o+w /var/www/html` (permette a tutti (`o-ther`) di creare un record (`w-rite`) nella directory `/var/www/html`).

Utilizzare questi comandi con cautela poiché influenzano direttamente la sicurezza del sistema.

Problema n. 2

Problema:

Se durante l'importazione dei database si verifica il seguente errore`ERROR 1049 (42000): Database sconosciuto 'db1'` (dove `db1` è il nome di un database), il database non è stato creato.

Soluzione:

Prova ad accedere a `mysql` e a ricreare questo database ancora una volta.

Problema n. 3

Problema:

Se quando si modifica il proprietario di file e directory, viene visualizzato il comando `chown: utente non valido: … `, è probabile che l'utente del server Web sia stato specificato in modo errato sul server.

Soluzione:

Consulta le guide corrispondenti sulla configurazione del server nel tuo sistema o usa l'utility `ps aux` per determinare l'utente giusto.

Problema n. 4

Problema:

Se si verificano errori PHP all'avvio di Magento su un nuovo server (di norma significa l'assenza di alcune estensioni PHP)...

Soluzione:

Questo può essere risolto installando le estensioni mancanti.

a) `È necessaria l'estensione json di PHP per utilizzare NormalizerFormatter di Monolog` ―

Manca l'estensione *php-json*;

b) `Errore irreversibile PHP: Errore non rilevato: Classe 'DOMDocument' non trovata in …` ―

Manca l'estensione *php-xml*;

c) `Errore irreversibile PHP: classe 'IntlDateFormatter' non trovata in …` ―

Manca l'estensione *php-intl*.

Problema n. 5

Problema:

Se le estensioni PHP mancano durante l'esecuzione del comando `comoser update`, vedrai i seguenti errori:

Per esempio,

`phpunit/phpunit 6.5.14 richiede ext-mbstring * -> l'estensione PHP richiesta mbstring manca dal tuo sistema.`

Soluzione:

Per gestire tali errori, devi semplicemente installare le estensioni PHP a cui si riferisce il compositore. Ad esempio, `yum install php-mbstring`.

Un elenco completo delle estensioni richieste per la tua versione di Magento 2 può essere trovato nella documentazione ufficiale.

Linea di fondo

Siete a posto! In questo articolo, ho fatto del mio meglio per presentare passaggi facili da seguire per trasferire il tuo sito Magento 2 da localhost al server.

Se hai ancora domande o desideri condividere la tua opinione, sentiti libero di utilizzare la sezione commenti qui sotto. Farò del mio meglio per rispondere a tutte le domande e dubbi!