วิธีโอนไซต์ Magento 2 จาก Localhost ไปยังเซิร์ฟเวอร์

ขั้นตอนการถ่ายโอนไซต์ที่ใช้ Magento 2 จากโฮสต์ท้องถิ่นหนึ่งไปยังอีกโฮสต์หนึ่งไม่ใช่กระบวนการที่ใช้เวลานาน อย่างไรก็ตาม มีรายละเอียดที่สำคัญและแง่มุมพิเศษที่ควรพิจารณาก่อนที่จะเข้าสู่กระบวนการ

ในบล็อกโพสต์นี้ เราจะทำการถ่ายโอนไซต์ Magento 2 จาก localhost ไปยังเซิร์ฟเวอร์ได้ง่ายเหมือน Lego มาทำความเข้าใจกัน

ขั้นตอนหลัก

เริ่มต้นด้วย มาดูขั้นตอนหลักของการโอนกัน:

1. การตรวจสอบความปกติของไซต์ Magento 2 บนโฮสต์ปัจจุบัน (A);
2. เตรียมรีโมตโฮสต์ให้พร้อม (B);
3. การตรวจสอบโฮสต์ระยะไกล (B);
4. การเตรียมข้อมูลให้พร้อมสำหรับการถ่ายโอน 4.1. ไฟล์ดัมพ์; 4.2. การถ่ายโอนข้อมูลฐานข้อมูล
5. การถ่ายโอนข้อมูล;
6. การเปิดข้อมูล; 6.1. การเปิดไฟล์; 6.2. นำเข้าฐานข้อมูล
7. เข้าถึงการแก้ไขข้อมูลบนโฮสต์ระยะไกล (B);
8. การแก้ไขสิทธิ์การเข้าถึงไฟล์และไดเร็กทอรี
9. ขั้นตอนมาตรฐานก่อนเปิดตัว Magento;
10. การตรวจสอบประสิทธิภาพของวีโอไอพีบนรีโมตโฮสต์ (B);
11. การแก้ปัญหาที่พบบ่อย

ง่ายเหมือนเลโก้: คำแนะนำทีละขั้นตอน

1. ตรวจสอบความปกติของไซต์ Magento 2 บนโฮสต์ปัจจุบัน

ทั้งหมดเป็นเรื่องง่ายที่นี่: เรียกใช้และตรวจสอบ โดยปกติ ใบสั่ง (เต็มรอบ) ควรถูกสร้างขึ้นเพื่อวัตถุประสงค์ดังกล่าว จากนั้นตรวจสอบ:

• ค้นหา;
• หน้าสินค้า,
• หมวดหมู่
• บัญชีของลูกค้า

นี่เป็นขั้นตอนที่สำคัญเนื่องจากช่วยให้คุณหลีกเลี่ยงการต่อสู้กับคำถามที่ว่าเมื่อไรบางอย่างหยุดทำงานหลังจากย้ายไปยังโฮสต์ใหม่ นอกจากนี้ วิธีนี้จะช่วยคุณประหยัดจากความจำเป็นในการจัดการกับปัญหาโฮสต์พื้นฐานที่สามารถแก้ไขได้ล่วงหน้า (A)

ฉันสนับสนุนให้คุณอย่าโอน a โดยแบ่งเท่า ๆ กันที่ใช้งาน Magento โดยไม่จำเป็นต้องเร่งด่วน ง่ายกว่ามากในการจัดการกับปัญหาทั้งหมดบนโฮสต์ปัจจุบัน (A) ก่อนเริ่มกระบวนการถ่ายโอน พิสูจน์และทดสอบแล้ว - วิธีนี้จะช่วยคุณประหยัดเวลาและอาการปวดคอ

2. เตรียมรีโมตโฮสต์ (B) ให้พร้อม

เซิร์ฟเวอร์ที่ใช้สำเนา Magento ต้องเป็นไปตามข้อกำหนดขั้นต่ำสำหรับเวอร์ชัน Magento ของคุณ

ศึกษาเอกสารอย่างเป็นทางการเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดเหล่านั้น: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

ต้องตั้งค่าสภาพแวดล้อมก่อนที่จะดำเนินการในขั้นตอนต่อไปของกระบวนการถ่ายโอน (เว็บเซิร์ฟเวอร์ที่มีโฮสต์เสมือน, PHP, ฐานข้อมูล)

น่าเสียดายที่การกำหนดค่าของแต่ละส่วนที่แยกจากกันนั้นอยู่นอกเหนือบทความนี้ อย่างไรก็ตาม คุณสามารถค้นหาข้อมูลเพิ่มเติมที่จำเป็นบนเว็บได้อย่างง่ายดาย ดังนั้นจึงไม่น่าจะยาก

ฉันแนะนำให้ให้ความสนใจเป็นพิเศษกับการมีอยู่ของส่วนขยาย PHP ที่จำเป็น

หากคุณมีคำถามใดๆ เกี่ยวกับขั้นตอนใดๆ ของบทช่วยสอนนี้ โปรดแสดงความคิดเห็น ฉันจะทำให้ดีที่สุดเพื่อตอบพวกเขาทั้งหมด

3. การตรวจสอบโฮสต์ระยะไกล (B)

ก่อนโอน Magento ตรวจสอบให้แน่ใจว่ามันทำงานบนโฮสต์ใหม่และโฮสต์นั้นทำงานอย่างถูกต้อง ขั้นแรก ตรวจสอบว่าเว็บเซิร์ฟเวอร์ตอบสนองตามที่อยู่ที่ระบุ (เราคิดว่าโฮสต์ได้รับการกำหนดค่าแล้ว)

ในตัวอย่างของฉัน ฉันใช้เส้นทางมาตรฐานที่พร้อมใช้งานทันทีหลังจากติดตั้ง Apache2 บนเซิร์ฟเวอร์ Linux:

> /var/www/html

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

*ที่นี่และต่อไป คำสั่งจะถูกเรียกใช้จากผู้ใช้ที่เกี่ยวข้อง หากจำเป็น หากคำสั่งถูกรันโดยไม่มีชื่อผู้ใช้ การเรียกใช้คำสั่งควรหมายถึงจากผู้ใช้ปัจจุบันและความพร้อมใช้งานของสิทธิ์ที่เกี่ยวข้อง

หากไม่มีข้อผิดพลาดปรากฏขึ้นหลังจากเรียกใช้คำสั่งนี้ แสดงว่าทุกอย่างเป็นไปด้วยดี และไฟล์ `index.php' ของคุณต้องอยู่ในที่อยู่ต่อไปนี้: {host}/index.php. ผลลัพธ์ในเบราว์เซอร์ของคุณควรมีลักษณะดังนี้ (แต่ยังคงขึ้นอยู่กับเวอร์ชัน PHP ของคุณ):

หากมีข้อผิดพลาดและคุณไม่เห็นข้อมูลเกี่ยวกับเวอร์ชัน PHP ของคุณ โปรดระบุคำแนะนำที่เกี่ยวข้องเกี่ยวกับการกำหนดค่าเว็บเซิร์ฟเวอร์ที่คุณต้องการ

นอกจากนี้ ฉันยังแนะนำให้ศึกษาบันทึกล่วงหน้า ซึ่งจะช่วยประหยัดเวลาของคุณได้มาก

ถัดไป ตรวจสอบว่าบริการฐานข้อมูลเปิดตัวและทำงานอย่างถูกต้อง:

 mysql -u root -p

ด้วยเหตุนี้ คุณจึงควรเชื่อมต่อกับ MySQL ได้สำเร็จ ใช้คำสั่ง `exit` เพื่อออก

* เข้าสู่ระบบและรหัสผ่านที่คุณใช้เมื่อตั้งค่า MySQL

นอกจากนี้ หลังจากเชื่อมต่อกับ MySQL สำเร็จแล้ว คุณจะต้องตรวจสอบฐานข้อมูลที่มีอยู่

 SHOW databases;

ชื่อของฐานข้อมูลที่คุณวางแผนจะถ่ายโอนต้องไม่เหมือนกับฐานข้อมูลที่มีอยู่แล้วบนเซิร์ฟเวอร์ใหม่ ในกรณีที่มีฐานข้อมูลที่คล้ายกัน ปัญหานี้ควรแก้ไขด้วยตนเองโดยการลบฐานข้อมูลที่มีอยู่แต่ไม่ได้ใช้ เช่น หรือการเปลี่ยนชื่อฐานข้อมูล Magento ที่คุณต้องการโอน โปรดทราบว่าคุณต้องป้อนชื่อที่เปลี่ยนแปลงในไฟล์การกำหนดค่าของสภาพแวดล้อมวีโอไอพี `app/etc/env.php'

