ฉันจะแก้ไขข้อบกพร่องของร้านค้าวีโอไอพีของฉันได้อย่างไร

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

ช่วยให้เว็บไซต์ของฉันไม่ทำงาน!

1. การออกแบบของฉันเป็นความผิดหรือเปล่า?
2. โมดูลของบุคคลที่สามเป็นความผิดพลาดหรือไม่?
3. เหตุใดฉันจึงไม่เห็นข้อผิดพลาด

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

การแก้จุดบกพร่องเป็นบิตของศิลปะ แต่สิ่งที่สามารถเข้าใจได้ง่ายโดยทำตามระบบการปกครองแบบง่าย ๆ

ทำตามแต่ละจุดจนกว่าคุณจะถึงทางออก

เปิดใช้งานข้อผิดพลาด PHP

นี่คือกุญแจสู่ปัญหาส่วนใหญ่ เพื่อความปลอดภัยหรือด้วยเหตุผลอื่นการแสดงข้อผิดพลาด PHP อาจถูกปิดใช้งานโดยค่าเริ่มต้นจากการกำหนดค่า PHP ของคุณ

คุณสามารถเปิดใช้งานข้อผิดพลาดด้วยวิธีแก้ไขปัญหาที่ถาวรมากขึ้นหรือเป็นเพียงสิ่งชั่วคราวเท่านั้น

ทางออกถาวร

สำหรับผู้ใช้ Apache / mod_php

ใน.htaccessไฟล์ของรูทเอกสารของคุณ- เพียงแค่วางสิ่งนี้ไว้ที่ด้านบน

php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag  log_errors on
php_value error_log  /home/path/public_html/var/log/system.log

สำหรับผู้ใช้ Nginx / FastCGI

ในการกำหนดค่า Nginx virtualhost ของคุณทั้งในlocation .php {คำสั่งสุดท้ายหรือในfastcgi_paramsไฟล์ (ถ้าคุณมีหนึ่งที่ระบุไว้)

fastcgi_param PHP_VALUE  display_startup_errors=on;
fastcgi_param PHP_VALUE  display_errors=on;
fastcgi_param PHP_VALUE  html_errors=on;
fastcgi_param PHP_VALUE  log_errors=on;
fastcgi_param PHP_VALUE  error_log=/home/path/public_html/var/log/system.log;

โซลูชั่นชั่วคราว / สากล

สำหรับแพลตฟอร์มใด ๆ

แก้ไขแถบบู๊ต Magento index.phpในรูทเอกสารของคุณและยกเลิกหมายเหตุบรรทัดต่อไปนี้:

#ini_set('display_errors', 1);

เปิดใช้งานโหมดนักพัฒนาซอฟต์แวร์

เมื่อคุณมีข้อผิดพลาดและทันใดนั้นก็พบหน้า "รายงานข้อผิดพลาด" และได้รับสตริงข้อผิดพลาดที่ดูเหมือนไร้ประโยชน์เช่น1184257287824- คุณมีตัวเลือกน้อย

ทางออกถาวร

สำหรับผู้ใช้ Apache / mod_php

ใน.htaccessไฟล์รูทเอกสารของคุณ- เพียงแค่วางที่ด้านบน

SetEnv MAGE_IS_DEVELOPER_MODE true

สำหรับผู้ใช้ Nginx / fastcgi

ในการกำหนดค่า Nginx virtualhost ของคุณทั้งในlocation .php {คำสั่งสุดท้ายหรือในfastcgi_paramsไฟล์ (ถ้าคุณมีหนึ่งที่ระบุไว้)

fastcgi_param MAGE_IS_DEVELOPER_MODE true;

โซลูชั่นชั่วคราว / สากล

แก้ไข bootstrap ของ Magento index.phpในรูทเอกสารของคุณและทำให้ifคำสั่งเป็นจริงเสมอหรือเปิดใช้งานสำหรับ IP เฉพาะของคุณ

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
  Mage::setIsDeveloperMode(true);
}

หรือ

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
  Mage::setIsDeveloperMode(true);
}

ตรวจสอบการอนุญาตของคุณ

การอนุญาตที่ไม่ถูกต้องจะทำให้เกิดปัญหามากมายซึ่งส่วนใหญ่ไม่สามารถหาได้ง่ายในตอนแรก

