我正在尝试调试一个可能与BBPress相关的间歇性404问题。我读过其他几篇关于间歇404和BBPress的报道,但没有一篇完全适用于我的情况,所以我要问一个新问题。
我的网站主页将间歇加载404。间歇性访问问题似乎每次持续10秒到3分钟。当这种情况发生时,所有试图访问该网站的人都会停止访问(在与托管服务技术支持部门通话时确认)。在此时间窗口内,站点上的其他页面似乎已正确加载。点击刷新最终将成功地正确重新加载页面。
我正在使用查询监视器检查重写规则。以下是页面加载错误时的结果:
Request account-2/conscious-business-design-dashboard
Matched Rule [^/]+/([^/]+)/?$
Matched Query attachment=conscious-business-design-dashboard
Query String attachment=conscious-business-design-dashboard
Query Vars attachment conscious-business-design-dashboard
comments_per_page 50
name conscious-business-design-dashboard
order DESC
posts_per_page 10
update_post_meta_cache 1
update_post_term_cache 1
以下是页面正确加载时的结果:
Request account-2/conscious-business-design-dashboard
Matched Rule (.?.+?)(?:/([0-9]+))?/?$
Matched Query pagename=account-2%2Fconscious-business-design-dashboard
&page=
Query String pagename=account-2%2Fconscious-business-design-dashboard
Query Vars comments_per_page 50
name conscious-business-design-dashboard
order DESC
pagename conscious-business-design-dashboard
posts_per_page 10
update_post_meta_cache 1
update_post_term_cache 1
Queried Object
Single Page: #225 (WP_Post)
以下是404期间运行的最相关查询:
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND wp_posts.post_name = \'conscious-business-design-dashboard\'
AND wp_posts.post_type = \'attachment\'
ORDER BY wp_posts.post_date DESC
以下是页面成功加载时运行的查询:
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND (wp_posts.ID = \'225\')
AND wp_posts.post_type = \'page\'
ORDER BY wp_posts.post_date DESC
当我查看BBPress代码时,我可以在这里确定重写规则:
// Rewrite rule matches used repeatedly below
$root_rule = \'/([^/]+)/?$\';
$feed_rule = \'/([^/]+)/\' . $feed_slug . \'/?$\';
$edit_rule = \'/([^/]+)/\' . $edit_slug . \'/?$\';
$paged_rule = \'/([^/]+)/\' . $paged_slug . \'/?([0-9]{1,})/?$\';
然而,所有的slug都在数据库中正确设置,我不知道它们是如何被破坏的。我在核心代码或插件代码中都找不到查询监视器结果中列出的确切重写规则。
其他信息:
该站点正在使用SSL,并启用了永久链接无论是否启用SSL,我都无法在其他托管服务的测试服务器上复制此问题。主主机上的临时服务器也没有显示404。测试服务器是一个VPS,但也运行足够多的其他站点,以接近满载。主服务器上的直接负载很小(同时有数十个用户),但主站点是共享主机我的uptimerobot监控显示在过去24小时内有两次精确的3小时停机时间,但访问日志没有显示uptimerobot预期的5分钟访问时间,因此我不确定这些数字的准确性。(我试图消除possibility of a CPU overload, 因为404似乎在所有用户中都是瞬时的和时间相关的。向上为每个人,然后突然短暂向下为每个人。)主站点是一个会员站点,并且是活动的,所以“关闭所有插件”并不是一个真正的选项(我们会先放弃论坛)——而且,关闭插件后,我们将无法复制负载以迫使404再次发生。成员资格规则(MemberPress)目前依赖于相当长的永久链接。会员插件是MemberPress和LearnDash。该网站也在运行BuddyPress,我做的一些研究表明可能也会涉及到BuddyPress。听起来在某些情况下,visiting pages in specific orders may trigger a BuddyPress rewrite rule 404, 但我相对确信,就我而言,这个问题并不取决于访问的页面顺序。(我有404错误监视器的referer日志。)我安装了插件查询监视器(提供本问题中的数据)和404错误监视器(该监视器列出了除网站主页以外的其他页面,显示404s,但访问日志仅在主页上显示404s)。我没有安装调试栏,因为他们的支持论坛显示与当前版本的WP不兼容我不能百分之百肯定这个问题是否局限于网站的主页。访问日志说是。404错误监视器显示了大量正在经历404的其他页面。我想我在其他网页上看到过,但我不能发誓。我可以证实,在我和托管技术支持的主页都关闭的时候,我能够访问网站上的其他页面主页不包含BuddyPress或BBPress功能。它有一个嵌入式Vimeo视频、几个按钮、纯文本、图像和一系列显示/隐藏内容的MemberPress访问规则对进一步的故障排除有什么建议吗?
最合适的回答,由SO网友:ChristopherS 整理而成
LearnDash和bbPress/BuddyPress之间存在一个已知的问题,这可能会导致这种情况,我自己也遇到了同样的问题。让人抓狂!它与生成的BP事件的数量成正比,因此用户活动越多,发生的次数就越多。LearnDash支持网站中的详细信息here.
我使用以下代码修复:
// Fix for LearnDash causing 404s on BuddyPress activity (updates, messages)
add_filter( "learndash_flush_rewrite_rules", function( $flush, $post_options ) {
return true;
}, 4, 2 );