Cum se transferă site-ul Magento 2 de la Localhost pe Server?

Procesul de transfer al unui site bazat pe Magento 2 de la o gazdă locală la alta nu este un proces care necesită timp. Cu toate acestea, are o serie de detalii esențiale și aspecte speciale care ar trebui luate în considerare înainte de a se introduce în proces.

În această postare pe blog, vom face transferul unui site Magento 2 de la localhost pe server la fel de ușor ca Lego. Să avem o perspectivă.

Etapele principale

Pentru început, să aruncăm o privire la pașii principali ai transferului:

1. Verificarea corectă a site-ului Magento 2 pe gazda curentă (A);
2. Pregătirea gazdei la distanță (B);
3. Verificarea gazdei de la distanță (B);
4. Pregătirea datelor pentru transfer; 4.1. File dump; 4.2. Dump-ul bazei de date;
5. Transfer de date;
6. Dezambalarea datelor; 6.1. despachetarea fișierelor; 6.2. Import de baze de date;
7. Corecția datelor de acces pe gazda la distanță (B);
8. Corectarea permisiunilor de acces la fișiere și directoare;
9. Proceduri standard înainte de lansarea Magento;
10. Verificări de performanță Magento pe gazda de la distanță (B);
11. Rezolvarea problemelor frecvente.

Ușor ca Lego: Ghid pas cu pas

1. Verificarea corectă a site-ului Magento 2 pe gazda actuală

Totul este ușor aici: alergați și verificați. De obicei, o comandă (ciclu complet) ar trebui creată în astfel de scopuri. Apoi verificați:

• căutare;
• pagini de produse,
• categorii,
• contul clientului.

Aceasta este o etapă importantă, deoarece vă permite să evitați luptele cu întrebări referitoare la momentul exact când ceva a încetat să funcționeze după mutarea la o nouă gazdă. De asemenea, acest lucru vă va scuti de necesitatea de a face față problemelor de bază ale gazdei care pot fi rezolvate în avans (A).

Vă încurajez să NU transferați pe jumătate o operare Magento fără nicio nevoie urgentă. Este mult mai ușor să rezolvați toate problemele de pe gazda actuală (A) înainte de a începe procesul de transfer. Dovedit și testat ― acest lucru vă va economisi atât timp, cât și durerea de gât.

2. Pregătirea gazdei la distanță (B).

Serverul, pe care este implementată copia Magento, trebuie să îndeplinească cerințele minime pentru versiunea dvs. Magento.

Studiați documentația oficială pentru a afla mai multe despre aceste cerințe: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

Mediul trebuie configurat înainte de a trece la următorii pași ai procesului de transfer (server web cu o gazdă virtuală, PHP, bază de date).

Din păcate, configurația fiecărei părți separate este dincolo de limitele acestui articol. Cu toate acestea, puteți găsi cu ușurință informațiile suplimentare necesare pe web. Deci, nu ar trebui să fie dificil.

Recomand să acordați o atenție deosebită prezenței extensiilor PHP necesare.

Dacă aveți întrebări cu privire la orice pas al acestui tutorial, vă rugăm să lăsați un comentariu. Voi face tot posibilul să răspund la toate.

3. Verificare la distanță a gazdei (B)

Înainte de a transfera Magento, asigurați-vă că funcționează pe noua gazdă și că gazda în sine funcționează corect. Mai întâi, verificați dacă serverul web răspunde la adresa menționată (presupunem că gazda a fost deja configurată).

În exemplul meu, folosesc calea standard care este disponibilă imediat după instalarea Apache2 pe serverul Linux:

> /var/www/html

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

*Aici și mai departe, comenzile vor fi executate de la utilizatorii corespunzători, dacă este necesar. Dacă comanda este rulată fără un nume de utilizator, atunci execuția comenzii ar trebui să fie înțeleasă ca de la utilizatorul curent și disponibilitatea oricăror permisiuni corespunzătoare.

