个人工具
名字空间
变换
操作

WordPress:Using Permalinks

来自站长百科
跳转到: 导航, 搜索

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

目录

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

Permalink形式

WordPress有三种基本的permalinks形式:

默认的: "Ugly"

默认的看起来像:

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

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

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. 的拒绝。
  5. 从你的.htaccess文件中删除所有的内容,并且点击更新文件按钮。
  6. 在控制面板上, 转向选项 > Permalinks。
  7. 点击更新Permalink结构按钮来为你的permalinks产生新的rewrite规则。
  8. 使用一个先前断掉的链接来测试结果。
  9. 将任何的手工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=35096http://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好处(查看外部资源,得到更加深入的分析)。

外部资源

留言