ผลลัพธ์ของคุณควรมีลักษณะดังนี้:

นอกจากนี้ คุณต้องตรวจสอบว่าบริการนี้เปิดตัวแล้วและรับฟังพอร์ตมาตรฐานโดยใช้ยูทิลิตี้ netstat :

 netstat -vulntp | grep -i mysql

ผลลัพธ์ของคุณจะมีลักษณะดังนี้:

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

4. การเตรียมข้อมูลให้พร้อมสำหรับการถ่ายโอน

4.1. ไฟล์ดัมพ์

ก่อนสร้างไฟล์ดัมพ์ เราขอแนะนำให้คุณนำไฟล์ที่ไม่จำเป็นทั้งหมดออกจากไดเร็กทอรี Magento หากมี เช่น ไฟล์เก่า แคช บันทึก ฯลฯ

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

นี้จะช่วยให้คุณย่นกระบวนการ นอกจากช่วยคุณจากการถ่ายโอนไฟล์ที่ไม่จำเป็นแล้ว คุณจะหลีกเลี่ยงการใช้พื้นที่เซิร์ฟเวอร์โดยไม่จำเป็น

*อย่าบังคับลบ `.htaccess' และไฟล์ที่ซ่อนอยู่อื่นๆ หากคุณใช้เว็บเซิร์ฟเวอร์ Apache2 (คำสั่ง `rf` จะไม่ลบออกโดยค่าเริ่มต้น) ไฟล์เหล่านี้จำเป็นสำหรับการดำเนินการ Magento ที่ถูกต้อง

ตอนนี้ ไปที่ไดเร็กทอรีที่ Magento ของเราอยู่ในเซิร์ฟเวอร์ภายใน (A) ในตัวอย่างของฉันคือ:

 > /Users/sergei/PhpstormProjects

ไดเร็กทอรีที่มี Magento ถูกตั้งชื่อภายใต้ aws-botapi

มาสร้างไฟล์เก็บถาวรเพื่อถ่ายโอนไปยังรีโมตโฮสต์ (B):

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

คุณควรตรวจสอบว่ามีการสร้างไฟล์เก็บถาวรแล้ว:

 ls -la aws-botapi.tar.gz

4.2. ฐานข้อมูลดัมพ์

หากมีฐานข้อมูลแยกกันหลายฐานข้อมูลที่จัดเรียงไว้ภายในไซต์ Magento ของคุณ ฐานข้อมูลทั้งหมดจะต้องถูกถ่ายโอน ในตัวอย่างของฉัน มีการใช้ฐานข้อมูลสองฐานข้อมูล คุณสามารถค้นหาได้ในการกำหนดค่าของสภาพแวดล้อม Magento `app/etc/env.php` ในส่วน `db => connection => `

ตอนนี้ ดัมพ์ฐานข้อมูลทั้งหมด:

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

*ใช้ข้อมูลเช่นชื่อผู้ใช้ฐานข้อมูลและชื่อฐานข้อมูล

5. การถ่ายโอนข้อมูล

ถ่ายโอนไฟล์ Magento ดัมพ์โดยใช้ยูทิลิตี้ `scp` (คัดลอกผ่าน ssh) หรือใช้วิธีการอื่นตามความสะดวกของคุณ (เช่น การคัดลอกผ่าน `ftp`):

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

ที่ไหน,

a) -i ~/.ssh/myprivatekey.pem เป็นเส้นทางไปยังคีย์ส่วนตัวสำหรับการเชื่อมต่อ (ไม่ต้องสนใจหากคุณใช้รหัสผ่านเพียงอย่างเดียว);

b) ผู้ใช้ ec2- เป็นชื่อผู้ใช้สำหรับการเชื่อมต่อ

c) 52.12.187.98 คือที่อยู่เซิร์ฟเวอร์

d) /home/ec2-user เป็นพาธสัมบูรณ์บนเซิร์ฟเวอร์ ไปยังตำแหน่งที่เราคัดลอกไฟล์

*หากคุณใช้พอร์ตที่แตกต่างจากพอร์ตมาตรฐาน อย่าลืมระบุพอร์ตโดยใช้พารามิเตอร์แยกต่างหาก (เช่น `-P 6000` สำหรับพอร์ต 6000)

หลังจากคัดลอกเสร็จแล้ว คุณจะเห็นบรรทัดประเภท:

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

ทำซ้ำการกระทำเดียวกันสำหรับไฟล์ดัมพ์:

 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. การเปิดข้อมูล

6.1. แตกไฟล์

บนเซิร์ฟเวอร์ (B) ให้ไปที่ไดเร็กทอรีที่เราคัดลอกไฟล์เก็บถาวรไป มาแตกไฟล์ Magento ไปยังไดเร็กทอรีของโลคัลโฮสต์:

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

ตรวจสอบให้แน่ใจว่าได้แตกไฟล์อย่างถูกต้อง:

 ls -la /var/www/html

หากไฟล์ Magento ถูกแตกไปยังไดเร็กทอรีย่อย ให้โอนไฟล์โดยใช้คำสั่ง `mv` หรือ `cp`

6.2. นำเข้าฐานข้อมูล

เชื่อมต่อกับ MySQL บนเซิร์ฟเวอร์ (B):

 mysql -u root -p

ตอนนี้ มาสร้างฐานข้อมูลใหม่:

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

*ผลลัพธ์ควรมีลักษณะดังนี้:

 > Query OK, 1 row affected (0.01 sec)

ทำการดำเนินการที่คล้ายกันในกรณีที่คุณมีฐานข้อมูลอื่น

จากนั้นนำเข้าฐานข้อมูลจากดัมพ์:

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

เชื่อมต่อกับ MySQL:

 mysql -u root -p

และตรวจสอบว่ามีฐานข้อมูลทั้งหมด:

 SHOW databases;

รายการฐานข้อมูลทั้งหมดต้องพร้อมใช้งาน รวมถึงฐานข้อมูลของเรา:

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

เลือกฐานข้อมูลที่เราเพิ่งนำเข้า:

 USE db1;

และตรวจสอบการมีอยู่ของตาราง:

 SHOW tables;

ในกรณีที่ไม่ได้สร้างตารางหรือว่างเปล่า ให้ตรวจสอบไฟล์ดัมพ์และทำซ้ำขั้นตอนทั้งหมดอีกครั้ง ยกเว้นขั้นตอนเมื่อสร้างฐานข้อมูลใหม่ (เนื่องจากมีอยู่แล้ว)

7. เข้าถึงการแก้ไขข้อมูลบนโฮสต์ระยะไกล (B)

ข้อมูลหลักที่ควรเปลี่ยนใน Magento หลังจากถ่ายโอนคือ 1) URL พื้นฐานและ 2) คีย์การเข้าถึง MySQL:

การเปลี่ยน URL พื้นฐาน

คุณจะต้องเปลี่ยนเส้นทางเก่าทั้งหมดในตาราง `core_config_data` ในการเริ่มต้น ให้แปลฟิลด์เหล่านี้โดยใช้แบบสอบถาม 'value' ที่มีที่อยู่เก่า สมมติว่าที่อยู่เว็บไซต์เดิมคือ '1001101010.com' จากนั้นคำสั่งค้นหาจะมีลักษณะดังนี้:

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

*`\G` ที่ท้ายข้อความค้นหาแทนที่จะเป็น `;` จะทำให้บันทึกอ่านง่ายขึ้น

** อย่าลืมใช้ `table_prefix' ก่อนชื่อตารางหากติดตั้งไว้

