/index.php/%postname%/
The 404 page will not work with this permalink configuration because “postname” matches all text.
The way permalink processing works is that it tries to fit your URL into one of several different permalink types. First it looks to see if you specified the word “category” (or whatever your category identifier is), next it looks to see if you gave a date and such, and so on. Failing this sort of thing, it tries to match against your specified permalink string.
%postname% matches anything. So it figures that you’re looking for a post or page with a title of “about2”. This redirects it to the archive/single page and processing stops. It never makes it down to 404. You can only get it to spit out the 404 page when your URL doesn’t conform to any known permalink string.
In other words, while you can use any permalink string you like, not all of the possible ones will actually work. This is the price of allowing custom strings.
So as long I use %postname% in the permalink stucture, then I will not be able to get a proper 404 error ?
Now I have disabled permalinks, and using ids, but still the above urls are valid and do not generate 404 error.
Seems that as long one includes the index.php in the url, then any url will work.
Now when using this url with id one gets the about page:
http://blog.smallvoid.com/?page_id=2
But this url doesn’t return a 404 error:
http://blog.smallvoid.com/?page_id=900
I’m a little puzzled of how to get this 404 thing working.
So as long I use %postname% in the permalink stucture, then I will not be able to get a proper 404 error ?
No. As long as you use something that matches anything for the first entry in the structure, 404’s won’t work. Using postname is perfectly valid, as long as you’re not using *only* postname.
As for the rest of it, IIS may be your main problem here. I don’t know IIS too well. You might want switch to a real webserver, like Apache.
Try using /index.php/%year%/%monthnum%/%day%/%postname%/ and see if that works.
Think the problem is that WordPress collection of wp_rewrite_rules are very greedy (No matter what permalink structure used). The Apache .htaccess file hides this behavior by being able to convert most requests to 404.
When using WordPress on IIS wihtout the protecting of .htaccess rewrite then the greedy wp_rewrite_rules sticks out its ugly head.
It is probably an easier path for me to see if I can get ISAPI rewrite setup, so it can save me from the wp_rewrite_rules, and give me that lovely 404 (Or so I hope).
I can generate some 404 pages by adding this to the top of single.php and page.php for the theme:
<?php if (!have_posts()) { include(get_404_template()); exit; } ?>
So it directs to the custom 404.php for the them.
Guess it is also a good idea, to change the search.php, so search results are not cached by search engines by using noindex.
Have solved my problem by creating a plugin, which reacts to apply_filter(‘the_posts’).
It checks that a the parsed page-/post-/category-id is valid. And if not valid then it returns a 404.
If the id is valid, then it checks that the url used to reach the id is the same as the one wordpress generate. And if not then it performs a 301 to the wordpress generated url.
snakefoot- I’m having the exact same issue as you. I posted about it here:
http://wordpress.org/support/topic/118164
Is your plugin publicly available? Would you be willing to share it with me, please?? I’d really appreciate it, as this issue has been driving me nuts! 🙂
If you read this, could you please drop me a line via the below contact form?
http://www.articulate.com/support/contact/gabe/
Thanks in advance!
To use my plugin one is required to modify certain parts of the WordPress code. The changes are described here:
http://trac.wordpress.org/ticket/3514#comment:8
I have contacted you about sending the plugin to you by email, if you don’t mind making modifications to the official WordPress code (Kind of annoying to upgrade WordPress, when having made modifications to the WordPress code unless using SVN).
