| 开发者 | |
|---|---|
| 更新时间 | 2009年8月18日 03:27 |
| PHP版本: | 2.0.0 及以上 |
| WordPress版本: | 2.6 |
http://example.com/post/hello-world/2Even though the official URL is this:
http://example.com/post/hello-world/Permalink Validator makes a hook to template_redirect, and then adds some extra validation of the URL supplied before actually calling the theme-templates.
permalink-validator.php to the /wp-content/plugins/ directoryIf having the ability to use htaccess or isapi_rewrite, then one should continue to use these to add missing trailing back-slash or www prefix. They are a lot faster at redirecting than Permalink Validator, as they are activated without starting the PHP script engine when the URL has incorrect format. Permalink Validator extends the validation so besides checking the format, then it also checks that the url is referring to something valid. The validation of the url doesn't generate any extra overhead in database queries (unless the url requires redirection).
The plugin makes a redirect when the url used to reach the page doesn't match the expected permalink url. Some times this leads to an endless loop, which Firefox shows as:
The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete. * This problem can sometimes be caused by disabling or refusing to accept cookies.This can be caused by a conflict in the htaccess / isapi_rewrite redirection rules and the given permalink structure:
The Permalink Validator will pretty much validate any URL you throw at it, but sometimes there are URL's that should not be validated. Edit the plugin-code and replace this line:
$excludes = array();With an array of the URL's to ignore:
$excludes = array("/forum");Plugins that requires an URL excluded:
Add the following lines to your robots.txt:
Disallow: */feed Disallow: */atom Disallow: */rss2 Disallow: */rss Disallow: */trackback Disallow: /*/feed Disallow: /*/atom Disallow: /*/rss2 Disallow: /*/rss Disallow: /*/trackback
Wordpress supports by default Apache htaccess and its mod_rewrite rules. When using Wordpress on IIS then these will not work and one is limited to this type of permalink:
http://example.com/index.php/post/hello-world/To remove the index.php, then one can either use the custom 404 redirects or isapi_rewrite. If using isapi_rewrite and changing from using index.php to not using index.php, then one can use the following httpd.ini (Assumes Wordpress is installed in the root):
[ISAPI_Rewrite] # Rules to ensure that normal content gets through RewriteRule /software-files/(.*) /software-files/$1 [L] RewriteRule /images/(.*) /images/$1 [L] RewriteRule /favicon.ico /favicon.ico [L] RewriteRule /robots.txt /robots.txt [L] # For file-based wordpress content (i.e. theme), admin, etc. RewriteRule /wp-(.*) /wp-$1 [L] # Rule to perform 301 redirect to ensure trailing back-slash on post and pages RewriteCond Host: (.*) RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [I,R] # Rule to perform 301 redirect (Remove index.php if specified) RewriteRule /index.php/(.*) /$1 [I,RP] # For normal wordpress content, via index.php RewriteRule ^/$ /index.php [L] RewriteRule /(.*) /index.php/$1 [L]
Permalink Validator cannot see the difference between this url:
http://example.com/And this url on IIS:
http://example.com/index.phpIt can also not see the difference between this url:
http://example.com/And this url on IIS:
http://example.com/////This is because REQUEST_URI is not supported properly on IIS, and this plugin can only simulate REQUEST_URI to a certain limit. Therefore it is impossible to know whether index.php or extra slashes was specified or not. The solution is to use a rewrite engine like ISAPI_rewrite or IIS mod-rewrite as they can provide a proper REQUEST_URI.
Microsoft IIS fails to reply with error code 404 in the HTTP header, when trying to access an non existing Wordpress page. This usually happens when using a custom 404 page on IIS. It seems that when using PHP on IIS, then it is not possible to reply with a proper HTTP header. Apparently the only way to return a proper 404 on IIS is to use ASP.
Google tracking code adds a question-mark (?) option to the URL, which the Permalink Validator will strip because it is not part of the permalink URL. Instead of using a question-mark (?), then one could use a hash (#) value, and then modify the Google tracking code to extract the hash value instead of the question-mark value.