WordPress:Using Permalinks

Permalinks are the permanent URLs to your individual weblog posts, as well as categories and other lists of weblog postings. A permalink is what another weblogger will use to link to your article (or section), or how you might send a link to your story in an e-mail message. The URL to each post should be permanent, and never change — hence permalink.

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

Permalink形式

There are three basic types of WordPress permalinks:

WordPress有三种基本的permalinks形式：

默认的: "Ugly"

The default looks like 默认的看起来像：

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

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

where N is the Post ID number. It works on all server environments, but it doesn't look as nice as some of the other options.

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

mod_rewrite: "漂亮的 Permalinks"

These are the holy grail of permalinks (see Pretty Permalinks). There are many different formats, but the most common, and most versatile looks like

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

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

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

Some people eliminate some or all of the date elements (day, month, year) to have a shorter permalink format. mod_rewrite permalinks require Apache's mod_rewrite module.

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

For lighttpd, see External sources.

对于lightpd,请看外部资源。

= PATHINFO: "几乎是漂亮的"

PATHINFO permalinks look very much like mod_rewrite permalinks but for one exception: they have /index.php inserted before them, like so:

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

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

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

Otherwise, they are the same as the "pretty" mod_rewrite permalinks, and are similarly flexible. Anything that mod_rewrite permalinks can do, PATHINFO permalinks can do, with the help of that /index.php part.

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

There is a helpful plugin that displays the type of permalinks being used and detailed information on the internal rewrite rules used by WordPress.

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

选择你的 permalink 结构

In the Options → Permalinks panel, you can choose one of the "common" structures or enter your own in the "Custom structure" field using the structure tags.

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

To activate PATHINFO permalinks, start your permalink structure with index.php/.

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

结构标签

You can use these tags to customize your "Pretty" or "Almost Pretty" permalinks. Make sure to end your structure with either %post_id% or %postname% (e.g. /%year%/%monthnum%/%day%/%postname%/) so that each permalink points to an individual post.

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

%year%

The year of the post, four digits, for example 2004

%year%

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

%monthnum%

Month of the year, for example 05

%monthnum%

一年的月份，例如05

%day%

Day of the month, for example 28

%day%

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

%hour%

Hour of the day, for example 15

%hour%

一天的具体时间，例如15

%minute%

Minute of the hour, for example 43

%minute%

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

%second%

Second of the minute, for example 33

%second%

一分的具体秒数，例如33

%postname%

A sanitized version of the title of the post (post slug field on Edit Post/Page panel). So “This Is A Great Post!” becomes this-is-a-great-post in the URI (see Using only %postname%)

%post_id%

The unique ID # of the post, for example 423

%category%

A sanitized version of the category name (category slug field on New/Edit Category panel). Nested sub-categories appear as nested directories in the URI.

%author%

A sanitized version of the author name.

%postname%

一个清洁版的帖子标题(post slug field on Edit Post/Page panel). So “这是一篇非常好的帖子！”变成了URI中的this-is-a-great-post（请看只使用%postname%）

%post_id%

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

%category%

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

%author%

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

类别基础

The Category base is a prefix used in category permalinks, which always take the form

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

 category_base/category_name

category_base/category_name

The default category base is category. 默认的类别基础是category。

Custom permalinks work on most systems without any problems, but there are still some conditions where problems occur.

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

只使用 %postname%

If you use postname as the only element in your permalinks to create a structure such as example.com/post-title, the rewrite rules may make it impossible to access pages such as your stylesheet (which has a similar format) or the /wp-admin/ folder [is this true in WordPress 2.0+ versions?]. It's best to include some numeric data (e.g. the post ID or date) in the permalink to prevent this from happening. Additionally, WordPress v1.2.x requires the use of a date structure in order for some features, such as the calendar, to function properly. /%year%/%monthnum%/%day%/%postname%/ is always a good start.

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

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

When you assign multiple categories to a post, only one can show up in the permalink. This will be the lowest numbered category (see Manage Categories). The post will still be accessible through all the categories as normal.

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

使用 "漂亮的" permalinks

Requirements:

要求必备的条件:

