即使在禁用的情况下，我也不能对所有加载的插件说话，但gravity表单并不是为大量使用而设计的，很可能是造成这个问题的重要原因。
我曾经与一个使用gravity表单的大型客户合作，他们的管理面板（和提交表单）变得非常慢，最终他们开始完全超时。
我不再掌握详细信息，但gravity表单当时的问题是，提交表单时，gravity表单会执行以下操作：
加载曾经提交过的每个表单，循环遍历其中的每个表单，直到它到达末尾。使用上次提交的条目并添加一个条目来生成下一个唯一id。当时，我为客户端创建了一个补丁，对其进行测试，应用它，并将其提交到gravity表单。。。也没有回音。在接下来的几次客户升级gravity表单时，它也遇到了同样的问题，我不得不重新应用补丁。我终于让他们换了服务。
如果你正在使用大量插件向wordpress管理面板添加额外的列（例如，列表帖子、列表页面等），我想这至少是问题的一部分，因为大多数插件作者使用系统中每个项目的查询来修改列表，而不是修改适当的管理查询，以便在帖子结果中包含他们想要的内容。
BIG WARNINGS
<如果您对php不太熟悉，
do not attempt this.do this on a staging server first 为了确保你不会弄坏东西，一定要
back up any files you are going to edit 在编辑之前。。。因此，如果需要，您可以快速将它们放回原处
termporarily 按如下方式破解wordpress核心：
（如果运行4.1）：
启用调试日志并禁用错误的公共显示（wp-config.php）：
define(\'WP_DEBUG\', true);
define(\'WP_DEBUG_LOG\', true);
define(\'WP_DEBUG_DISPLAY\', false);
这将在主题目录中创建调试日志文件。
编辑wp设置。php并在第213至216行中找到以下内容：
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
wp_register_plugin_realpath( $plugin );
include_once( $plugin );
}
将其更改为以下内容：
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
wp_register_plugin_realpath( $plugin );
$start_at = time();
if ( WP_DEBUG_LOG ) {
error_log("Loading plugin {$plugin}\\r\\n\\t Start: {$start_at}");
}
include_once( $plugin );
$end_at = time();
if ( WP_DEBUG_LOG ) {
error_log("\\t Finished: {$end_at}");
error_log("\\t Total Time: " . $end_at - $start_at . \'(s)\' );
}
}
这只会告诉你在第一次加载时是否有插件做了不好的事情。
您可以临时对同一文件第237行中的do\\u action（“plugins\\u loaded”）命令执行相同的操作，但这只会告诉您加载所有插件所需的时间。
要知道每个插件需要多长时间，您可以挂接到按优先级1加载的plugins\\u，读取所有plugins\\u加载的挂钩，将它们更新为具有不同的优先级，然后添加自己的plugins加载操作以记录每个间隔之间的时间戳。
e、 g。
设置所有插件，使第一个使用插件的加载为10，第二个加载为12，等等。。。然后在每个步骤之间添加您自己的plugins\\u加载操作，以记录时间以及每个步骤所用的时间：
9： 已启动
11： 1秒（时间戳nnnnnnnnnn）
13： 0秒（时间戳nnnnn）
15： 8秒（时间戳nnnnnn）
我知道这可能没有多大帮助，但至少可以让你知道罪魁祸首是什么。
通过使用上述调试命令，您可以carefully 对核心wordpress文件进行一些临时编辑，以记录在不出现错误插件的情况下所需的时间，从而在前端显示错误，从而使站点崩溃。
