WordPress:Using Permalinks

来自站长百科
跳转至： 导航、​ 搜索

导航: 上一级 | WordPress | 首页 | WordPress中文论坛 | WordPress主机 | CMS程序 | 论坛程序 | ECShop | ShopNC | PowerEasy

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/开始。

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

解决 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上的第一个部分，被真正地看成是一个链接，其它的部分会被看成是文本。下面有一个例子。

结果会是：

点击一个较低的链接，用户会得到一个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写作：

此外，一些相当好的电子邮件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. 的拒绝。
  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.

更多的帮助[ ]

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

小贴士和 Tricks[ ]

使你的文章以 .html 结束[ ]

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

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

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

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

外部资源[ ]

取自“https://www.zzbaike.com/wiki/index.php?title=WordPress:Using_Permalinks&oldid=3358”