• Apache web server with the mod_rewrite module installed

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

• In WordPress's home directory,

• 在WordPress的主页目录：

• • The FollowSymLinks option enabled

• • 激活的FollowSymLinks 选项

• • FileInfo directives allowed (e.g. AllowOverride FileInfo, AllowOverride All)

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

• • An .htaccess file (if this file is missing, WordPress will try to create it when you activate "pretty" permalinks)

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

• • If you want WordPress to update the .htaccess file automatically, WordPress will need write access to the file.

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

• For lighttpd, see External Resources.

• 对于lightpd,请看外部资源

When you create or update a "pretty" permalink structure, WordPress will generate rewrite rules and attempt to insert them into the proper .htaccess file. If it can't, it will say something like You should update your .htaccess now and print out the rules for you to copy and paste into the file (put them at the end).

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

In WordPress 2.0+ versions, you'll probably need to do this only once, because WordPress does the rewriting internally. If you ever move your WordPress home directory (Blog address), you'll need to repeat this step.

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

WordPress will play nice with an existing .htaccess and will not delete any existing RewriteRules or other directives. If you have other mod_rewrite rules, put yours before WordPress's.

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

我的 .htaccess 文件在哪儿?

Wordpress's index.php and .htaccess files should be together in the directory indicated by the Blog address (URI) setting on your General Options page. Since the name of the file begins with a dot, the file may not be visible through an FTP client unless you change the preferences of the FTP tool to show all files, including the hidden files.

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

创建和编辑 (.htaccess)

If you do not already have a .htaccess file, create one. If you have shell or ssh access to the server, a simple touch .htaccess command will create the file. If you are using FTP to transfer files, create a file on your local computer, call it 1.htaccess, upload it to the root of your WordPress folder, and then rename it to .htaccess.

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

You can edit the .htaccess file by FTP, shell, or (possibly) your host's control panel.

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

If your .htaccess file contains errors that bring down your site ("Internal Server Error (500)"), you will need to use FTP or your host's control panel to delete the rogue .htaccess file.

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

自动上传 .htaccess

If WordPress can't update your .htaccess file automatically, it will tell you something like If your .htaccess file were writable, we could do this automatically, but it isn’t… near the bottom of the Options → Permalinks panel.

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

If you want to let WordPress do this, you'll need to give WordPress write access to the .htaccess file. The exact permissions necessary depend on your server setup. Try adding write permissions for the owner, then group, then world, testing after each change; once WordPress has edited the file successfully, don't add any further write permissions.

如果你想要WordPress来自动地上传这个文件，你就需要给给 WordPress 写 .htaccess文件的权限。

After applying the permalinks, you should change the permissions to something stronger like 660 or 644 to prevent others on the server from potentially having access to it.

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

没有mod_rewrite的Permalinks

"Pretty" permalinks require mod_rewrite, and IIS (common on Windows servers) does not support mod_rewrite. (If you are using Apache 2.0.54, on Windows, mod_rewrite may work, provided it is enabled in apache\conf\httpd.conf.) But you can try PATHINFO permalinks; put index.php/ at the start of your custom permalink structure:

"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%/

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

This option may not always work, especially in cases of WordPress running on IIS 6. To make this option work on IIS, add these 2 lines to a php.ini file and store that file in your webroot (http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options):

这个选项并不是总是能够运行，特别当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

cgi.fix_pathinfo = 1

 cgi.force_redirect = 0

Another solution exists using IIS' custom 404 redirects. It requires that your web host allows you to add a custom 404 redirect, but it doesn't require you to install any 3rd party mod_rewrite software and it also doesn't require that your permalink structure begin with /index.php/.

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

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

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

• Another very simple custom 404 redirect solution: http://tech.einaregilsson.com/2007/07/30/pretty-wordpress-permalinks-on-iis/

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

If you have administrator privileges on your server, you may be interested in these solutions:

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

• WordPress URL Rewrite Plugin for blogs running on IIS by Binary Fortress Software

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

• • URL Rewriting for WordPress under IIS by Dean Lee

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

解决 Permalink 问题

解决.htaccess 产生 问题