ตัวอย่างเช่น.
ถ้า PHP ไม่สามารถเขียนไปยัง./mediaไดเรกทอรีและคุณเปิดใช้งานการรวม JS - วีโอไอพีไม่สามารถสร้างไฟล์รวมและ URI ที่ไม่ซ้ำกันที่เกี่ยวข้องสำหรับสื่อ ดังนั้นสิ่งที่คุณจะพบในซอร์สโค้ดของเบราว์เซอร์คือเส้นทางเซิร์ฟเวอร์แบบเต็มไปยังไฟล์มีเดีย /home/path/public_html/media/xxx

มิฉะนั้นไซต์อาจทำงานเป็นปกติโดยไม่มีข้อผิดพลาดร้ายแรงที่มองเห็นได้

โปรดจำไว้ว่าการปฏิบัตินี้มีความปลอดภัยสำหรับการโฮสต์โดยเฉพาะ แต่อาจมีปัญหาด้านความปลอดภัยกับการโฮสต์ที่ใช้ร่วมกันหากกระบวนการ Apache ไม่ได้ chroot'ed ต่อผู้ใช้

ในตัวอย่างของเราผู้ใช้ SSH / FTP คือsonassiผู้ใช้ Apache apacheและกลุ่มคือapache

เพิ่มผู้ใช้ FTP / SSH ไปยังกลุ่ม Apache

สิ่งสำคัญที่สุดคือเราต้องให้แน่ใจว่าผู้ใช้ FTP / SSH เป็นส่วนหนึ่งของกลุ่ม Apache ในตัวอย่างของเรามันapache(แต่ก็เป็นเรื่องปกติด้วยwww-data)

usermod -a -G apache sonassi

เพิ่มผู้ใช้เป็นกลุ่มให้มากที่สุดเท่าที่คุณมีสำหรับ FTP / SSH

รีเซ็ตการอนุญาตดั้งเดิม

ดังนั้นก่อนที่เราจะเริ่มให้แน่ใจว่าสิทธิ์ทั้งหมดถูกต้อง

chown -R sonassi:apache /home/path/public_html/
find /home/path/public_html/ -type d -exec chmod 775 {} \;
find /home/path/public_html/ -type f -exec chmod 664 {} \;

ทำการเปลี่ยนแปลงอย่างถาวร

ACLs และ Sticky Bits

ACLs ใน Linux อนุญาตให้เรากำหนดกฎเฉพาะในกรณีของเราไฟล์สิทธิ์ที่ควรสืบทอดเมื่อสร้าง เหนียวเล็กน้อย (ดังกล่าวในภายหลัง) ดูแลกลุ่มมรดก แต่ไม่ได้ช่วยให้มีสิทธิ์ซึ่งเป็นเหตุผลที่เราใช้ ACL ของ

เริ่มต้นด้วยการเปิดใช้งานการสนับสนุน ACL ในพาร์ทิชันที่ใช้งานอยู่โปรดตรวจสอบเคอร์เนลของคุณถูกรวบรวมด้วยการสนับสนุนของ ACL

พาร์ทิชันของคุณอาจจะ/, /home, /varหรือสิ่งอื่นแทนตามความเหมาะสม

mount -o remount,acl /home

ตอนนี้เปิดใช้งาน ACL แล้วเราสามารถตั้งค่ากฎ ACL และบิตกลุ่มเหนียว:

setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/

แต่ฉันไม่ได้รับการสนับสนุนจาก ACL

หากเคอร์เนลของคุณไม่รองรับ ACL คุณสามารถใช้umask(ซึ่งเป็นการตั้งค่าเวลาทำงานสำหรับ BASH, FTP และ PHP) เพื่อตั้งค่าการอนุญาตไฟล์เริ่มต้น วีโอไอพีมักจะกำหนดumask(0)ในindex.phpแต่มันจะอยู่ในความสนใจของคุณที่จะเปลี่ยนแปลงนี้

ในindex.phpการเปลี่ยนแปลงของคุณumaskสายที่จะ

umask(022);

และในสภาพแวดล้อม BASH ของคุณสำหรับ SSH ให้ตั้งค่านี้ในของคุณ.bashrcหรือ.bash_profile

umask 022

สำหรับเซิร์ฟเวอร์ FTP ของคุณคุณจะต้องอ่านเอกสารประกอบ แต่หลักการก็เหมือนกัน