Dacă nu apar erori după rularea acestei comenzi, atunci totul a mers bine și fișierul dvs. `index.php` trebuie să fie disponibil la următoarea adresă: {host}/index.php. Rezultatul din browser ar trebui să arate cam așa (deși multe depind încă de versiunea dvs. PHP):

Dacă ceva nu a mers prost și nu vedeți informații despre versiunea dvs. PHP, vă rugăm să adresați un ghid corespunzător despre configurarea unui server web de care aveți nevoie.

De asemenea, vă recomand să studiați jurnalele în avans - acest lucru vă va economisi o grămadă de timp.

Apoi, verificați dacă serviciul de bază de date a fost lansat și funcționează corect:

 mysql -u root -p

Ca rezultat, ar trebui să vă conectați cu succes la MySQL. Utilizați comanda `exit` pentru a ieși.

* Introduceți datele de conectare și parola pe care le-ați folosit la configurarea MySQL.

În plus, după conectarea cu succes la MySQL, va trebui să verificați bazele de date existente.

 SHOW databases;

Numele bazelor de date pe care intenționați să le transferați nu trebuie să fie aceleași cu cele care există deja pe noul server. În cazul în care există baze de date similare, această problemă ar trebui rezolvată manual prin ștergerea unei baze de date existente, dar neutilizate, de exemplu, sau prin redenumirea unei baze de date Magento pe care intenționați să o transferați. Rețineți că trebuie neapărat să introduceți numele schimbat în fișierul de configurare al mediului Magento `app/etc/env.php`.

Rezultatul dvs. ar trebui să arate după cum urmează:

De asemenea, ar trebui să verificați dacă serviciul în sine a fost lansat și ascultă portul standard folosind utilitarul netstat :

 netstat -vulntp | grep -i mysql

Rezultatul dvs. va arăta după cum urmează:

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

4. Pregătirea datelor pentru transfer

4.1. Dump de fișiere

Înainte de a crea un dump de fișiere, vă încurajez cu tărie să luați toate fișierele inutile din directorul Magento, dacă există, de exemplu, dumpuri vechi, cache, jurnale etc.

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

Acest lucru vă va permite să scurtați procesul. Pe lângă faptul că vă scutiți de transferul fișierelor inutile, veți evita utilizarea spațiului serverului fără nicio nevoie specială.

*NU ștergeți forțat `.htaccess` și alte fișiere ascunse, dacă utilizați serverul web Apache2 (comanda `rf` nu le șterge implicit). Aceste fișiere sunt necesare pentru funcționarea corectă a Magento.

Acum, mergeți la directorul în care se află Magento pe serverul local (A). În exemplul meu, este:

 > /Users/sergei/PhpstormProjects

Directorul cu Magento este numit sub aws-botapi .

Să creăm o arhivă pentru transferul ei ulterior către gazda la distanță (B):

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

Ar trebui să verificați dacă arhiva a fost creată:

 ls -la aws-botapi.tar.gz

4.2. Dump-ul bazelor de date

Dacă există mai multe baze de date separate care sunt aranjate local pe site-ul dvs. Magento, atunci toate acestea trebuie transferate. În exemplul meu, sunt utilizate două baze de date. Le puteți găsi în configurațiile mediului Magento `app/etc/env.php` din secțiunea `db => connection => `.

Acum, aruncați toate bazele de date:

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

* Folosiți informații precum numele de utilizator și numele bazei de date.

5. Transfer de date

Transferați fișierele Magento descarcă folosind utilitarul `scp` (copiere prin ssh) sau utilizați orice alte mijloace după cum doriți (de exemplu, copierea prin `ftp`):

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

Unde,

a) -i ~/.ssh/myprivatekey.pem este calea către cheia privată pentru conectare (ignorați acest lucru dacă utilizați numai parola);

b) ec2-user este numele de utilizator pentru conexiune;

c) 52.12.187.98 este adresa serverului;

d) /home/ec2-user este calea absolută de pe server, unde copiam fișierele.

