WordPress:Using Permalinks

Permalinks是你的个人网络博客帖子永久的URLs也是你的网络博客内容的目录和其它的列表。一个permalink是另一个写博客的人用来链接到你的文章（或者部分），或者用来使你在一个电子邮件信息中发送一个链接到你写的故事中。每篇文章的URL应该是永久的，是永远都不能更改的-既然是perma链接。

Permalink形式

WordPress有三种基本的permalinks形式：

默认的: "Ugly"

默认的看起来像：

http://example.com/?p=N

在N是Post ID数字的位置。它在所有的服务器环境中都能够运行，但是它没有其它的一些选项看起来好看。

mod_rewrite: "漂亮的 Permalinks"

这些是permalinks的holy grail（看看漂亮的Permalinks）。有许多不同的版式，但是最常见的，最通用的，看起来像这样的

    http://example.com/category/post-name/
或者  http://example.com/year/month/day/post-name

有的人删除了一些或者所有的有关日期的部分（年，月，日）以形成一个比较简短的permalink样式。mod_rewritepermalinks需要Apache的mod_rewrite模块。

对于lightpd,请看外部资源。

= PATHINFO: "几乎是漂亮的"

PATHINFOpermalinks看起来与mod_rewrite permalinks非常地相像，但是有一点不同，PATHINFOpermalinks前面嵌入了/index.php，看起来像这样的：

http://example.com/index.php/yyyy/mm/dd/post-name/

否则的话，他们与"pretty" mod_rewrite permalinks是一样的，而且同样地灵活。任何mod_rewrite permalinks可以执行的，在/index.php部分的帮助下，PATHINFO permalinks也可以做。

有一个有用的插件会显示正在使用的permalinks的形式，以及WordPress所使用的内部rewrite规则的详细信息。

选择你的 permalink 结构

在选项→Permalinks面板上，你可以选择其中一个"普通的"结构，或者使用结构标签，在"自定义结构" 区输入你自己的结构。

要激活PATHINFO permalinks，请以index.php/开始，激活你的permalink结构。

结构标签

你可以使用这些标签来自定义你的"漂亮的"或者 "几乎是漂亮的"permalinks。确保以%post_id% 或者%postname%结束你的结构（例如/%year%/%monthnum%/%day%/%postname%/）这样每个permalink点都会指向每一篇文章。

%year%

帖子发表的年份，四位数字，例如2004

%monthnum%

一年的月份，例如05

%day%

一个月的具体日期，例如28

%hour%

一天的具体时间，例如15

%minute%

一小时的具体分钟，例如43

%second%

一分的具体秒数，例如33

%postname%

一个清洁版的帖子标题(post slug 在编辑文章/页面面板区域). So “这是一篇非常好的帖子！”变成了URI中的this-is-a-great-post（请看只使用%postname%）

%post_id%

帖子独一无二的ID #，例如423

%category%

一个类别名的清洁版本（新的/编辑目录面板上的category slug区域）。嵌套的子类别在URL上以一个嵌套的子目录出现。

%author%

一个文章作者名的清洁版本。

类别基础

Category base是用在类别permalinks中的一个前缀，通常采取的形式是 category_base/category_name

默认的类别基础是category。

自定义permalinks几乎在所有的系统上运行时都没有什么问题，但是在一些情况下，一些问题仍然会产生。

只使用 %postname%

如果你将帖子名作为你的permalinks中创建一个例如example.com/post-title结构的唯一的因素，rewrite规则，可能使你无法访问网页，例如你的样式表（样式表有一个相似的版式）或者/wp-admin/文件夹[在 WordPress 2.0+ 版本中也是这样的吗?]。最好在permalink中添加一些数字数据（例如帖子的ID或者日期），以防止这种情况的发生。此外，WordPress v1.2.x需要使用一些日期结构来为一些功能服务，例如使日历合适地运转。/%year%/%monthnum%/%day%/%postname%/通常是一个好的开始。

在一篇帖子中的多个类别中使用%category%

当你给一篇帖子指派多个类别的时候，permalink中只能显示一个类别。这个类别将是编号最低的类别（请看管理类别）。通过所有的类别帖子应该能够正常地访问。

使用 "漂亮的" permalinks

要求必备的条件:

• 用mod_rewrite模块来安装Apache网络服务器

• 在WordPress的主页目录：

• • 激活的FollowSymLinks 选项

• • FileInfo 指示允许(例如 AllowOverride FileInfo, AllowOverride All)

• • 一个.htaccess文件（如果这个文件丢失了，当你激活"pretty" permalinks时，WordPress会试着创建它）

• • 如果你想要WordPress自动地更新.htaccess文件，WordPress需要拥有对于文件的写权限。

• 对于lightpd,请看外部资源

当你创建或者更新一个"pretty" permalink结构，WordPress会产生重写规则，并试着将它们插入一个合适的.htaccess文件。如果它不能那样做的话，它就会显示你现在需要更新你的.htaccess ，并且为你打印出规则让你复制并且粘贴到文件中（将它们放在最后）。

在WordPress 2.0+版本中，你可能只要做一次这样的步骤，因为WordPress在内部重写了。如果你曾经移动了你的WordPress主页目录(Blog address),你就要重复这个步骤。

对于一个现存的.htaccess，WordPress会运转得很好，也不会删除任何现有的RewriteRules或者其它的指示。如果你有其它的mod_rewrite规则，将你的规则放在WordPress的前面。

我的 .htaccess 文件在哪儿?

WordPress的index.php 和 .htaccess文件应该在一起出现在目录上，有你的总选项网页上Blog address (URI)设置显示。因为文件名是以一个点号开始的，通过一个FTP client可能看不见这个文件，除非你更改了FTP工具的参数选择，使其能够显示所有的文件，包括那些隐藏的文件。

创建和编辑 (.htaccess)

如果你还没有一个.htaccess文件，创建一个。如果你有shell或者ssh权限进入你的服务器，一个简单的touch .htaccess命令就能创建文件。如果你使用FTP来传输文件，在你的本地电脑上创建一个文件，命名为1.htaccess，将它上传到你的WordPress文件夹的根上,然后将它重新命名为.htaccess。

你可以通过FTP,shell,或者（有可能）你的主机的控制面板来编辑.htaccess文件。

如果你的.htaccess文件包含有错误，并且破坏了你的站点("内部服务器错误 (500)")，你就要使用FTP或者你的主机的控制面板来删除劣质的.htaccess 文件。

自动上传 .htaccess

如果WordPress不能自动上传你的.htaccess文件，它会向你显示一些内容像如果你的.htaccess文件是可写的，我们就能自动地上传，但是你的文件不是可写的…在选项&rarr附近显示；Permalinks面板上。

如果你想要WordPress来自动地上传这个文件，你就需要给 WordPress 写 .htaccess文件的权限。所需要的精确的权限取决于你的服务器设置。试着给用户提供写权限，然后给小组提供，然后给世界提供写权限，在每次更改权限后，测试一下；WordPress一旦成功地编辑了文件，不要再添加更广的写权限了

在应用了permalinks之后，你应该将权限设置为更强的，像660或者644，来阻止服务器上的其他人潜在地访问了它。

没有mod_rewrite的Permalinks

"Pretty" permalinks需要mod_rewrite， IIS（在Windows服务器上很常见）并不支持mod_rewrite。（如果你在Windows上使用了Apache 2.0.54,倘若mod_rewrite在apache\conf\httpd.conf中激活了，它便能够运行。）但是你可以尝试PATHINFO permalinks;将index.php/放在你自定义的permalinks 结构的开端：

/index.php/%year%/%monthnum%/%day%/%postname%/

这个选项并不是总是能够运行，特别当WordPress在IIS 6 上运行的时候。要使这个选项在IIS 上运行，将这2行添加到一个php.ini文件，在你的网络根上储存这个文件(http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options):

 cgi.fix_pathinfo = 1
 cgi.force_redirect = 0

还有一个方法就是使用IIS的自定义401redirects。它需要你的网络主机允许你添加一个自定义的404redirect,但是它不需要你安装任何第三方的mod_rewrite软件，而且它也不需要你的permalink结构以/index.php/开始。

• http://www.keyboardface.com/IIS-Permalinks/

• 另一个非常简单的自定义404redirect解决办法：http://tech.einaregilsson.com/2007/07/30/pretty-wordpress-permalinks-on-iis/

如果你在你的服务器上有管理者特权，你可能对这些解决办法感兴趣：

• 关于运行在IIS上的博客的WordPress URL Rewrite 插件

• • Dean Lee的在IIS下的为WordPress的URL Rewriting

解决 Permalink 问题

解决.htaccess 产生 问题

如果你安装的WordPress没有产生一个.htaccess文件或者如果WordPress没有在你现存的.htaccess文件写下新的规则，可能有两种原因导致了这种情况。一步一步地运行，只有在前一个步骤不能运行之后，再开始下一个步骤。

1. 改变文件权限:你必须改变文件权限 .htaccess文件权限改为6666，并且用WordPress模板编辑器对它进行编辑，但是并不推荐你这样做，因为如果你这样做了，你的博客上的任何用户，可以编辑模板的，都可以编辑文件。你可以将权限改为660，这样文件只有对服务器是可写的，这也会有一些限制。
2. 服务器封锁:你的主机可能封锁了服务器_软件变数，这可能导致WordPress不能产生.htaccess。如果你确定你的服务器正在运行Apache，你可以通过更改你的wp-includes/vars.php文件，迫使WordPress相信你的服务器正在运行Apache。按照下面的这些步骤，来做出这些更改。
• 使用你的WordPress管理面板上内置的文件编辑器来打开wp-includes/vars.php文件。要导航到这个面板，先登录到WordPress,点击"管理"，然后点击"文件"，下滚至低端，在"其它的文件"标题下的文本框中输入wp-includes/vars.php。 查找

  $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

  并将它替换为

  // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

• 在a new line under

  // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

  and type in

  $is_apache = 1;

下添加一行
3. XAMPP的用户 (Windows):一些版本的XAMPP在默认情况下不能够mod_rewrite（虽然它在Apache中得到了 汇编）。是它能够-随之使WordPress能够写.htaccess文件，需要这个文件来创建pretty permalinks-你必须打开apache/conf/httpd.conf并且不要注释LoadModule rewrite_module modules/mod_rewrite.so（例如，删除行首的hash/pound标记。

Permalinks, .htaccess, 和 MS Frontpage

关于Microsoft Frontpage的一个注释：许多服务器（共享的和专用的）有许多不同的主机公司建造和维护，这些服务器都有用apache构造编译的mod_frontpage，在许多情况下，在每个虚拟服务器上还安装了Frontpage 服务器 扩展。这是最常见不过的了，如今许多大多数主机公司的服务器构造过程都使用了许多/大多数的可执行的二进制，这些可执行码，包括了mod_fronpage和服务器扩展。即使因为扩展与apache结合的方式（和httpd.conf文件），你没有使用Frontpage，当你试着查看你的WP安装的时候，你可能得到一个500错误或者一个空白的白色网页（虽然管理面板可能正常地运转），原因就在于你的服务器上存在extensions/mod_frontpage。

WordPress会与安装的Frontpage扩展一起恰当地运行，但是peralinks确不能运行，而且来自Wordpress管理界面的对于permalinks部分的任何的更改，都会导致Frontpage服务器扩展的毁坏，原因就在于给.htaccess文件添加了mod_rewrite规则。但是有一个办法可以解决这个问题。

Quick Fixes, Frontpage 或者 Permalinks

Frontpage扩展 解决:如果你不在乎permalinks，只想让MS Frontpage服务器扩展再次地运行，你只要编辑你的.htaccess文件，并且用rewrite规则，来移除WordPress部分。

使用Permalinks:如果你不在乎Frontpage（但是你的主机公司安装了扩展）

你就要移除(或者让你的主机公司移除)MS Frontpage 服务器扩展，或者编辑.htaccess文件来移除所有的Frontpage行，只留下WordPress mod_rewrite代码。

共同地使用 FrontPage 和 Permalinks

最后，一个解决办法。

关于这个问题论坛上有几个主题，而且目前为止，没有出现解决问题的办法。

一般来说，在一个安装了FrontPage服务器扩展的Unix服务器上，WordPress运行得很好，你可以编辑和发表网页（用Microsoft FrontPage) — 直到 —你更改一下permalinks(例如，对于关于日期的种类，我喜欢/2005/04/等等)。我通常像那些问及permalinks等等的人建议那种形式的URI,因为那是w3c推荐的方法（看看http://www.w3.org/Provider/Style/URI )。 现在问题在于FrontPage使用.htaccess文件（WordPress mod_rewrite规则必须访问这个文件）它的"发表"和 "网页作者" 设置。一旦WordPress mod_rewrite代码被添加到那个文件中，两种情况会发生—permalinks不再运行，Frontpage服务器扩展也损坏了。

我尝试了无数的方法，来试图解决这个问题，包括试着使用rewrite规则，"忽视"FrontPage使用的%{HTTP_USERAGENT)%，使用一个第二个的AccessFilename .wpaccess to the httpd.conf 文件，以及许多其它的内容，没有什么部件能够使FrontPage和管理的使用，与WordPress中的permalinks能够同时使用。

解决办法事实上非常简单，我意外地发现了这个解决办法。

如果你使用或者想要在WordPress中使用FrontPage(或者如果你的主机软件包先前就配置为这样的)，你可能要在你的服务器上完成以下的步骤，或者让你的主机公司为你完成这些步骤。 Microsoft FrontPage 创建了以下的目录

_vti_bin

嵌套在里面了，它创建了

_vti_adm

和

_vti_aut

除了在你的站点（或者WordPress）根文件夹所有的这些目录中，你会找到额外的.htaccess文件。

在这些三个目录以及在根目录上，在所有的.htaccess文件上面，你只要添加一行：

选项 +FollowSymlinks

其中每一个可能有或者还没有这一行

选项没有

编辑并且保存每个.htaccess文件，你便完成了。现在一切都运行得非常的好，包括FrontPage,和你选择的permalinks。

最后的一个记录

在一个个人记录中，我喜欢使用Frontpage来管理/维护站点，大概在’96，我就开始使用Frontpage了，一直到现在，因为我大多数的工作都是UNIX服务器上完成的，不管怎么说我配置了这个来使用外部编辑器来编辑所有的内容，包括对于php文件的Zend Studio,关于样式表的Bradbury TopStyle,关于图像的Adobe ImageReady/Photoshop等等。我或多或少只将Frontpage作为一个方面的方式来管理站点和访问所有的内容，等等。 然后当我点击任何应用软件中的"保存" 按钮的时候，按钮就会使Frontpage将任何的变化直接地保存到服务器上，而不需要FTP’ing文件，等等。它的确能够帮助许多过程快速地完成，permalink损坏后，去年一年左右，我的确决定情况地不稳定，因为我不需要使用permalink或者不需要使用Fontpage,或者继续重新安装FP扩展。一方面我找到了一个方式来为我"运行的" 站点制作一个.htaccess ，然后在我做其它的事的时候，将它更改问FP .htaccess (permalinks 当然不会运转), 不管哪种方法都是一件令人劳苦的事情。

这个在大多数的FP版本以及如今使用的大多数的扩展的unix版本上应该能够运行。 --Chradil 2006年17时24分 (格林尼治标准时间)

长的 Permalinks

当你在一封电子邮件中使用额外长的permalinks并且将permalinks发表到评论和聊天中时候，一些长的permalinks"就被砍断了"或者只有permalinks上的第一个部分，被真正地看成是一个链接，其它的部分会被看成是文本。下面有一个例子。

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

结果会是：

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

点击一个较低的链接，用户会得到一个404网页没有发现的错误。如果你有使用很长的permalink文章标题的倾向，采取以下的步骤来防止这个问题的发生。

1.核实一下你真的在使用Permalinks。

2.编辑你的.htaccess文件并且添加以下的内容：

 RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]

3.给它测试一下。找到文章的ID数字，在你的浏览器上输入以下的内容（和你的信息），而且你应该再次导向你的文章：

http://yourdomain.example.com/post/(the ID #)

大多数电子邮件软件并不会切断由angle-brackets (< and >)描绘的URLs,这一点也很值得注意，因此当你在电子邮件中粘贴URLs的时候，你应该将URLs写作：

Read my blog post at <http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog>

此外，一些相当好的电子邮件clients，在你编写一个纯文本的电子邮件的时候，给你提供一个"预先格式"电子邮件。粘贴链接的时候，使用"预先格式"选项，会迫使电子邮件client在链接中不插入换行符。

解决其它问题

如果你的.htaccess的产生是正确的，但是Permalinks不能运行，下面的内容可能是一个问题。如果问题继续存在，在WordPress论坛的中发表一个短信 怎样分段。

AllowOverride 没有被激活

你的服务器也许没有激活AllowOverride指示。如果AllowOverride指示在你的Apache httpd.config文件中设置为None，那么.htaccess文件便被完全地忽略了。在这种情况下，服务器甚至不会尝试阅读文件系统中的.htaccess文件。当这个指示被设置为All的时候，那么任何拥有.htaccessContext的，都允许在.htaccess文件中。httpd.config中激活的AllowOverride指示的例子：

 <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

你也可能要在你的文件根上激活AllowOverride指示：

 <Directory /var/www/html>
    # ... other directives...
    AllowOverride All
 </Directory>

；你也可能要为站点更改AllowOverride设置。这当然是使用Mac OS X服务器时，发生的情况，当时也可能在其它的系统上也适用。通常你可以在/etc/httpd/sites/中找到站点的配置文件。 ；如果你不想将AllowOverride设置为所有的（如上面的那样）那么你的AllowOverride 列表上必须包括FileInfo指示。你必须重新地启动你的Apache 服务器使任何的httpd.config文件更改起效，阅读关于Apache Core 特色。

；导航到的页面不能运行：有时候导航到第二个（或者下一个）文章的页面，可能并不象期望地那样能够运行。你的网页可能使用下面的这些URIs之一产生了到另一个网页的链接：

 http://www.example.com/page/2/
 http://www.example.name/category/categoryname/page/2/
 http://www.example/year/month/day/page/2/
 http://www.example/year/month/page/2/

；点击那些链接中的一个的结果是网页载入了所有的边缘内容（页眉，页脚，工具条），却没有载入带有文章的网页，或出现一个错误信息："对不起，没有文章匹配那个标准。"

；这是由于WordPress产生在.htaccess文件中的一个小干扰。要解决这个问题，删除你的.htaccess文件的内容，并且重新地创建这个文件。

1. 在控制面板上，转到管理 > 文件(编辑文件的更多信息)
2. 点击链接到你的 .htaccess 文件来编辑它的内容
3. 复制文件的内容并且将它粘贴到文本编辑器中的一个文本文件中。这是一个预防措施，以防止你的.htaccess文件有redirects的手工条目，或者对其它的便利的 htaccess tricks
的拒绝。
4. 从你的.htaccess文件中删除所有的内容，并且点击更新文件按钮。
5. 在控制面板上, 转向选项 > Permalinks。
6. 点击更新Permalink结构按钮来为你的permalinks产生新的rewrite规则。
7. 使用一个先前断掉的链接来测试结果。
8. 将任何的手工htaccess条目返回到你的文件 (将手工htaccess 条目放在# BEGIN WordPress之前或者放在 # END WordPress 行之后。)

；通过从服务器中删除.htaccess文件，创建一个新的空.htaccess文件，将文件权限改为666，然后在选项 > Permalinks通过点击更新Permalinks结构按钮，产生一组新的htaccess规则，你可以执行相似的步骤。

；如果这样做仍然不起作用，看看WordPress支持论坛，特别是这篇支持的文章。

文章的Permalinks 不能运行

如果你试着导航到一个最新创建的网页但是遇到了一个错误，你可能需要更新你的Permalink 结构。记住每次你给WordPress添加了一个新的静态的网页，新的规则必须产生并且更新到.htaccess (WordPress 1.X)或者更新到内部的rewrites 数组(WordPress 2.X)。

到 Ultimate Tag Warrior tag pages 的permalinks不能够运行

如果你正在WordPress2.X上使用UltimateTagWarrior插件的时候，你在本地标签URLs上得到了404错误，那是因为由WordPress产生的内在的rewrites，过度地贪婪了，在UTW的rewrite规则有机会之前，便得到了调用。只有使用一个自定义的permalink结构(像 /%postname%/)时，通常才会出现这样的情况。要解决这个问题， 转变你的 Permalink 结构为 "以日期和名称为基础" 或者改进 UTW 插件将UTW rewrites放置到内部rewrites数组的上端。 关于这个的更多的信息。

Permalinks 在运行但是没有页面返回

有些版本的PHP4.4x和5.5x，当与一些版本的Apache2.x用在一起的时候，会有一个程序错误，致使mod_rewrite不能执行。更多信息可以查看http://bugs.php.net/bug.php?id=35096 和http://bugs.php.net/bug.php?id=35059.

更多的帮助

If these steps do not work, search for your problem in the Codex, WordPress:Troubleshooting, or in the Support Forum. As a last resort, file a bug report.

如果这些步骤都不起作用，在Codex, 发现并解决故障, 或者在[1]上搜索你的问题。

小贴士和 Tricks

使你的文章以 .html 结束

There's an easy way to having your posts end in a .html extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:

 /%year%/%monthnum%/%day%/%postname%.html

有一个简单的方法可以使你的文章以一个.html结束，使用以上的结构标签。遵循适当地结束permalinks的例子，你可以有一个拥有这个规则的网页http://yoursite.com/2006/01/01/happy-newyear.html：

 /%year%/%monthnum%/%day%/%postname%.html

Note that this does not generate static .html files. It only adds the .html extension, pages are still being dynamically generated. The SEO benefit to this is debatable, but it can be useful should you need to migrate away from WordPress, since the pages can easily be made static and retain their URL structure.

注意这个不会产生静态的.html文件。它只是添加.html扩展，网页还是动态地产生了。SEO受益于这个是有争议的，但是如果你需要从WordPress中迁移出去，这个还是有用的，因为网页可以轻易地被设置为静态的，并且保持它们的URL结构。

WordPress versions prior to 2.3 lacked canonical URLs, making .html something very beneficial to add (forcing the URL to be canonical). Now it only provides limited, if any SEO benefits (see External Resources for further analysis).

WordPress2.3之前的版本缺少规范的URLs，使得添加.html变得有用（迫使URL变得规范）。现在它提供了有限的，如果有的话，SEO好处（查看外部资源，得到更加深入的分析）。

外部资源

• View All your permalinks and rewrites with this WordPress plugin.

• 用这个WordPress插件浏览你所有的permalinks 和 rewrites 。
• Beautify your URLs with Permalinks

• 用Permalinks美化你的URLs

• Example Apache htaccess code — Cut and paste correct .htaccess code here

• Apache htaccess 代码例子 — 剪贴并且在这儿粘贴正确的.htaccess代码。

• How to Configure WordPress to Create Search Engine Friendly URLs for Permalinks

• 怎样配置WordPress来为Permalinks创建搜索引擎有好的URLs

• URL Rewriting Tutorial — the whats, hows and wherefores.

• URL Rewriting 指南 — the whats,方式和理由

• Boost Search Engine Optimisation (SEO) using Permalinks

• 使用Permalinks推进搜索引擎最优化

• Understanding WordPress Permalinks

• 了解 WordPress Permalinks

• mod_rewrite and htaccess help forum
• mod_rewrite 和 htaccess 帮助论坛

• Clean Permalinks for IIS using .htaccess

• 用IIS using .htaccess清洁 Permalinks

• URL rewriting with lighttpd
• 用lightpd rewriting URL

• Permalinks with Lighttpd — using mod_magnet; works on 1.4.2+

• 有Lighttpd的 Permalinks — 使用 mod_magnet; 在1.4.2+上运行。