كيفية نقل موقع Magento 2 من المضيف المحلي إلى الخادم؟

لا تستغرق عملية نقل موقع يستند إلى Magento 2 من مضيف محلي إلى آخر عملية تستغرق وقتًا طويلاً. ومع ذلك ، فإنه يحتوي على عدد من التفاصيل الدقيقة والجوانب الخاصة التي يجب أخذها في الاعتبار قبل الانغماس في العملية.

في منشور المدونة هذا ، سنجعل نقل موقع Magento 2 من المضيف المحلي إلى الخادم أمرًا سهلاً مثل Lego. دعونا نلقي نظرة ثاقبة.

الخطوات الرئيسية

في البداية ، دعنا نلقي نظرة على الخطوات الرئيسية للتحويل:

1. فحص سلامة موقع Magento 2 على المضيف الحالي (A) ؛
2. تجهيز المضيف البعيد (B) ؛
3. فحص المضيف البعيد (ب) ؛
4. تجهيز البيانات للنقل ؛ 4.1 تفريغ الملف 4.2 تفريغ قاعدة البيانات
5. نقل البيانات؛
6. تفريغ البيانات 6.1 تفريغ الملفات 6.2 استيراد قواعد البيانات ؛
7. الوصول إلى تصحيح البيانات على المضيف البعيد (B) ؛
8. تصحيح أذونات الوصول إلى الملفات والأدلة ؛
9. الإجراءات القياسية قبل إطلاق Magento ؛
10. يتحقق أداء Magento على المضيف البعيد (B) ؛
11. حل المشاكل المتكررة.

سهل مثل Lego: إرشادات خطوة بخطوة

1. فحص سلامة موقع Magento 2 على المضيف الحالي

كل شيء سهل هنا: اركض وتحقق. عادة ، يجب إنشاء أمر (دورة كاملة) لهذه الأغراض. ثم تحقق:

• بحث؛
• صفحات المنتج ،
• التصنيفات،
• حساب العميل.

هذه مرحلة مهمة لأنها تتيح لك الابتعاد عن المصارعة مع الأسئلة المتعلقة بالوقت الذي يتوقف فيه شيء ما عن العمل بالضبط بعد الانتقال إلى مضيف جديد. أيضًا ، سيوفر لك هذا ضرورة التعامل مع مشكلات المضيف الأساسية التي يمكن حلها مسبقًا (أ).

أنا أشجعك على عدم نقل ماجينتو بنصفين دون أي حاجة ملحة. من الأسهل بكثير التعامل مع جميع المشكلات المتعلقة بالمضيف الحالي (أ) قبل بدء عملية النقل. مثبت ومختبر - سيوفر لك ذلك الوقت والألم في الرقبة.

2. تجهيز المضيف البعيد (B)

يجب أن يفي الخادم ، الذي تم نشر نسخة Magento عليه ، بالحد الأدنى من متطلبات إصدار Magento الخاص بك.

ادرس الوثائق الرسمية لمعرفة المزيد عن تلك المتطلبات: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

يجب إعداد البيئة قبل المتابعة إلى الخطوات التالية لعملية النقل (خادم ويب مع مضيف افتراضي ، PHP ، قاعدة بيانات).

لسوء الحظ ، فإن تكوين كل جزء منفصل يتجاوز حدود هذه المقالة. ومع ذلك ، يمكنك بسهولة العثور على المعلومات الإضافية المطلوبة على الويب. لذلك ، لا ينبغي أن يكون هناك صعوبة.

أوصي بإيلاء اهتمام خاص لوجود ملحقات PHP المطلوبة.

إذا كان لديك أي أسئلة حول أي خطوة في هذا البرنامج التعليمي ، فالرجاء ترك تعليق. سأبذل قصارى جهدي للإجابة عليهم جميعًا.

3. فحص المضيف البعيد (ب)

قبل نقل 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 التي تنوي نقلها. لاحظ أنه يجب عليك بالضرورة إدخال الاسم الذي تم تغييره في ملف التكوين الخاص ببيئة 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 هو المسار إلى المفتاح الخاص للاتصال (تجاهل هذا إذا كنت تستخدم كلمة المرور فقط) ؛

ب) ec2-user هو اسم المستخدم للاتصال ؛

ج) 52.12.187.98 هو عنوان الخادم ؛

د) / 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". للبدء ، لنقم بترجمة هذه الحقول باستخدام استعلام "القيمة" الذي يتضمن العنوان القديم. لنفترض أن عنوان موقع الويب القديم كان "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" في حقل "القيمة" بسطر "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'` عن طريق تحديد البيانات الدقيقة من الخادم الجديد في حقلي" اسم المستخدم "و" كلمة المرور ".

* هام! إذا كانت قاعدة البيانات الخاصة بك موجودة على خادم بعيد ، فلا داعي لتغيير البيانات. الشيء الوحيد الذي عليك القيام به هو التأكد من وجود وصول من الخادم الحالي إلى قاعدة البيانات البعيدة. (على سبيل المثال ، أنه تمت إضافته إلى القائمة البيضاء لجدار الحماية على خادم قاعدة البيانات).