*Dacă utilizați un port care este diferit de cel standard, nu uitați să îl identificați folosind un parametru separat (de exemplu, `-P 6000` pentru portul 6000).

După finalizarea copierii, veți vedea o linie de genul:

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

Repetați aceleași acțiuni pentru descărcarea fișierelor:

 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. Dezambalarea datelor

6.1. Despachetarea fișierelor

Pe server (B), să navigăm la directorul în care am copiat arhivele. Să despachetăm fișierele Magento în directorul gazdei locale:

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

Asigurați-vă că verificați dacă fișierele au fost despachetate corect:

 ls -la /var/www/html

Dacă fișierele Magento au fost despachetate în subdirector, transferați-le folosind fie comenzile `mv`, fie `cp`.

6.2. Import de baze de date

Conectați-vă la MySQL pe server (B):

 mysql -u root -p

Acum, să creăm o nouă bază de date:

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

*Rezultatul ar trebui să arate cam așa:

 > Query OK, 1 row affected (0.01 sec)

Efectuați acțiuni similare în cazul în care aveți alte baze de date.

Apoi, importați baze de date din 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

Conectați-vă la MySQL:

 mysql -u root -p

și verificați dacă toate bazele de date sunt prezente:

 SHOW databases;

Lista tuturor bazelor de date trebuie să fie disponibilă, inclusiv a noastră:

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

Selectați baza de date pe care tocmai am importat-o:

 USE db1;

și verificați prezența tabelelor:

 SHOW tables;

În cazul în care tabelele nu au fost create sau sunt goale, verificați fișierul dump în sine și repetați încă o dată întregul proces, cu excepția pasului în care a fost creată o nouă bază de date (cum există deja).

7. Accesați corecția datelor pe gazda la distanță (B)

Principalele date care ar trebui modificate în Magento după ce au fost transferate sunt 1) adrese URL de bază și 2) chei de acces la MySQL:

Modificarea adreselor URL de bază

Va trebui să modificați toate căile vechi din tabelul `core_config_data`. Pentru început, să localizăm aceste câmpuri folosind interogarea „valoare” care include adresa veche. Să presupunem că adresa veche a site-ului web era „1001101010.com”, apoi comanda de căutare va arăta după cum urmează:

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

*`\G` la sfârșitul interogării în loc de `;` va face înregistrările mai ușor de citit.

** Nu uitați să folosiți `table_prefix` înainte de numele tabelelor dacă a fost instalat.

Rezultatul va arăta cam aș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)

În acest moment, scopul nostru este să schimbăm vechea adresă cu una nouă. În acest scop, să ne asigurăm că trebuie schimbat într-adevăr în toate liniile (așa este de cele mai multe ori, cu excepția unor cazuri rare care implică configurarea modulelor terțe) și rulăm următoarea interogare:

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

Acesta va înlocui toate aparițiile liniilor `1001101010.com` din câmpul `valoare` în linia `mynewdomain.com`.

Rezultatul ar trebui să fie aproximativ după cum urmează (numărul de linii ar trebui să fie egal):

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

Următoarea cerere:

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

Acum, este timpul să trecem la editarea fișierului mediului `app/etc/env.php` (din rădăcina Magento; în exemplu, era `/var/www/html/`).

Să-l deschidem într-un program de editare de text (eu folosesc Nano , deși cu siguranță este problema preferințelor personale).

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

Apoi editați datele în `'db' => 'conexiune'` specificând datele exacte de la noul server în câmpurile 'nume utilizator' și 'parolă'.

* IMPORTANT! Dacă baza de date se află pe un server la distanță, nu este nevoie să modificați datele. Singurul lucru pe care trebuie să-l faceți este să vă asigurați că există acces de la serverul curent la acea bază de date de la distanță. (De exemplu, că a fost adăugat la lista albă de firewall de pe serverul bazei de date).

Utilizați valoarea „localhost” din câmpul „gazdă” pentru a înțelege dacă conexiunea este locală sau nu.

Apoi, salvați fișierul.

8. Corectarea permisiunilor de acces la fișiere și directoare