ผลลัพธ์จะมีลักษณะดังนี้:

 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)

ณ จุดนี้เป้าหมายของเราคือเปลี่ยนที่อยู่เก่าเป็นที่อยู่ใหม่ เพื่อจุดประสงค์นี้ ให้ตรวจสอบให้แน่ใจว่าควรมีการเปลี่ยนแปลงในทุกบรรทัด (โดยส่วนใหญ่แล้ว ยกเว้นกรณีหายากบางกรณีที่เกี่ยวข้องกับการกำหนดค่าโมดูลบุคคลที่สาม) และเรียกใช้แบบสอบถามต่อไปนี้:

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

มันจะแทนที่บรรทัด "1001101010.com" ทั้งหมดในฟิลด์ "value" เป็นบรรทัด "mynewdomain.com"

ผลลัพธ์ควรเป็นดังนี้ (จำนวนบรรทัดควรเท่ากัน):

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

คำขอดังต่อไปนี้:

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

ตอนนี้ ได้เวลาดำเนินการแก้ไขไฟล์ของสภาพแวดล้อม `app/etc/env.php` (จากรูทของ Magento ในตัวอย่างคือ `/var/www/html/`)

ให้เปิดในโปรแกรมแก้ไขข้อความ (ฉันใช้ Nano แม้ว่าจะเป็นคำถามเกี่ยวกับความชอบส่วนตัวก็ตาม)

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