استخدم قيمة "المضيف المحلي" في حقل "المضيف" لفهم ما إذا كان الاتصال محليًا أم لا.

بعد ذلك ، احفظ الملف.

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 بدقة. وفقًا للوثائق ، يوصى بشدة بالإعداد التالي:

* يجب تشغيل جميع الأوامر من جذر Magento !، باستمرار 1 بعد 1. في المثال ، جذر Magento على الخادم هو `/ 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

* إذا كان المستخدم الحالي يفتقر إلى الأذونات لتشغيل هذه الأوامر ، فاستخدم `الجذر` (أمر` sudo` ، مثل `sudo find ...`)

9. الإجراءات القياسية قبل إطلاق Magento

حان الوقت للتحقق من بدء تشغيل Magento من سطر الأوامر. للبدء ، دعنا نختبر الإخراج القياسي للأوامر التي يمكنك الوصول إليها:

* الآن ، بعد إعداد الأذونات ، سيتم إجراء أي وصول إلى Magento من مستخدم خادم الويب نفسه الذي ينشئ الملفات وملفات ذاكرة التخزين المؤقت والإحصاءات وما إلى ذلك. إذا تجاهلت هذا ، فقد يتوقف Magento عن العمل وستضطر إلى استعادة الأذونات مرة أخرى (الخطوة السابقة في هذه الإرشادات).

** للتشغيل الدقيق ، ستحتاج إلى العثور على مترجم php المناسب على خادمك. عادة ، يشير الاسم المستعار `php` إلى الإصدار الحديث. ومع ذلك ، ستحتاج غالبًا إلى الإشارة إلى المسار الكامل ، مثل `/ usr / bin / php72` على سبيل المثال.

*** هنا وأكثر ، سيتم تشغيل جميع أوامر Magento من دليل جذر Magento على الخادم (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: publish ru_RU` للغة الروسية.

تهانينا! لقد نجحت في نقل متجر Magento2 الخاص بك من المضيف المحلي للعمل بشكل صحيح على خادم جديد. الآن ، افتحه في المتصفح عن طريق إدخال عنوان جديد!

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

مشكلة:

إذا حدث الخطأ التالي عند استيراد قواعد البيانات ، "ERROR 1049 (42000): قاعدة بيانات غير معروفة 'db1 "` (حيث أن` db1` هو اسم قاعدة البيانات) ، فهذا يعني أنه لم يتم إنشاء قاعدة البيانات الخاصة بك.

المحلول:

حاول الوصول إلى "mysql" وأعد إنشاء قاعدة البيانات هذه مرة أخرى.

العدد 3

مشكلة:

إذا كنت ترى الأمر "chown: مستخدم غير صالح: ..." عند تغيير مالك الملفات والأدلة ، فمن المحتمل أنك حددت مستخدم خادم الويب على الخادم الخاص بك بشكل غير صحيح.

المحلول:

راجع الأدلة المقابلة حول تكوين الخادم في نظامك أو استخدم الأداة المساعدة `ps aux` لتحديد المستخدم المناسب.

العدد رقم 4

مشكلة:

إذا كانت هناك أخطاء PHP عند بدء تشغيل Magento على خادم جديد (كقاعدة عامة ، فهذا يعني عدم وجود بعض امتدادات PHP) ...

المحلول:

يمكن حل ذلك عن طريق تثبيت الامتدادات المفقودة.

أ) `ملحق json الخاص بـ PHP مطلوب لاستخدام Monolog's NormalizerFormatter` -

* ملحق php-json * مفقود ؛

ب) خطأ فادح في PHP: خطأ لم يتم اكتشافه: فئة 'DOMDocument' غير موجودة في ... `-

* ملحق php-xml * مفقود ؛

ج) خطأ فادح في PHP: الفئة 'IntlDateFormatter' غير موجودة في ... "-

* php-intl * extebnsion مفقود.

العدد 5

مشكلة:

إذا كانت امتدادات PHP مفقودة عند تشغيل أمر "composer update" ، فستشاهد الأخطاء التالية:

فمثلا،

يتطلب `phpunit / phpunit 6.5.14 ext-mbstring * -> ملحق PHP المطلوب mbstring مفقود من نظامك.

المحلول:

للتعامل مع مثل هذه الأخطاء ، تحتاج ببساطة إلى تثبيت ملحقات PHP التي يشير إليها الملحن. على سبيل المثال ، "yum install php-mbstring".

يمكن العثور على قائمة كاملة بالامتدادات المطلوبة لإصدار Magento 2 الخاص بك في الوثائق الرسمية.

الحد الأدنى

أنت كل مجموعة! في هذه المقالة ، بذلت قصارى جهدي لتقديم خطوات سهلة لمتابعة نقل موقع Magento 2 الخاص بك من المضيف المحلي إلى الخادم.

إذا كان لا يزال لديك أسئلة أو ترغب في مشاركة رأيك ، فلا تتردد في استخدام قسم التعليقات أدناه. سأبذل قصارى جهدي للإجابة على جميع الأسئلة والمخاوف!