Pentru a configura cu exactitate permisiunile de acces, trebuie să știți de la ce utilizator și cu ce grup rulează serverul dvs. web.

Cel mai frecvent, este fie „apache” pentru CentOS, fie „www-data” în Ubuntu. De regulă, numele de utilizator este egal cu numele grupului. Cu toate acestea, pe diferite servere, acest lucru poate diferi.

Următoarea comandă vă va ajuta să vă dați seama:

 ps aux | egrep '(apache|httpd)'

Ca rezultat, în prima coloană, veți vedea numele de utilizator (numele grupului este probabil să fie același. Cu toate acestea, dacă nu sunteți sigur, utilizați comanda `groups apache`, unde `apache` este numele de utilizator pentru a verifică).

Primul lucru după aceasta, va trebui să transferăm toate fișierele și directoarele din interiorul Magento către utilizatorul serverului web (este `apache` în exemplu. Pentru utilizatorul `www-data` pur și simplu înlocuiți `apache:apache` cu ` www-data:www-data` și, în mod similar, pentru alții):

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

Apoi, verificați dacă modificările au fost aplicate sau nu:

 ls -la /var/www/html

Toate fișierele și directoarele (cu excepția celui părinte marcat ca `..` trebuie să aibă un utilizator și grupul `apache` (dacă `www-data` este un utilizator de server web în sistemul dvs., atunci ar trebui să fie marcat ca un proprietar):

Acum, este necesar să configurați cu precizie permisiunile de acces la fișierele și directoarele Magento. Conform documentației, următoarea configurare este foarte recomandată:

*Toate comenzile trebuie să fie executate de la rădăcina Magento!, în mod constant 1 după 1. În exemplu, rădăcina Magento de pe server este `/var/www/html`.

Utilizați comanda `pwd` pentru a verifica locația curentă.

 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

*Dacă utilizatorul actual nu are permisiunea de a rula aceste comenzi, utilizați `root` a utilizatorului (comanda `sudo`, cum ar fi `sudo find...`)

9. Proceduri standard înainte de lansarea Magento

Este timpul să verificați dacă Magento se lansează din linia de comandă. Pentru început, să testăm rezultatul standard al comenzilor la care ai acces:

*Acum, după configurarea permisiunilor, orice acces la Magento se va face de la același utilizator de server web care generează fișiere, fișiere cache, statice etc. Dacă ignorați acest lucru, Magento poate înceta să ruleze și veți fi forțat să restaurați permisiunile încă o dată (pasul anterior din aceste ghiduri).

**Pentru o operare precisă, va trebui să găsiți interpretul php potrivit pe serverul dvs. De obicei, alias `php` se referă la versiunea actualizată. Cu toate acestea, va trebui adesea să indicați calea completă, cum ar fi `/usr/bin/php72`, de exemplu.

***Aici și mai departe, toate comenzile Magento vor rula din directorul rădăcină Magento de pe server (B).

 sudo -u apache php bin/magento list

Aceasta va face lista cu comenzile disponibile în linia de comenzi:

Dacă totul a decurs cu succes, puteți trece la comenzile ulterioare:

*Dacă înainte de transfer nu ați șters directoarele cu memoria cache și fișierele generate, acesta este momentul potrivit pentru a face asta folosind următoarea comandă:

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

 sudo -u apache php bin/magento setup:upgrade

Puteți evita rularea acestei comenzi, dar tot recomand să vă asigurați că toate modulele sunt scrise și că nu apar erori. Ca rezultat, veți vedea o listă cu module, care au fost procesate, fără a vedea erori în proces.

Efectuați compilarea pentru a genera fișierele Magento necesare:

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

*În acest moment, este esențial să detectați toate erorile care au apărut. În caz contrar, Magento va rula incorect. Dacă nu s-au găsit erori, atunci totul este perfect. ?

Apoi, generați statice (dacă modul de producție este activat. Pentru a verifica modul curent, utilizați următoarea comandă:

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

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

*Pentru a genera statice pentru o anumită locație, specificați-o ca parametru după comandă. De exemplu, `sudo -u apache php bin/magento setup:static-content:deploy ru_RU` va fi folosit pentru limba rusă.

Felicitări! Ați transferat cu succes magazinul Magento2 de la localhost pentru a funcționa corect pe un nou server. Acum, deschideți-l într-un browser introducând o nouă adresă!

10. Depanare: probleme frecvente

Problema #1

Problemă:

Dacă la copierea arhivei, primiți un mesaj de genul:

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

Apoi ar trebui să verificați unde ați copiat arhiva pe server în primul rând. Este foarte probabil ca utilizatorul care intenționează să se conecteze să nu aibă permisiunea de a face o înregistrare în acest director (`/var/www/html` în exemplu).

Soluţie:

Acest lucru poate fi rezolvat prin schimbarea directorului în care încercați să copiați la rularea comenzii ` scp ` sau conectarea la server și ajustând permisiunile de acces la acest director pentru utilizatorul curent:

`sudo chown -R ec2-user /var/www/html` (faceți un utilizator proprietarul directorului `/var/www/html` și al tuturor fișierelor și directoarelor incluse), sau

`sudo chmod -R o+w /var/www/html` (permite tuturor (`o-ther`) să facă o înregistrare (`w-rite`) în directorul `/var/www/html`).

Utilizați aceste comenzi cu prudență, deoarece influențează direct securitatea sistemului dumneavoastră.

Problema #2

Problemă:

Dacă la importarea bazelor de date apare următoarea eroare`ERROR 1049 (42000): Baza de date necunoscută 'db1'` (unde `db1` este numele unei baze de date), atunci baza de date nu a fost creată.

Soluţie:

Încercați să accesați`mysql` și să recreați această bază de date încă o dată.

Problema #3

Problemă:

Dacă atunci când schimbați proprietarul fișierelor și directoarelor, vedeți comanda `chown: utilizator invalid: … `, atunci probabil că ați specificat incorect utilizatorul serverului web pe serverul dvs.

Soluţie:

Consultați ghidurile corespunzătoare despre configurarea serverului din sistemul dumneavoastră sau utilizați utilitarul `ps aux` pentru a determina utilizatorul potrivit.

Problema #4

Problemă:

Dacă există erori PHP la pornirea Magento pe un server nou (de regulă, înseamnă absența unor extensii PHP)...

Soluţie:

Acest lucru poate fi rezolvat prin instalarea extensiilor lipsă.

a) „Extensia json a PHP este necesară pentru a utiliza NormalizerFormatter de la Monolog” ―

Extensia *php-json* lipsește;

b) „Eroare fatală PHP: Eroare neprinsă: Clasa „DOMDocument” nu a fost găsită în...” ―

Extensia *php-xml* lipsește;

c) „Eroare fatală PHP: clasa „IntlDateFormatter” nu a fost găsită în...” ―

Extebnsion *php-intl* lipsește.

Problema #5

Problemă:

Dacă extensiile PHP lipsesc atunci când rulați comanda `composer update`, veți vedea următoarele erori:

De exemplu,

`phpunit/phpunit 6.5.14 necesită ext-mbstring * -> extensia PHP solicitată mbstring lipsește din sistemul dumneavoastră.`

Soluţie:

Pentru a face față unor astfel de erori, trebuie să instalați pur și simplu extensiile PHP la care se referă compozitorul. De exemplu, `yum install php-mbstring`.

O listă completă a extensiilor necesare pentru versiunea dvs. Magento 2 poate fi găsită în documentația oficială.

Concluzie

Sunteți gata! În acest articol, am făcut tot posibilul să prezint pași ușor de urmat pentru transferul site-ului dvs. Magento 2 de la localhost pe server.

Dacă mai aveți întrebări sau doriți să vă împărtășiți opinia, nu ezitați să folosiți secțiunea de comentarii de mai jos. Voi face tot posibilul să răspund la toate întrebările și preocupările!