เปลี่ยนธีมกลับเป็นค่าเริ่มต้น

เป็นไปได้ว่าชุดรูปแบบหรือแพคเกจของคุณเป็นผู้รับผิดชอบปัญหานี้ การย้อนกลับไปใช้ธีมวานิลลาวีโอไอพีเป็นวิธีที่รวดเร็วในการค้นหา

** สิ่งนี้มาพร้อมกับข้อแม้ที่บางโมดูลอาจขึ้นอยู่กับคุณสมบัติของธีม *

แทนที่จะเปลี่ยนอะไรผ่านแผงการดูแลระบบมันง่ายกว่ามากที่จะเปลี่ยนชื่อไดเรกทอรีที่ละเมิด

ผ่าน SSH

mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}

หรือผ่านไคลเอนต์ FTP ของคุณสำรวจและเปลี่ยนชื่อแพคเกจของคุณเป็นอย่างอื่น เช่น.myBrokenTheme.tmp

หากสามารถแก้ไขปัญหาของคุณได้

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

เป็นหลักกระบวนการคือการเปิดใช้งานไดเรกทอรีในขณะที่คุณทยอยลงต้นไม้ไฟล์ - จนกว่าคุณจะสามารถหาไฟล์ที่ละเมิด

1. เปลี่ยนชื่อไดเรกทอรีเค้าโครงเป็น .tmp
2. เปลี่ยนชื่อไดเรกทอรีแม่แบบเป็น .tmp

จากนั้นหากมีการแก้ไขให้เปลี่ยนชื่อไฟล์ทั้งหมดภายในไดเรกทอรีโครงร่างเป็น.tmp- (สำหรับผู้ใช้ SSH ls | xargs -I {} mv {} {}.tmpหรือrename 's/^/.tmp/' *)

จากนั้นค่อยเปิดใช้งานแต่ละไฟล์ 1 ต่อ 1 จนกระทั่งได้รับการแก้ไข

หากไม่สามารถแก้ปัญหาของคุณได้

มีความเป็นไปได้ที่ไดเรกทอรีของคุณbase/defaultหรือenterprise/defaultอาจมีการปนเปื้อน - และจะถูกแทนที่ด้วยเวอร์ชั่นใหม่ที่รู้จักกันดีที่สุด

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

