在WordPress中重写URL的一些提示和插件

WBOLT_COM 6 月 02, 2023 1.1k+ 0

WordPress的最新更新使开发者可以非常迅速地定制他们的个人网站。更新你的主题的区域，替换侧边栏的小部件，甚至编写你自己的自定义PHP代码功能，都很简单。其广度是巨大的–其中一个受欢迎的领域是改写漂亮的URL固定链接。

你可以用一些方法去更新默认的WordPress重写系统。在这个教程中，我将分享几个例子，并演示这个过程是多么简单。你需要对PHP有一定的了解才能知道代码中发生了什么，但复制和粘贴到你自己的模板中是如此简单，几乎没有任何工作。

了解WP_Rewrite

如果你对Apache服务器上的mod_rewrite非常熟悉，那么你会发现WordPress的重写语法。他们的系统仍然建立在.htaccess文件的基础上，但所有的规则都是用PHP编码的。这实际上使这个过程更容易一些，因为我们对编写我们自己的URL有更多的控制。

我建议浏览一下$wp_rewrite类的页面，因为它有大量关于这个主题的信息。甚至还有一些我们可以参考的小例子，使一切更容易理解。大部分的代码可以直接写在你的主题的 functions.php 文件中。让我们先来看看WordPress已经包含的默认重写内容。

$wp_rewrite->rules

通过将 $wp_rewrite 类声明为全局，我们可以访问所有的内部数据。当你去添加你自己的规则时，这些规则被添加到一个名为 $wp_rewrite->rules 的数组中。记住这个变量很重要，因为在开发过程中，你可能需要多次引用这些数据。

<?php
global $wp_rewrite;
print_r($wp_rewrite->rules);
?>

I added this block of code into my theme’s page.php file. It will output a large array of data which looks like a big mess. But if you View Source on your page it’s actually easy to see which rewrite rules are matched to which filename. For example, let’s look at the rules for category rewrites:

我在我的主题的page.php文件中加入了这块代码。它将输出一个大的数据数组，看起来像一个大混乱。但如果你在你的页面上查看来源，实际上很容易看到哪些重写规则与哪个文件名相匹配。例如，让我们看一下类别重写的规则：

[category/(.+?)/?$] => index.php?category_name=$matches[1]

左边括号里的部分是我们要寻找的Apache RewriteRule。从/category/部分开始，后面是任何字符串的字符。如果这一点被匹配，那么服务器就知道要参考 index.php?category_name= ，同时替换掉末尾的变量。

设置自定义固定链接

仅仅在$wp_rewrite类中就有很多内容可以讨论。许多其他的属性可以被引用，比如 $wp_rewrite->category_base 或 $wp_rewrite->author_base ，用于获取这些页面的默认URL结构。但除了拉取WP的默认设置外，我们也可以建立我们自己的规则。

重建Author Base

当你进入固定链接设置页面时，你可以选择重设类别和标签基础。但奇怪的是，重置Author Base的选项却没有。

但我们可以使用WordPress代码中的 add_rewrite_rule() 来整合一些新的设置。在这种情况下，我把/author/替换成了/writer/，但你可以使用你喜欢的任何基数。此外，我还复制了一些其他的重定向，用于作者页和RSS订阅。你可以把这块代码添加到你的主题的 functions.php 文件中。

add_action( 'init', 'add_author_rules' );
function add_author_rules() { 
    add_rewrite_rule(
        "writer/([^/]+)/?",
        "index.php?author_name=$matches[1]",
        "top");
   
    add_rewrite_rule(
  "writer/([^/]+)/page/?([0-9]{1,})/?",
  "index.php?author_name=$matches[1]&paged=$matches[2]",
  "top");
   
    add_rewrite_rule(
  "writer/([^/]+)/(feed|rdf|rss|rss2|atom)/?",
  "index.php?author_name=$matches[1]&feed=$matches[2]",
  "top");
     
    add_rewrite_rule(
  "writer/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?",
  "index.php?author_name=$matches[1]&feed=$matches[2]",
  "top");
}

即使不使用 $wp_rewrite 变量也可以访问这个函数。一些开发者喜欢这种方法，因为它比用类属性硬编码更简单。然而我也注意到这种方法对于一些WordPress的安装来说并不总是可靠的。实际上还有第二个选择，就是在冲刷你的.htaccess后，在钩子上添加这些规则（见下文）。

Author Base使用generate_rewrite_rules

为这个方法写作，我们将再次需要全局的$wp_rewrite类。然后我设置了一个名为 $new_rules 的新变量，其中包含一个关联数组的数据。我下面的例子代码只是为基本的作者页部分进行重写。

