站长百科 | 数字化技能提升教程 数字化时代生存宝典
首页
数字化百科
电子书
▼
建站程序
开发
服务器
办公软件
开发教程
▼
服务器教程
软件使用教程
运营教程
热门电子书
▼
CSS教程
WordPress教程
导航
程序频道
推广频道
网赚频道
人物频道
网站程序
网页制作
云计算
服务器
CMS
论坛
网店
虚拟主机
cPanel
网址导航
WIKI使用导航
WIKI首页
热点词条
最新资讯
网站程序
站长人物
页面分类
使用帮助
编辑测试
创建条目
网站地图
站长百科导航
站长百科
主机侦探
IDCtalk云说
跨境电商导航
WordPress啦
站长专题
网站推广
网站程序
网站赚钱
虚拟主机
cPanel
网址导航专题
云计算
微博营销
虚拟主机管理系统
开放平台
WIKI程序与应用
美国十大主机
编辑“
WordPress:Using Permalinks
”(章节)
人物百科
|
营销百科
|
网赚百科
|
站长工具
|
网站程序
|
域名主机
|
互联网公司
|
分类索引
跳转至:
导航
、
搜索
警告:
您没有登录。如果您做出任意编辑,您的IP地址将会公开可见。如果您
登录
或
创建
一个账户,您的编辑将归属于您的用户名,且将享受其他好处。
反垃圾检查。
不要
加入这个!
== Permalinks, .htaccess, 和 MS Frontpage == 关于Microsoft Frontpage的一个注释:许多服务器(共享的和专用的)有许多不同的主机公司建造和维护,这些服务器都有用apache构造编译的<tt>mod_frontpage</tt>,在许多情况下,在每个虚拟服务器上还安装了Frontpage 服务器 扩展。这是最常见不过的了,如今许多大多数主机公司的服务器构造过程都使用了许多/大多数的可执行的二进制,这些可执行码,包括了mod_fronpage和服务器扩展。即使因为扩展与apache结合的方式(和<tt>httpd.conf</tt>文件),你没有使用Frontpage,当你试着查看你的WP安装的时候,你可能得到一个500错误或者一个空白的白色网页(虽然管理面板可能正常地运转),原因就在于你的服务器上存在<tt>extensions/mod_frontpage</tt>。 WordPress会与安装的Frontpage扩展一起恰当地运行,但是peralinks确不能运行,而且来自Wordpress管理界面的对于permalinks部分的'''任何的'''更改,都会导致Frontpage服务器扩展的毁坏,原因就在于给.htaccess文件添加了<tt>mod_rewrite</tt>规则。''但是有一个办法可以解决这个问题。'' === 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运行得很好,你可以编辑和发表网页(用[http://www.microsoft.com/frontpage/ 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使用的<tt>%{HTTP_USERAGENT)%</tt>,使用一个第二个的AccessFilename <tt>.wpaccess</tt> to the <tt>httpd.conf</tt> 文件,以及许多其它的内容,没有什么部件能够使FrontPage''和''管理的使用,与WordPress中的permalinks能够同时使用。 解决办法事实上非常简单,我意外地发现了这个解决办法。 如果你使用或者想要在WordPress中使用FrontPage(或者如果你的主机软件包先前就配置为这样的),你可能要在你的服务器上完成以下的步骤,或者让你的主机公司为你完成这些步骤。 Microsoft FrontPage 创建了以下的目录 <pre>_vti_bin</pre> 嵌套在里面了,它创建了<pre>_vti_adm</pre>和<pre>_vti_aut</pre> 除了在你的站点(或者WordPress)根文件夹所有的这些目录中,你会找到额外的<tt>.htaccess</tt>文件。 在这些三个目录以及在根目录上,在所有的<tt>.htaccess</tt>文件上面,你只要添加一行: <pre> 选项 +FollowSymlinks </pre> 其中每一个可能有或者还没有这一行 <pre>选项没有</pre> 编辑并且保存每个<tt>.htaccess</tt>文件,你便完成了。现在一切都运行得非常的好,包括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版本上应该能够运行。 --[[WordPress:User:Chradil|Chradil]] 2006年17时24分 (格林尼治标准时间) === 长的 Permalinks === 当你在一封电子邮件中使用额外长的permalinks并且将permalinks发表到评论和聊天中时候,一些长的permalinks"就被砍断了"或者只有permalinks上的第一个部分,被真正地看成是一个链接,其它的部分会被看成是文本。下面有一个例子。 <div style="margin: 5px; padding:5px"> <tt style="font-weight:bold; color:#036; text-decoration:underline; font-size:0.9em">http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog</tt></div> 结果会是: <div style="margin:5px; padding 5px"><tt> <span style="font-weight:bold; color:#036; text-decoration:underline; font-size:0.9em">http://yourdomain.example.com/2005/10/4/article</span>-about-joe-fred-sally-and-bog</tt> </div> 点击一个较低的链接,用户会得到一个404网页没有发现的错误。如果你有使用很长的permalink文章标题的倾向,采取以下的步骤来防止这个问题的发生。 1.核实一下你真的在使用[[WordPress:Using Permalinks|Permalinks]]。 2.编辑你的<tt>.htaccess</tt>文件并且添加以下的内容: <pre style="font-size: 0.7em"> RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA] </pre> 3.给它测试一下。找到文章的ID数字,在你的浏览器上输入以下的内容(和你的信息),而且你应该再次导向你的文章: <pre> http://yourdomain.example.com/post/(the ID #) </pre> 大多数电子邮件软件并不会切断由angle-brackets (< and >)描绘的URLs,这一点也很值得注意,因此当你在电子邮件中粘贴URLs的时候,你应该将URLs写作: <div style="margin: 5px; padding:5px"> <tt>Read my blog post at <<span style="text-decoration:underline; color:blue">http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog</span>></tt></div> 此外,一些相当好的电子邮件clients,在你编写一个纯文本的电子邮件的时候,给你提供一个"预先格式"电子邮件。粘贴链接的时候,使用"预先格式"选项,会迫使电子邮件client在链接中不插入换行符。 === 解决其它问题 === 如果你的<tt>.htaccess</tt>的产生是正确的,但是Permalinks不能运行,下面的内容可能是一个问题。如果问题继续存在,在[http://www.wordpress.org/support WordPress论坛的]中发表一个短信 怎样分段。 ; '''AllowOverride 没有被激活''' :你的服务器也许没有激活AllowOverride指示。如果AllowOverride指示在你的Apache <tt>httpd.config</tt>文件中设置为<tt>None</tt>,那么<tt>.htaccess</tt>文件便被完全地忽略了。在这种情况下,服务器甚至不会尝试阅读文件系统中的<tt>.htaccess</tt>文件。当这个指示被设置为<tt>All</tt>的时候,那么任何拥有<tt>.htaccess</tt>Context的,都允许在.htaccess文件中。<tt>httpd.config</tt>中激活的AllowOverride指示的例子: <pre> <Directory /> Options FollowSymLinks AllowOverride All </Directory> </pre> 你也可能要在你的文件根上激活AllowOverride指示: <pre> <Directory /var/www/html> # ... other directives... AllowOverride All </Directory> </pre> ; 你也可能要为站点更改AllowOverride设置。这当然是使用Mac OS X服务器时,发生的情况,当时也可能在其它的系统上也适用。通常你可以在<tt>/etc/httpd/sites/</tt>中找到站点的配置文件。 ; 如果你不想将AllowOverride设置为所有的(如上面的那样)那么你的AllowOverride 列表上必须包括FileInfo指示。你必须重新地启动你的Apache 服务器使任何的<tt>httpd.config</tt>文件更改起效,阅读关于[http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride Apache Core 特色]。 ; 导航到的页面不能运行:有时候导航到第二个(或者下一个)文章的页面,可能并不象期望地那样能够运行。你的网页可能使用下面的这些URIs之一产生了到另一个网页的链接: <pre> 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/ </pre> ; 点击那些链接中的一个的结果是网页载入了所有的边缘内容(页眉,页脚,工具条),却没有载入带有文章的网页,或出现一个错误信息:"对不起,没有文章匹配那个标准。" ; 这是由于WordPress产生在<tt>.htaccess</tt>文件中的一个小干扰。要解决这个问题,删除你的.htaccess文件的内容,并且重新地创建这个文件。 <ol> <li>在控制面板上,转到管理 > 文件([[WordPress:Editing_Files|编辑文件的更多信息]])</li> <li>点击链接到你的 .htaccess 文件来编辑它的内容</li> <li>复制文件的内容并且将它粘贴到文本编辑器中的一个文本文件中。这是一个预防措施,以防止你的.htaccess文件有redirects的手工条目,或者对其它的[http://www.javascriptkit.com/howto/htaccess.shtml 便利的 htaccess tricks]</li>的拒绝</li>。 <li>从你的.htaccess文件中删除所有的内容,并且点击更新文件按钮。</li> <li>在控制面板上, 转向选项 > Permalinks。</li> <li>点击更新Permalink结构按钮来为你的permalinks产生新的rewrite规则。</li> <li>使用一个先前断掉的链接来测试结果。</li> <li>将任何的手工htaccess条目返回到你的文件 (将手工htaccess 条目放在<tt># BEGIN WordPress</tt>之前或者放在 <tt># END WordPress</tt> 行之后。)</li> </ol> ; 通过从服务器中删除<tt>.htaccess</tt>文件,创建一个新的空.htaccess文件,将文件权限改为666,然后在选项 > Permalinks通过点击更新Permalinks结构按钮,产生一组新的htaccess规则,你可以执行相似的步骤。 ; 如果这样做仍然不起作用,看看WordPress支持论坛,特别是[http://wordpress.org/support/topic/51613#post-283222 这篇支持的文章]。 ; '''文章的Permalinks 不能运行''' :如果你试着导航到一个最新创建的[[WordPress:Glossary#Page|网页]]但是遇到了一个错误,你可能需要[[WordPress:Permalinks_Options_SubPanel|更新你的Permalink 结构]]。记住每次你给WordPress添加了一个新的静态的网页,新的规则必须产生并且更新到<tt>.htaccess</tt> (WordPress 1.X)或者更新到内部的rewrites 数组(WordPress 2.X)。 ; ''' 到 Ultimate Tag Warrior tag pages 的permalinks不能够运行''' :如果你正在WordPress2.X上使用UltimateTagWarrior插件的时候,你在本地标签URLs上得到了404错误,那是因为由WordPress产生的内在的rewrites,过度地贪婪了,在UTW的rewrite规则有机会之前,便得到了调用。只有使用一个自定义的permalink结构(像 <tt>/%postname%/</tt>)时,通常才会出现这样的情况。要解决这个问题, [[WordPress:Permalinks_Options_SubPanel|转变你的 Permalink 结构]]为 "以日期和名称为基础" 或者改进 UTW 插件将UTW rewrites放置到内部rewrites数组的上端。 [http://www.naturalsearchblog.com/archives/2007/01/20/getting-404-errors-on-ultimate-tag-warrior/ 关于这个的更多的信息]。 ; '''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. === 更多的帮助 === 如果这些步骤都不起作用,在[http://codex.wordpress.org Codex], [[WordPress:Troubleshooting|发现并解决故障]], 或者在[http://wordpress.org/support/支持论坛]上搜索你的问题。
摘要:
请注意,您对站长百科的所有贡献都可能被其他贡献者编辑,修改或删除。如果您不希望您的文字被任意修改和再散布,请不要提交。
您同时也要向我们保证您所提交的内容是您自己所作,或得自一个不受版权保护或相似自由的来源(参阅
Wordpress-mediawiki:版权
的细节)。
未经许可,请勿提交受版权保护的作品!
取消
编辑帮助
(在新窗口中打开)