cd /home/path/public_html/
mkdir clean_mage
cd clean_mage
MAGENTO_VERSION=1.7.0.0
wget -O magento.tgz  http://www.magentocommerce.com/downloads/assets/$MAGENTO_VERSION/magento-$MAGENTO_VERSION.tar.gz
tar xvfz magento.tgz
cd /home/path/public_html/app/design/frontend
mv base{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/design/frontend/base .
cd /home/path/public_html/skin/frontend
mv base{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/skin/frontend/base .

คุณยังสามารถใช้โอกาสนี้diffในสองไดเรกทอรีหากคุณต้องการตรวจสอบการเปลี่ยนแปลงใด ๆ

diff -r base base.tmp

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

ปิดใช้งานโมดูลโลคัล

โดยปกติวีโอไอพีจะกำหนดเส้นทางการรวม PHP เพื่อโหลดคลาสตามลำดับต่อไปนี้

Local > Community > Core

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

อีกครั้งแทนที่จะปิดใช้งานโมดูลผ่านแผงผู้ดูแลระบบ Magento มันเป็นจริงมากขึ้นในการทำเช่นนี้ในระดับไฟล์

โดยทั่วไปเมื่อต้องการปิดการใช้งานโมดูลในแบบ "เหมาะสม" คุณจะต้องแก้ไข./app/etc/modules/MyModule.xmlไฟล์และการตั้งค่าตามลำดับ<active>false</active>อย่างไรก็ตามนี่ไม่ได้เป็นการป้องกันคลาสไม่ให้ทำการโหลด

หากคลาสอื่นขยายคลาสที่กำหนดในโมดูล (ละเว้นการประกาศการพึ่งพา Magento ใด ๆ ) คลาสนั้นจะยังคงถูกโหลด - ไม่ว่าจะปิดใช้งานส่วนขยายหรือไม่ก็ตาม

ดังนั้นวิธีที่ดีที่สุดในการปิดการใช้งานส่วนขยายคือการเปลี่ยนชื่อไดเรกทอรี

เริ่มต้นด้วยการปิดการใช้งานในท้องถิ่น

เพียงเปลี่ยนชื่อไดเรกทอรีผ่าน FTP หรือใช้คำสั่ง SSH ต่อไปนี้

mv ./app/code/local{,.tmp}

จากนั้นปิดใช้งานชุมชน

mv ./app/code/community{,.tmp}

หากปัญหาได้รับการแก้ไขจากทั้ง

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

ดังนั้นเรียกคืนไดเร็กทอรี X และลองทำสิ่งต่อไปนี้ทดสอบระหว่างแต่ละไฟล์

เป็นหลักกระบวนการคือการเปิดใช้งานไดเรกทอรี (โมดูล) ค่อยๆทีละคนจนกว่าข้อผิดพลาดเกิดขึ้นอีกครั้ง

1. เปลี่ยนชื่อโมดูลทั้งหมดในไดเรกทอรีเป็น.tmp(สำหรับผู้ใช้ SSH ls | xargs -I {} mv {} {}.tmpหรือrename 's/^/.tmp/' *)
2. เปิดใช้งานแต่ละโมดูลทีละหนึ่งโดยค่อยๆลบออก.tmpจากชื่อไฟล์

หากปัญหายังไม่ได้รับการแก้ไข

จากนั้นก็เป็นไปได้ที่แกนตัวเองจะปนเปื้อน แกนหลักของวีโอไอพี PHP ประกอบด้วย

./app/code/core
./lib

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

cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .

ถ้าปัญหายังไม่ได้รับการแก้ไขให้เปลี่ยนlibไดเรกทอรีด้วย

cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .

ณ จุดนี้ร้านค้า Magento ของคุณจะไม่มีอะไรมากไปกว่าการติดตั้งวานิลลาพร้อมฐานข้อมูลที่ถูกดัดแปลง

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

คำแนะนำข้างต้นทำหน้าที่ให้คุณทราบวิธีการระบุข้อผิดพลาด ไม่แก้ไขข้อผิดพลาดผลลัพธ์

^{เนื้อหาที่มาจากwww.sonassi.com/knowledge-base/magento-debug-processและwww.sonassi.com/knowledge-base/stop-magento-permissions-errman-permanently}

ตามที่ขอใน Twitterและพูดคุยกับ Metaฉันจะเริ่มต้นที่นี่บทช่วยสอนการดีบักสำหรับผู้ไม่ใช้งานจริง

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

คำตอบที่ดีมากเกี่ยวกับวิธีการแก้ปัญหาวีโอไอพีเมื่อคุณต้องการได้รับสกปรกได้รับจาก Sonassiแล้ว แต่ฉันพยายามที่จะเพิ่มสิ่งต่าง ๆ และคัดลอกสิ่งที่ฉันคิดว่าเหมาะสำหรับพ่อค้า

คำเตือน: ไดเรกทอรีและไฟล์ทั้งหมดที่กล่าวถึงในโพสต์นี้เกี่ยวข้องกับโฟลเดอร์ root คุณภาพเยี่ยมซึ่งอาจมี/var/wwwแต่ขึ้นอยู่กับผู้ให้บริการโฮสติ้งคุณสามารถเรียกเอกสารรากของคุณได้ทุกที่ถามผู้ให้บริการของคุณหากคุณไม่พบวีโอไอพีของคุณ !

โหมดการพัฒนา

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

^{ขอบคุณfontis.comสำหรับภาพนี้}

รายงานที่กล่าวถึงในหน้าสามารถพบได้ใน var/reports/<the_number>

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

เปิดindex.phpไฟล์ของคุณในโฟลเดอร์รูทของ magento ขึ้นอยู่กับเวอร์ชั่นคุณจะพบบรรทัดเหล่านี้รอบ ๆ บรรทัดที่ 73:

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE'])) {
    Mage::setIsDeveloperMode(true);
}

#ini_set('display_errors', 1);

หากต้องการเปิดใช้งานโหมดในขณะนี้คุณต้องเปลี่ยนบรรทัดเหล่านี้

หากคุณทราบที่อยู่ IP ของคุณ (คนส่วนใหญ่จะได้รับที่อยู่ใหม่ทุก ๆ 24 ชั่วโมงอย่างน้อยในเยอรมนี) google จะช่วยคุณที่นี่:

ที่อยู่ IP สาธารณะของคุณคือ 87.138.100.68

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) 
    || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress'
) {
    Mage::setIsDeveloperMode(true);
    ini_set('display_errors', 1);
}

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