If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this. Work step by step and continue to the next step only if the previous step does not work.

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

1. Change File Permissions: You must chmod the .htaccess file to 666 to edit it with the WordPress template editor, but this is not recommended, since if you do that, any user of your blog, who can edit templates will be able to edit it. You can change the permissions to 660 to make it server-writable, which again will have the same limitation.
1. 改变文件权限:你必须改变文件权限 .htaccess文件权限改为6666，并且用WordPress模板编辑器对它进行编辑，但是并不推荐你这样做，因为如果你这样做了，你的博客上的任何用户，可以编辑模板的，都可以编辑文件。你可以将权限改为660，这样文件只有对服务器是可写的，这也会有一些限制。
2. Server Blockage: Your host might have blocked the SERVER_SOFTWARE variable and this will cause WordPress' .htaccess generation to fail. If you are sure that your server is running Apache, you can force WordPress to believe that your server is running Apache by changing your wp-includes/vars.php file. Follow the steps below to implement these changes.
3. 服务器封锁:你的主机可能封锁了服务器_软件变数，这可能导致WordPress不能产生.htaccess。如果你确定你的服务器正在运行Apache，你可以通过更改你的wp-includes/vars.php文件，迫使WordPress相信你的服务器正在运行Apache。按照下面的这些步骤，来做出这些更改。
• Open the wp-includes/vars.php file using the built in file editor in your WordPress Admin panel. To navigate to this panel, login to WordPress, click on "Manage", then on "Files", scroll to the bottom and type in wp-includes/vars.php into the text box under the "Other Files" title.
• 使用你的WordPress管理面板上内置的文件编辑器来打开wp-includes/vars.php文件。要导航到这个面板，先登录到WordPress,点击"管理"，然后点击"文件"，下滚至低端，在"其它的文件"标题下的文本框中输入wp-includes/vars.php。 Look for

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

  and replace it with

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

• Add a new line under

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

  and type in

  $is_apache = 1;

查找

$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;

下添加一行
4. Users of XAMPP (Windows): Some versions of XAMPP do not enable mod_rewrite by default (though it is compiled in Apache). To enable it — and thus enable WordPress to write the .htaccess file needed to create pretty permalinks — you must open apache/conf/httpd.conf and uncomment the line LoadModule rewrite_module modules/mod_rewrite.so (i.e., delete the hash/pound sign at the front of the line).
2. 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

A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with mod_frontpage compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the httpd.conf file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because extensions/mod_frontpage exist on your server.

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

Wordpress will operate correctly with the Frontpage Extensions installed, however permalinks will not function at all and ANY change to the permalinks section from the Wordpress admin interface will cause corruption of the Frontpage server extensions due to the addition of the mod_rewrite rules to the .htaccess file. There is however now a fix for this situation.

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

Quick Fixes, Frontpage 或者 Permalinks

Frontpage Extensions Fix: If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the WordPress section with the rewrite rules.

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

To Use Permalinks: If you don't care about Frontpage(but your hosting company has the extensions installed)

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

You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the WordPress mod_rewrite code.

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

共同地使用 FrontPage 和 Permalinks

Finally, A solution.

最后，一个解决办法。

There have been a number of threads on this issue in the support forums, and until now, no solution to the problem.

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

Normally, on a Unix server with the Microsoft FrontPage Server extensions installed WordPress works just fine and you are able to edit and publish pages (with Microsoft FrontPage) — until — you make a change to the permalinks (for example to the date based kind that I like /2005/04/etc). I often suggest that type of URI to folks asking about permalinks etc, as that is the method recommended by the w3c (see http://www.w3.org/Provider/Style/URI ).

一般来说，在一个安装了FrontPage服务器扩展的Unix服务器上，WordPress运行得很好，你可以编辑和发表网页（用Microsoft FrontPage) — 直到 —你更改一下permalinks(例如，对于关于日期的种类，我喜欢/2005/04/等等)。我通常像那些问及permalinks等等的人建议那种形式的URI,因为那是w3c推荐的方法（看看http://www.w3.org/Provider/Style/URI )。

Now, the problem is that FrontPage uses the .htaccess file (which the WordPress mod_rewrite rules must access) for its "publishing" and "web authoring" configuration. As soon as the WordPress mod_rewrite code is added to the file, two things happen — the permalinks don't work and the Frontpage Server extensions become corrupt.

现在问题在于FrontPage使用.htaccess文件（WordPress mod_rewrite规则必须访问这个文件）它的"发表"和 "网页作者" 设置。一旦WordPress mod_rewrite代码被添加到那个文件中，两种情况会发生—permalinks不再运行，Frontpage服务器扩展也损坏了。

I have tried countless ways to get around this, including trying to use rewrite rules that "ignore" the %{HTTP_USERAGENT)% used by FrontPage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked to allow use of FrontPage and management and use of permalinks in WordPress at the same time.

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

The solution is actually simple, and I figured it out by accident.

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

If you are using, or wish to use FrontPage (or if your hosting package is pre-configured that way) along with WordPress, you'll need to take the following simple steps on your server or have your hosting company do them for you.

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

Microsoft FrontPage creates the following directory Microsoft FrontPage 创建了以下的目录

_vti_bin

_vti_bin

Nested within that it creates both

_vti_adm

and

_vti_aut

嵌套在里面了，它创建了

_vti_adm

和

_vti_aut

In addition to in your site (or WordPress) root folder in all of those directories you will find additional .htaccess files.

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

In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:

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

Options +FollowSymlinks

选项 +FollowSymlinks

There may or may not already be a line in each like

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

Options None

选项没有

Edit and save each .htaccess file and you're done. Now everything works perfectly, including FrontPage, AND the permalinks of your choosing.

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

最后的一个记录