จากนั้นแก้ไขข้อมูลใน `'db' => 'connection'` โดยระบุข้อมูลที่ถูกต้องจากเซิร์ฟเวอร์ใหม่ในฟิลด์ 'ชื่อผู้ใช้' และ 'รหัสผ่าน'

* สำคัญ! ถ้าฐานข้อมูลของคุณอยู่บนเซิร์ฟเวอร์ระยะไกล ไม่จำเป็นต้องเปลี่ยนข้อมูล สิ่งเดียวที่คุณต้องทำคือต้องแน่ใจว่ามีการเข้าถึงจากเซิร์ฟเวอร์ปัจจุบันไปยังฐานข้อมูลระยะไกลนั้น (ตัวอย่างเช่น มันถูกเพิ่มลงในรายการไฟร์วอลล์ที่อนุญาตบนเซิร์ฟเวอร์ฐานข้อมูล)

ใช้ค่า 'localhost' ในฟิลด์ 'host' เพื่อทำความเข้าใจว่าการเชื่อมต่อนั้นเป็นการเชื่อมต่อภายในหรือไม่

ถัดไป บันทึกไฟล์.

8. การแก้ไขสิทธิ์การเข้าถึงไฟล์และไดเรกทอรี

ในการตั้งค่าสิทธิ์การเข้าถึงอย่างถูกต้อง คุณจำเป็นต้องรู้ว่าผู้ใช้รายใดและกลุ่มใดที่เว็บเซิร์ฟเวอร์ของคุณทำงาน

ส่วนใหญ่มักจะเป็น "apache" สำหรับ CentOS หรือ "www-data" ใน Ubuntu ตามกฎแล้วชื่อผู้ใช้จะเท่ากับชื่อกลุ่ม อย่างไรก็ตาม ในเซิร์ฟเวอร์ที่แตกต่างกัน สิ่งนี้อาจแตกต่างกัน

คำสั่งต่อไปนี้จะช่วยให้คุณเข้าใจ:

 ps aux | egrep '(apache|httpd)'