#if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
  Mage::setIsDeveloperMode(true);
#}
ini_set('display_errors', 1);

เข้าสู่ระบบ

Magento บันทึกสิ่งต่าง ๆ มากมายเป็นสองไฟล์:

• var/log/exception.log
• var/log/system.log

ข้อยกเว้นถูกบันทึกไว้เสมอ ต้องเปิดใช้งานบันทึกระบบในแบ็กเอนด์:

System > Configuration > Developer > Log

ตั้งค่าEnabledเป็นใช่และคุณจะเห็นข้อผิดพลาดเพิ่มเติมและดีบักข้อความทั้งในsystem.logและในexception.log

มันเป็นปัญหาของชุดรูปแบบหรือไม่?

คุณมีธีมของคุณเองซึ่งถูกกำหนดค่าในแบ็กเอนด์ที่นี่:

ระบบ> การกำหนดค่า> การออกแบบ

^{ขอบคุณkb.magenting.comสำหรับรูปภาพ}

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

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

เกิดอะไรขึ้น

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

ในคำถาม:

• อธิบายสิ่งที่คุณกำลังทำ
• เกิดข้อผิดพลาดอะไรขึ้น
• อะไรในไฟล์บันทึก
• อาจเป็นภาพหน้าจอของข้อผิดพลาด

1. ก่อนอื่นคุณควรเปิดใช้งานโหมดนักพัฒนาซอฟต์แวร์
2. คุณอาจเปิดใช้งานเพื่อแสดงข้อผิดพลาดใน index.php: ini_set ('display_errors', 1);
3. รวบรวมส่วนขยาย xDebug ด้วย smart IDE ใด ๆ (PhpStrom / eclipse)
4. ปิดการใช้งานโมดูลที่กำหนดเองและบุคคลที่ 3
5. ตรวจสอบข้อยกเว้นและบันทึกข้อผิดพลาดของคุณแก้ไขข้อผิดพลาดในรายการในบันทึกข้อยกเว้น
6. ตรวจสอบว่าต้องโหลดส่วนขยาย curl และ mcrypt บนเซิร์ฟเวอร์ของคุณ
7. ตรวจสอบการอนุญาตโฟลเดอร์และไฟล์ chown -R sonassi: apache / home / path / public_html / find / home / path / public_html / -type d -exec chmod 775 {} \; ค้นหา / home / path / public_html / -type f -exec chmod 664 {} \;
8. อัปเดตสิทธิ์ในการใช้งานมีเดียและ var 0777 หากไม่ได้ตั้งค่าไว้
9. เริ่ม IDE (phpstrom) จากนั้นตั้งจุดเริ่มต้นของดีบักเกอร์บน index.php 10. กด F8 และไปต่อไปจนกว่าคุณจะพบข้อผิดพลาด

สำหรับการใช้ขั้นตอนข้างต้นคุณควรได้รับข้อผิดพลาดอย่างแน่นอน

แก้ไขข้อบกพร่อง Backtrace

นี่เป็นฟังก์ชั่นที่ดีในการดีบั๊กการเรียกใช้ฟังก์ชันเป็นวีโอไอพี

เพิ่มฟังก์ชั่นนี้ใน include / config.php หรือสร้างไฟล์ใหม่และใส่ฟังก์ชั่น php ที่ใช้กันทั่วไปทั้งหมดของคุณ

ฟังก์ชัน back_trace ($ exit = true) {
  $ call_back_methods = '';
  $ call_back_methods. = '';
  $ call_back_methods. = 'SNFunction NameLine NumberFile Name';

  $ counter = 1;
  foreach (debug_backtrace () เป็น $ index => $ data) {
    // ถ้า (0 == $ index) ดำเนินการต่อ;

    $ call_back_methods. = '' $ counter ++ '';
    $ call_back_methods. = '' $ data ['function'] '';
    $ call_back_methods. = '' $ data ['line'] '';
    $ call_back_methods. = '' $ data ['file'] '';
  }

  $ call_back_methods. = '';

  พิมพ์ $ call_back_methods;

  if (จริง == $ exit) ทางออก;
}

เอาท์พุทจะเป็น