调试是一门艺术，但是可以通过遵循简单的方案轻松掌握。
遵循每个要点，直到最终找到解决方案。
启用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虚拟主机配置中，在最终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;
临时/通用解决方案
对于任何平台
index.php在文档根目录中编辑Magento引导程序，并取消注释以下行：
#ini_set('display_errors', 1);
启用开发人员模式
当您遇到错误并突然进入“错误报告”页面，并得到一个看似无用的错误字符串，例如1184257287824-您有几个选择。
永久解决方案
对于Apache / mod_php用户
在您的文档根.htaccess文件中-只需将其放在顶部即可。
SetEnv MAGE_IS_DEVELOPER_MODE true
对于Nginx / fastcgi用户
在您的Nginx虚拟主机配置中，在最终location .php {指令或fastcgi_params文件中（如果已指定）
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
临时/通用解决方案
index.php在文档根目录中编辑Magento引导程序，或者使该if语句始终为true，或者为您的特定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组合-Magento无法为媒体生成组合文件和关联的唯一URI。因此，相反，您在浏览器源代码中将找到媒体文件的完整服务器路径。
/home/path/public_html/media/xxx
否则，该站点可能看起来正常运行-实际上没有可见的严重错误。
请记住，这种做法对于专用托管是安全的，但是如果未按用户对Apache进程进行chroot，则共享托管可能会出现安全问题。
在我们的示例中，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 {} \;
使更改永久生效
ACL和粘性位
Linux中的ACL允许我们定义特定的规则，在这种情况下，创建时应继承哪些权限文件。一个粘着位（后面提到）负责集团的继承权，但不具有的权限，这就是为什么我们使用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的运行时设置）来设置默认文件权限。Magento通常设置umask(0)为index.php，但是更改此设置符合您的利益。
在您的index.php更改umask行是
umask(022);
并在SSH的BASH环境，在此设置或者您的.bashrc或.bash_profile
umask 022
对于FTP服务器，您需要阅读它的文档，但是原理是相同的。
恢复主题为默认
您的主题或程序包可能是导致此问题的原因。恢复到原始的Magento主题是一种快速的发现方法。
**这带有警告，某些模块可能取决于某些主题功能*
与其通过管理面板进行任何更改，不如仅重命名有问题的目录要简单得多。
通过SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
或者通过您的FTP客户端，遍历并将包重命名为其他名称。例如。myBrokenTheme.tmp
如果这样可以解决您的问题
然后，您需要更深入地了解模板的哪一部分有问题。因此，请还原您的软件包并尝试以下操作，并在每个软件包之间进行测试。
本质上，该过程是在遍历文件树时逐渐启用目录-直到找到有问题的文件。
- 将布局目录重命名为
.tmp
- 将模板目录重命名为
.tmp
然后，如果其中一个可以解决，请将布局目录中的所有文件重命名为.tmp-（对于SSH用户ls | xargs -I {} mv {} {}.tmp或rename 's/^/.tmp/' *）
然后逐步逐个启用每个文件，直到解决为止。
如果这样不能解决您的问题
有潜力，你base/default或enterprise/default目录已经被污染-与已知的干净版本，最好更换。
您可以通过下载干净的Magento构建并根据需要替换目录来执行此操作。通过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
注意 此方法将在处理过程中引起更多错误，因为模块依赖性决定了特定文件的存在。不幸的是，这与课程相当。
禁用本地模块
默认情况下，Magento定义了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目录并尝试以下操作，并在每个目录之间进行测试。
本质上，该过程是逐步逐步启用目录（模块），直到错误再次发生
- 将目录中的所有模块重命名为
.tmp（对于SSH用户ls | xargs -I {} mv {} {}.tmp或rename 's/^/.tmp/' *）
- 通过
.tmp从文件名中删除，逐步启用每个模块
如果问题没有解决
然后，芯子本身可能会被污染。Magento PHP的主要核心包括
./app/code/core
./lib
同样，重命名这些目录并复制一个干净的变体。假设您已经通过SSH下载了上述的Magento干净版本，您可以执行以下操作：
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商店只不过是带有已修改数据库的原始安装。
某些模型实际上仍存储在数据库中（例如，订单增量）-因此，此时，这是手动进行这些编辑的情况。到目前为止，以上所有步骤都是可逆的，没有持久的损害。但是，如果我们也要导入一个干净的Magento数据库-它可能被证明是不可逆的（缺少还原备份）。
上面的指南可帮助您识别错误；不能解决由此产生的错误。
内容自愿来自www.sonassi.com/knowledge-base/magento-debug-process和www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently
