我每天都使用 WordPress,以前从未见过这个问题。也许 SO 社区有一些见解。
我有一个标准的 WordPress 安装 v4.3,这是当前版本。我没有活动的重写模块。没有设置基本类别或标签。对于干净的 URL,永久链接设置为“帖子名称”,这对于整个网站(除了 /blog 下的所有内容)都适用。
我尝试将 /blog/* 重写为 index.php?page_id=xxx 并编写了一个自定义解析器来处理 URI 段,这似乎可以在本地工作。然而,在服务器上,所有 /blog/xxx 都只是重定向到 /blog/,即使我没有专门告诉它这样做。我尝试在 .htaccess 中设置它:
RewriteRule blog/(category|tag|page|search)/(.+)/?$ index.php?page_id=123
即使正则表达式检查并且我为自定义帖子类型设置的所有其他重写规则都有效,这也不起作用。当失败时,我尝试编写重写规则挂钩:
// pathetic hack to fix wp permalink horror for blogs
add_filter( 'rewrite_rules_array','my_insert_rewrite_rules' );
add_action( 'wp_loaded','my_flush_rules' );
// flush_rules() if our rules are not yet included
function my_flush_rules(){
$rules = get_option( 'rewrite_rules' );
if(isset($_GET['rules']))
{
echo '<pre>';
print_r($rules);
echo '</pre>';
}
if ( ! isset( $rules['blog/(category|tag|page|search)/(.+)/?$'] ) ) {
global $wp_rewrite;
$wp_rewrite->flush_rules();
}
}
// Adding a new rule
function my_insert_rewrite_rules( $rules )
{
$newrules = array();
$newrules['blog/(category|tag|page|search)/(.+)/?$'] = 'index.php?page_id=123';
return $newrules + $rules;
}
如果您在浏览器中运行“?rules”,则会显示当前的重写数组,并且它确实将其添加到数组中。然而,出于某种原因,WP 采取的操作是“重定向”到 index.php?page_id=123,而不是加载它并让我自己解析 URI。就像“博客”这个词在某种程度上是保留的。还有其他人见过这样的事情吗?我能想象的唯一可能会破坏事物的相关插件是 CCTM,但博客不是自定义内容类型。 /blog 只是一个普通页面,就像其他根据 URI 段获取帖子的页面一样。
我建议尝试对这些页面使用标准 WP 架构,但客户坚持认为所有内容都位于 /blog/category/category_name/page/x 下。他们不想在这一点上让步,我理解,因为在本地它按预期工作。是的,服务器设置有细微差别,但共同的核心元素是相同的 - htaccess 已启用,wp 是根目录,未安装在目录中,等等。我尝试过禁用所有插件、切换到2015主题、刷新永久链接、清除缓存等。非常奇怪。
任何输入或类似的故事都可能导致解决方案,所以我欢迎你所拥有的。
我正在回答我自己的问题,因为看起来很多其他人也有类似的问题,并且公认的答案很少。所以对于我的具体情况,这就是答案:
huksley 的回答
,我在 Web 根目录中编写了备用 index_pass.php 文件。该文件仅包含以下内容:
<?php $_SERVER["REQUEST_URI"] = $_SERVER["REDIRECT_URI"]; include("index.php");
RewriteEngine On
RewriteBase /
RewriteRule ^blog/(category|tag|page|search)/(.+)/?$ index_pass.php?page_id=123 [NC,L,E=URI:somedomain.com/blog/$1/$2/$3/$4]
#wordpress defaults below
然后在主题的functions.php中我添加这个以防止新的hacky垃圾解决方案抛出404:
add_filter('template_redirect', 'my_404_override' );
function my_404_override() {
global $wp_query;
if (strpos($_SERVER['REQUEST_URI'], "blog/category") > -1 || strpos($_SERVER['REQUEST_URI'], "blog/tag") > -1 || strpos($_SERVER['REQUEST_URI'], "blog/search") > -1) {
status_header( 200 );
$wp_query->is_404=false;
$bypass = true;
include('page-blog-index.php');
exit;
}
}
那里的流氓 $bypass 只是告诉我填补 page-blog-index.php 中这个破解解决方案造成的空白
我们就这样了。有用。我并不完全确定为什么,我对此有点不舒服,但最终我不在乎,只要它有效。我更希望有一个实际的解决方案,它不会违反任何理智程序员头脑中的每一个逻辑碎片,并且完全在多个博士衍生的 CMS 的实际框架内,但是,嘿,我们不能一直赢,对吧?
希望对其他人有帮助。