ดังนั้น ในคอลัมน์แรก คุณจะเห็นชื่อผู้ใช้ (ชื่อกลุ่มน่าจะเหมือนกัน อย่างไรก็ตาม หากคุณไม่แน่ใจ ให้ใช้คำสั่ง `groups apache` โดยที่ `apache' คือชื่อผู้ใช้เพื่อ ตรวจสอบออก)

สิ่งแรกหลังจากนี้ เราจะต้องถ่ายโอนไฟล์และไดเร็กทอรีทั้งหมดภายใน Magento ไปยังผู้ใช้เว็บเซิร์ฟเวอร์ (ในตัวอย่างคือ `apache` สำหรับผู้ใช้ `www-data' เพียงแค่เปลี่ยน `apache:apache` เป็น ` www-data:www-data` และในทำนองเดียวกันสำหรับผู้อื่น):

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

ถัดไป ตรวจสอบว่าการเปลี่ยนแปลงถูกนำไปใช้หรือไม่:

 ls -la /var/www/html

ไฟล์และไดเร็กทอรีทั้งหมด (ยกเว้นพาเรนต์ที่ทำเครื่องหมายเป็น `..` ต้องมีผู้ใช้และกลุ่ม 'apache' (หาก `www-data' เป็นผู้ใช้เว็บเซิร์ฟเวอร์ในระบบของคุณ ก็ควรทำเครื่องหมายเป็น เจ้าของ):

ตอนนี้ จำเป็นต้องตั้งค่าการอนุญาตการเข้าถึงไฟล์และไดเร็กทอรี Magento อย่างถูกต้อง ตามเอกสาร ขอแนะนำให้ตั้งค่าต่อไปนี้:

*คำสั่งทั้งหมดต้องรันจากรูทวีโอไอพี! โดยสม่ำเสมอ 1 หลัง 1 ในตัวอย่าง รูทวีโอไอพีบนเซิร์ฟเวอร์คือ `/var/www/html`

ใช้คำสั่ง `pwd` เพื่อตรวจสอบตำแหน่งปัจจุบัน

 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

*หากผู้ใช้ปัจจุบันไม่มีสิทธิ์เรียกใช้คำสั่งเหล่านี้ ให้ใช้ `root ` ของผู้ใช้ (คำสั่ง `sudo` เช่น `sudo find …`)

9. ขั้นตอนมาตรฐานก่อนเปิดตัว Magento

ถึงเวลาตรวจสอบว่า Magento เปิดใช้งานจากบรรทัดคำสั่งหรือไม่ เริ่มต้นด้วย มาทดสอบผลลัพธ์มาตรฐานของคำสั่งที่คุณเข้าถึงได้:

*ตอนนี้ หลังจากตั้งค่าการอนุญาต การเข้าถึง Magento จะทำจากผู้ใช้เว็บเซิร์ฟเวอร์คนเดียวกับที่สร้างไฟล์ ไฟล์แคช สแตติก ฯลฯ หากคุณเพิกเฉยต่อสิ่งนี้ Magento อาจหยุดทำงานและคุณจะถูกบังคับให้กู้คืนสิทธิ์ อีกครั้ง (ขั้นตอนก่อนหน้าในหลักเกณฑ์เหล่านี้)

**เพื่อการทำงานที่แม่นยำ คุณจะต้องค้นหาตัวแปล php ที่เหมาะสมบนเซิร์ฟเวอร์ของคุณ โดยปกติ นามแฝง `php' หมายถึงเวอร์ชันล่าสุด อย่างไรก็ตาม คุณมักจะต้องระบุพาธแบบเต็ม เช่น `/usr/bin/php72` เป็นต้น

***และต่อไป คำสั่งวีโอไอพีทั้งหมดจะทำงานจากไดเร็กทอรีรูทของวีโอไอพีบนเซิร์ฟเวอร์ (B)

 sudo -u apache php bin/magento list

สิ่งนี้จะทำให้รายการพร้อมคำสั่งที่มีอยู่ในบรรทัดคำสั่ง:

หากทุกอย่างสำเร็จ คุณสามารถดำเนินการตามคำสั่งเพิ่มเติม:

*หากก่อนการถ่ายโอน คุณไม่ได้ล้างไดเร็กทอรีที่มีแคชและไฟล์ที่สร้างขึ้น นี่เป็นเวลาที่เหมาะสมที่จะดำเนินการโดยใช้คำสั่งต่อไปนี้:

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

 sudo -u apache php bin/magento setup:upgrade

คุณสามารถหลีกเลี่ยงการเรียกใช้คำสั่งนี้ได้ แต่ฉันยังคงแนะนำให้ตรวจสอบให้แน่ใจว่าโมดูลทั้งหมดถูกเขียนขึ้นและไม่มีข้อผิดพลาดเกิดขึ้น ด้วยเหตุนี้ คุณจะเห็นรายการที่มีโมดูลซึ่งได้รับการประมวลผลแล้ว แต่ไม่เห็นข้อผิดพลาดใดๆ ในกระบวนการ

ดำเนินการคอมไพล์เพื่อสร้างไฟล์ Magento ที่จำเป็น:

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

* ณ จุดนี้ สิ่งสำคัญคือต้องตรวจหาข้อผิดพลาดทั้งหมดที่เกิดขึ้น มิฉะนั้น Magento จะทำงานไม่ถูกต้อง หากไม่พบข้อผิดพลาดแสดงว่าทุกอย่างสมบูรณ์แบบ ?

จากนั้น สร้างสแตติก (หากเปิดใช้งานโหมดการผลิต หากต้องการตรวจสอบโหมดปัจจุบันของคุณ ให้ใช้คำสั่งต่อไปนี้:

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

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

*หากต้องการสร้างสแตติกสำหรับโลแคลเฉพาะ ให้ระบุเป็นพารามิเตอร์หลังคำสั่ง ตัวอย่างเช่น `sudo -u apache php bin/magento setup:static-content:deploy ru_RU` จะถูกใช้สำหรับภาษารัสเซีย

ยินดีด้วย! คุณได้โอนร้านค้า Magento2 จาก localhost เพื่อดำเนินการอย่างถูกต้องบนเซิร์ฟเวอร์ใหม่ ตอนนี้เปิดในเบราว์เซอร์โดยป้อนที่อยู่ใหม่!

10. การแก้ไขปัญหา: ปัญหาบ่อย

ฉบับที่ #1

ปัญหา:

หากเมื่อคัดลอกไฟล์เก็บถาวร คุณจะได้รับข้อความประเภทนี้:

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

จากนั้นคุณควรตรวจสอบว่าคุณได้คัดลอกไฟล์เก็บถาวรบนเซิร์ฟเวอร์ไว้ที่ใดในอินสแตนซ์แรก มีความเป็นไปได้สูงที่ผู้ใช้ที่ตั้งใจจะเชื่อมต่อไม่มีสิทธิ์สร้างบันทึกในไดเร็กทอรีนี้ (`/var/www/html` ในตัวอย่าง)

วิธีการแก้:

ซึ่งสามารถแก้ไขได้โดยเปลี่ยนไดเร็กทอรีที่คุณพยายามคัดลอกเมื่อรันคำสั่ง ` scp ` หรือเชื่อมต่อกับเซิร์ฟเวอร์ และปรับสิทธิ์การเข้าถึงไดเร็กทอรีนี้สำหรับผู้ใช้ปัจจุบัน:

`sudo chown -R ec2-user /var/www/html` (กำหนดให้ผู้ใช้เป็นเจ้าของไดเร็กทอรี `/var/www/html` และไฟล์และไดเร็กทอรีที่รวมอยู่ทั้งหมด) หรือ

`sudo chmod -R o+w /var/www/html` (อนุญาตให้ทั้งหมด (`o-ther`) สร้างบันทึก (`w-rite`) ในไดเร็กทอรี `/var/www/html`)

ใช้คำสั่งเหล่านี้ด้วยความระมัดระวัง เนื่องจากคำสั่งเหล่านี้มีผลโดยตรงต่อความปลอดภัยของระบบของคุณ

ฉบับที่ #2

ปัญหา:

หากเมื่อนำเข้าฐานข้อมูล ข้อผิดพลาดต่อไปนี้เกิดขึ้น 'ข้อผิดพลาด 1049 (42000): ฐานข้อมูลที่ไม่รู้จัก 'db1'' (โดยที่ `db1' คือชื่อของฐานข้อมูล) แสดงว่าฐานข้อมูลของคุณยังไม่ถูกสร้างขึ้น

วิธีการแก้:

ลองเข้าถึง 'mysql' และสร้างฐานข้อมูลนี้ใหม่อีกครั้ง

ปัญหา #3

ปัญหา:

หากเมื่อเปลี่ยนเจ้าของไฟล์และไดเรกทอรี คุณเห็นคำสั่ง `chown: ผู้ใช้ไม่ถูกต้อง: … ` แสดงว่าคุณระบุผู้ใช้เว็บเซิร์ฟเวอร์บนเซิร์ฟเวอร์ของคุณอย่างไม่ถูกต้อง

วิธีการแก้:

ศึกษาคำแนะนำที่เกี่ยวข้องเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์ในระบบของคุณ หรือใช้ยูทิลิตี `ps aux` เพื่อกำหนดผู้ใช้ที่เหมาะสม

ฉบับ #4

ปัญหา:

หากมีข้อผิดพลาด PHP เมื่อเริ่ม Magento บนเซิร์ฟเวอร์ใหม่ (ตามกฎหมายความว่าไม่มีส่วนขยาย PHP บางตัว)...

วิธีการแก้:

ซึ่งสามารถแก้ไขได้โดยการติดตั้งส่วนขยายที่ขาดหายไป

a) `นามสกุล json ของ PHP จำเป็นต้องใช้ NormalizerFormatter ของ Monolog` ―

ส่วนขยาย *php-json* หายไป

b) `ข้อผิดพลาดร้ายแรงของ PHP: Uncaught Error: ไม่พบคลาส 'DOMDocument' ใน …` ―

ไม่มีนามสกุล *php-xml*

c) `ข้อผิดพลาดร้ายแรงของ PHP: ไม่พบคลาส 'IntlDateFormatter' ใน …` ―

*php-intl* ส่วนขยายหายไป

ปัญหา #5

ปัญหา:

หากส่วนขยาย PHP หายไปเมื่อรันคำสั่ง `composer update` คุณจะเห็นข้อผิดพลาดต่อไปนี้:

ตัวอย่างเช่น,

`phpunit/phpunit 6.5.14 ต้องการ ext-mbstring * -> mbstring ส่วนขยาย PHP ที่ร้องขอหายไปจากระบบของคุณ'

วิธีการแก้:

ในการจัดการกับข้อผิดพลาดดังกล่าว คุณต้องติดตั้งส่วนขยาย PHP ที่ผู้แต่งอ้างถึง ตัวอย่างเช่น `yum ติดตั้ง php-mbstring'

รายการส่วนขยายที่จำเป็นสำหรับเวอร์ชัน Magento 2 ของคุณมีอยู่ในเอกสารอย่างเป็นทางการ

บรรทัดล่าง

คุณพร้อมแล้ว! ในบทความนี้ ฉันพยายามอย่างเต็มที่ที่จะนำเสนอขั้นตอนง่ายๆ ในการถ่ายโอนไซต์ Magento 2 ของคุณจาก localhost ไปยังเซิร์ฟเวอร์

หากคุณยังคงมีคำถามหรือต้องการแบ่งปันความคิดเห็น โปรดใช้ส่วนความคิดเห็นด้านล่าง ฉันจะพยายามอย่างเต็มที่เพื่อตอบคำถามและข้อกังวลทั้งหมด!