function generate_author_rewrite_rules() {
  global $wp_rewrite;
  $new_rules = array(
    "writer/([^/]+)/?" => "index.php?author_name=".$wp_rewrite->preg_index(1)
  );
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}

但如果我们想包括多个页面和RSS订阅，我们可以加强数组的功能。你可以选择创建一个PHP函数来推送关联数组数据，这可能有点太复杂了。我们也可以通过逗号来分割数据块，在数组中表现为独立的实体。请看我再次写在 functions.php 主题文件中的更新代码。

function generate_author_rewrite_rules() {
  global $wp_rewrite;
  $new_rules = array(
    "writer/([^/]+)/?" => "index.php?author_name=".$wp_rewrite->preg_index(1),
  "writer/([^/]+)/page/?([0-9]{1,})/?" => "index.php?author_name=".$wp_rewrite->preg_index(1)."&paged=".$wp_rewrite->preg_index(2),
  "writer/([^/]+)/(feed|rdf|rss|rss2|atom)/?" => "index.php?author_name=".$wp_rewrite->preg_index(1)."&feed=".$wp_rewrite->preg_index(2),
  "writer/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?" => "index.php?author_name=".$wp_rewrite->preg_index(1)."&feed=".$wp_rewrite->preg_index(2)
  );
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}

请记住，这两种方法在你刷新原始重写规则之前都不会起作用。当你对这些函数进行修改时，你必须这样做，但之后你的新规则将无限期地坚持下去。

刷新重写规则

每当你对URL重写代码进行更新时，这些变化不会立即应用。你必须刷新.htaccess重写规则，这样你的新代码才会被加入。然而，在每一个页面启动时都这样做是非常浪费的，因为它会写入数据库并硬刷新.htaccess文件。

一个更好的方法是在管理面板中访问你的permalinks页面并重新保存更改。这总是调用flush_rewrite_rules，所以你永远不必担心用户在前台遇到加载问题。而且只需要一次就可以重新保存页面并更新你系统中的所有规则。但如果这不起作用，你可以尝试调用 $wp_rewrite->flush_rules() ；

使用非WP规则

在 $wp_rewrite 类中，我们可以访问几十个属性。其中一个比较重要的选项是 $wp_rewrite->non_wp_rules ，它收集了一个不影响index.php文件的重定向数组。

这实际上是在WordPress插件开发中最常使用的。你可以将一个特定的自定义URL类型（如 /calendar/jun-2012/ ）推送到你的网站后台（ /wp-content/plugins/calendarplug/myscript.php ）。当然，除了插件之外，这种自定义重写规则的关联阵列还有更多的用途。我在下文中提供了一个很好的例子。

屏蔽你的主题文件

这是我在WordPress讨论区经常看到的一个常见建议。理想情况下，我们想用一个更优雅的URL来引用 /wp-content/themes/mytheme/ 文件夹中的一些文件。注意，这将需要一组不同的WordPress重写来改变目录结构。

WordPress的内部重写系统总是将内容推向一个单一的路由文件。在默认情况下，我们使用index.php以及任何额外的查询字符串数据。但对于隐藏我们的标准模板目录（ /wp-content/themes/mytheme/* ），我们将需要显示许多不同的文件。

add_action('generate_rewrite_rules', 'themes_dir_add_rewrites');
 
function themes_dir_add_rewrites() {
  $theme_name = next(explode('/themes/', get_stylesheet_directory()));
 
  global $wp_rewrite;
  $new_non_wp_rules = array(
    'css/(.*)'       => 'wp-content/themes/'. $theme_name . '/css/$1',
    'js/(.*)'        => 'wp-content/themes/'. $theme_name . '/js/$1',
    'images/wordpress-urls-rewrite/(.*)'    => 'wp-content/themes/'. $theme_name . '/images/wordpress-urls-rewrite/$1',
  );
  $wp_rewrite->non_wp_rules += $new_non_wp_rules;
}

我写了一个新的函数 themes_dir_add_rewrites() 来从这些较长的URL中提取所有的主要内容，并在后台重定向它们。注意，我们正在使用$wp_rewrite类的另一个神秘的属性，名为 non_wp_rules 。根据文档，这些规则不直接指向WP的index.php文件，将在服务器端处理。

这些非WP规则的伟大之处在于，你仍然可以很容易地管理旧的URL方法。没有什么可以阻止你链接到：

/wp-content/themes/mytheme/images/wordpress-urls-rewrite/logo.jpg.

但如果你能参考的话，它看起来就会好很多：

/images/wordpress-urls-rewrite/logo.jpg 代替上面的链接。