【背景】
首先,我们都已知道,wordpress默认设置的文章的链接地址为:
http://localhost/?p=9
其中该文章的9为postID。
而如果想要实现SEO,以及让文章链接地址更加具有可读性,最好的方式是,把上面的?p=9改为更加有意义的字符串
并且保证是英文,这样链接地址才可以更好的显示。
而其中把上面的地址,改为固定的某个地址,叫做固定链接。
而wordpress 3.3中,默认已经自带固定链接的功能了:
设置->固定链接,可以设置多种格式:
日期和名称型 http://localhost/2011/12/20/sample-post/
月份和名称型 http://localhost/2011/12/sample-post/
等等。
但是,去改了其中一种模式之后,再去打开之前的文章,却显示:
The webpage cannot be found
HTTP 404
即打不开网页,找不到网页了。
不过需要提及一点的是,我这里,虽然帖子无法打开,但是在主页中:
http://localhost/
却还是可以查看到那很多篇文章的,只是点击任何一篇,结果都是无法显示而已。
同样地,点击“← 早期文章”去打开第二页,看看更早的帖子,也都是打不开的。
【解决过程】
1.之前就遇到类似问题,最后是通过在固定链接设置中,在设置的模式之前,添加/index.php,而得以正常访问网页。
比如:
去把我所设置的固定链接的类型“日期和名称型“,其所对应的值为:
/%year%/%monthnum%/%day%/%postname%/
将其改为:
/index.php/%year%/%monthnum%/%day%/%postname%/
具体详情参考:
【已解决】wordpress中,设置为固定链接后,显示HTTP 404错误,文章无法打开 找不到网页
但是,此处好像也不起作用了,也无法解决问题。
而且也觉得,这个应该不是很好的方法,毕竟固定链接中还包含一个index.php,这算咋回事啊。。。
2.后来就到网上找,最后是从这里得到启发:
WordPress 修改固定链接后出现 Not Found 的解决方法
http://www.u-ce.com/topics/web-design.html
然后自己确保了:
(1)httpd.conf中
开启了对应的mode_rewrite模块:
把:
#LoadModule rewrite_module modules/mod_rewrite.so
改为:
LoadModule rewrite_module modules/mod_rewrite.so
(2)httpd.conf中把旧的:
/httpd-2.2-x64/htdocs
都改为了对应的当前的地址:
D:/tmp/WordPress/DevRoot/httpd-2.2.19-win64/httpd-2.2-x64/htdocs
(注:我这里的apache是解压的,所以地址没有自动改过来,如果你的apache是安装的,应该安装的时候,自动帮你改好的)
(3)htdocs根目录下已经存在了.htaccess,而且设置都已经正确。
并且,每次在wordpress中更改固定链接的配置时候,wordpress都会自动去更新这个.htaccess文件的。
所以,一般情况下,也不需要我们操心。
附上.htaccess的内容:
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress
(4)httpd.conf中,权限设置,是允许override权限的
httpd.conf中有多个关于AllowOverride的部分。
一个个简单解释一下:
A。全局的default的AllowOverride权限
# # Each directory to which Apache has access can be configured with respect # to which services and features are allowed and/or disabled in that # directory (and its subdirectories). # # First, we configure the "default" to be a very restrictive set of # features. # <Directory /> Options FollowSymLinks AllowOverride None Order deny,allow Deny from all </Directory>
很明显,英文注释解释了,处于安全考虑,此处是默认:
AllowOverride None
以及
Deny from all
关闭了所有的override的权限的和访问权限。
此处我们不需要理会。
B。htdocs部分的AllowOverride权限
# # Note that from this point forward you must specifically allow # particular features to be enabled - so if something's not working as # you might expect, make sure that you have specifically enabled it # below. # # # This should be changed to whatever you set DocumentRoot to. # #<Directory "/httpd-2.2-x64/htdocs"> <Directory "D:/tmp/WordPress/DevRoot/httpd-2.2.19-win64/httpd-2.2-x64/htdocs"> # # Possible values for the Options directive are "None", "All", # or any combination of: # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews # # Note that "MultiViews" must be named *explicitly* --- "Options All" # doesn't give it to you. # # The Options directive is both complicated and important. Please see # http://httpd.apache.org/docs/2.2/mod/core.html#options # for more information. # Options Indexes FollowSymLinks # # AllowOverride controls what directives may be placed in .htaccess files. # It can be "All", "None", or any combination of the keywords: # Options FileInfo AuthConfig Limit # #AllowOverride None AllowOverride All # # Controls who can get stuff from this server. # Order allow,deny Allow from all </Directory>
面默认是:
#AllowOverride None
我把其注释掉,改为我们所需要的:
AllowOverride All
即,此处需要允许所有的override。
这样,我们改了固定链接后,访问帖子文章,才有权限,才能正常访问。
(具体此变量的含义,至今不是彻底的十分清楚,只是知道此处起效而已)
C。其他部分的,好像是关于cgi的,目前不是很清楚,也不需要改。
【总结】
其他配置都已经正确的前提下,通过把httpd.conf中关于htdocs部分的AllowOverride None改为AllowOverride All
就可以实现固定链接修改后,文章仍旧可以正常访问了。
也就可以避免通过在固定链接地址模式前添加/index.php的方式了。
【参考资料】
WordPress 修改固定链接后出现 Not Found 的解决方法
WordPress 修改固定链接后出现 Not Found 的解决方法
【后记】
后来又有一次,在本地wordpress中,遇到了此问题,在修改了固定链接后,结果帖子都打不开,出现404错误。
后来是通过去WAMP中开启Apache的mod_rewrite:
然后WAMP会自动重启Apache,然后就可以正常访问wordpress的帖子了。
看来只是默认的apache,没有开启mod_rewirte而导致此问题的。开启后,就解决了。
不需要改其他(默认的那些)设置的。
转载请注明:在路上 » 【已解决】WordPress更改固定链接后,导致文章帖子出现HTTP 404错误,无法显示,找不到网页,The webpage cannot be found