On a personal note, I prefer to use Frontpage to manage/maintain sites, I've been using it since around '96, and by now, since I do most work on UNIX servers anyway I have it configured to use external editors for just about everything, including Zend Studio for php files, Bradbury TopStyle for stylesheets, Adobe ImageReady/Photoshop for images, etc. I'm more or less just using Frontpage as a convenient way to manage the site and access everything, etc. Then when I hit the "save" button in any of the other applications, they have Frontpage save my changes directly to the server, with no need to be FTP'ing files around, etc. It does help to get lots accomplished very quickly, and I was pretty bummed for the past year or so with the permalink frustration, since I was either needing to not use permalinks or not use Frontpage, or keep re-installing the FP extensions. At one point I found a way to make a .htaccess for my "running" site, but then change it to a FP .htaccess when I was doing any work (permalinks of course didn't work), either way it was a real pain.

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

This should work with most versions of FP and most of the unix versions of the extensions in use today.

这个在大多数的FP版本以及如今使用的大多数的扩展的unix版本上应该能够运行。

--Chradil 17:24, 17 May 2006 (GMT)

--Chradil 2006年17时24分 (格林尼治标准时间)

长的 Permalinks

When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.

当你在一封电子邮件中使用额外长的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

Can result in: 结果会是：

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

To click on the lower link, the user would get a 404 Page Not Found Error. If you have a tendency to use very long permalink post titles, take these steps to prevent this problem.

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

1. Check that you are indeed using Permalinks. 1.核实一下你真的在使用Permalinks。

2. Edit your .htaccess file and add the following:

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

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

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

3. Test it. Find a post's ID number and type the following (with your information) in your browser and you should be redirected to your post:

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

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

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

It is also worth noting that most email software will not cut off URLs that have been delineated with angle-brackets (< and >), so when pasting URLs into emails, you should write them as so:

大多数电子邮件软件并不会切断由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>

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

Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.

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

解决其它问题

If your .htaccess file is being generated correctly, but Permalinks still do not function, the following might be a problem. If problems persist, post a note in the WordPress Forum's How To section.

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

AllowOverride Not Enabled

Your server may not have the AllowOverride directive enabled. If the AllowOverride directive is set to None in your Apache httpd.config file, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem. When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. Example of enabled AllowOverride directive in httpd.config:

AllowOverride 没有被激活

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

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

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

You may also have to enable the AllowOverride directive in your DocumentRoot:

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

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

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

You may also have to change the AllowOverride settings for the site. This is surely the case when using Mac OS X Server, but might be likewise with other systems. Usually you can find the site configuration files in /etc/httpd/sites/

；你也可能要为站点更改AllowOverride设置。这当然是使用Mac OS X服务器时，发生的情况，当时也可能在其它的系统上也适用。通常你可以在/etc/httpd/sites/中找到站点的配置文件。

If you don't want to set AllowOverride to all (as it is above) then your AllowOverride list must include the FileInfo directive. You must restart your Apache server for any httpd.config file changes to take effect. For more information on which overrides are allowed, read about Apache Core Features.

；如果你不想将AllowOverride设置为所有的（如上面的那样）那么你的AllowOverride 列表上必须包括FileInfo指示。你必须重新地启动你的Apache 服务器使任何的httpd.config文件更改起效，阅读关于Apache Core 特色。

Paged Navigation Doesn't Work

Sometimes navigation to second (and subsequent) pages of posts does not work as expected. Your page may generate a link to a page with one of these URIs:

；导航到的页面不能运行：有时候导航到第二个（或者下一个）文章的页面，可能并不向期望地那样能够运行。你的网页可能使用下面的这些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/

 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/

The result of clicking one of those links is that the page loads with all the surroundings (header, footer, sidebar), but instead of a page of posts, there is an error message: "Sorry, no posts match that criteria."

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

This is due to a glitch in the .htaccess file that WordPress generates. To fix it, delete the contents of your .htaccess file and re-create it.

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

1. In the Control Panel, go to Manage > Files (More Info on Editing Files)
1. 在控制面板上，转到管理 > 文件(编辑文件的更多信息)
2. Click the link to your .htaccess file to edit its contents
3. 点击链接到你的 .htaccess 文件来编辑它的内容
4. Copy the contents of the file and paste it to a text file in a text editor. This is a precaution in case your .htaccess file has manual entries for redirects, denials or other handy htaccess tricks
5. 复制文件的内容并且将它粘贴到文本编辑器中的一个文本文件中。这是一个预防措施，以防止你的.htaccess文件有redirects的手工条目，或者对其它的便利的 htaccess tricks
的拒绝。
6. Delete all contents from your .htaccess file and click the Update File button.
7. 从你的.htaccess文件中删除所有的内容，并且点击更新文件按钮。
8. In the Control Panel, go to Options > Permalinks.
9. 在控制面板上, 转向选项 > Permalinks。
10. Click the Update Permalink Structure button to freshly generate new rewrite rules for your permalinks.
11. 点击更新Permalink结构按钮来为你的permalinks产生新的rewrite规则。
12. Test the results using a link that had previously broken.
13. 使用一个先前断掉的链接来测试结果。
14. Add any manual htaccess entries back in your file (Place manual htaccess entries before the # BEGIN WordPress or after # END WordPress lines.)
2. 将任何的手工htaccess条目返回到你的文件 (将手工htaccess 条目放在# BEGIN WordPress之前或者放在 # END WordPress 行之后。)

You may also perform similar steps by deleting the .htaccess files from the server, creating a fresh empty .htaccess file, changing its permissions to 666, and then in Options > Permalinks generate a new set of htaccess rules by clicking the Update Permalinks Structure button.

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

If that still doesn't work, take a look at the WordPress support forums, specifically, this support post.

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

Permalinks to pages don't work

If you've tried to navigate to a newly created Page and encounter an error, you likely need to update your Permalink structure. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to .htaccess (WordPress 1.X) or to the internal rewrites array (WordPress 2.X).

文章的Permalinks 不能运行

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

Permalinks to Ultimate Tag Warrior tag pages don't work

If you get 404 errors on local tag URLs when using the UltimateTagWarrior plugin on WordPress 2.X, it's because the internal rewrites generated by WordPress are being overly greedy and getting invoked before UTW's rewrite rules have a chance. This usually occurs only when using a custom permalink structure (like /%postname%/). To fix it, either switch your Permalink structure to "Date and name based" or hack the UTW plugin to place the UTW rewrites at the top of the internal rewrites array. More Info on this.

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

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

Permalinks work but no pages are returned

Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.

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+上运行。