If you are using the <!–nextpage–> tags in your blog posts, this will add a trailing / to the URL which forces 310 infinite redirection loop.
I had to disable the Plugin in the meanwhile.
@arashster – Interesting, there have been a couple of other reports of 301 infinite loops but I have yet to be able to reproduce them. Two or three were particular to https redirects.
Would you mind emailing me a list of the active plugins you are using? Any email address at marcuspope.com will reach me. I’ve tested the nextpage comment links and they worked just fine on my staging evironment. And can you confirm that you added the required lines of code to wp-config.php? They’re listed in the installation notes.
I’d really like to pin this issue down, so as much info about your wordpress setup as you feel comfortable providing would be great. Themes, plugins, server environment, php version etc. If you had a staging environment I could test on that would be ideal, but that’s a lot to ask for 😀
@arashster – can you try replaceing HTTP_HOST in the wp-config.php statements my plugin needs with SERVER_NAME instead? If you wouldn’t mind trying that and letting me know if you still get redirects and I would really appreciate it. I would try myself but I cannot get the redirect behavior to occur.
Well, the good news is that I have finally been able to reproduce this problem, and I have a fix for the 301 redirect loop. If you are curious about the technical issues keep reading, if you just want to try a fix – try enabling my plugin, and saving the Admin > Settings > Permalinks page two full times Everything should work after that. If someone could let me know whether this works for them I’d appreciate it, it definitely fixed the problem I could reproduce. It also appears to only be a problem on linux/apache setups. So if you are using IIS and also experience this problem please let me know.
Technical Details from here on:
The bad news is I still don’t have a permanent fix to why WordPress can’t find your custom post types to begin with. I know what causes the infinite loop, and I have a temporary solution to the redirect problem but I’m still not sure why it fails to process the permalink structure correctly to begin with.
I am however fairly convinced it’s caused by a bug in WordPress Core. And why it would work with my plugin disabled is due to a hack they implemented as a work-around to the core bug. I think my plugin prevents the hack from working around the core problem. But I can reproduce the behavior with my plugin disabled by switching permalink choices and only saving once. There are a number of others who have posted in forums that they’re not sure why but they’ve always found clicking save multiple times to be a best practice… including Andrew Nacin a core developer.
Problem number one is that custom post type permalinks are loaded at a different point in the call stack depending on if they are created in a theme or a plugin. In a theme you can actually create them in functions.php and they will work. You should be creating them in an init hook, but that still won’t fix this problem. So flushing permalinks for custom post types will use the wrong prefix because they are already loaded and they are not re-initialized in
flush_rewrite_rules. But flushing them again should work because this is the order of execution:
(CPT = Custom Post Type)
1. Get Permalink Format (old version)
1. Initialize NonCPT Permalinks
1. Initialize CPT Permalinks
1. Process Command To Update Permalink Format
1. Flush NonCPT Permalinks
1. Get Permalink Format (new version)
1. Initialize NonCPT Permalinks
1. Re-Use Old CPT Permalinks
1. Update Database
Which results in Custom Post Types keeping their old permalink rewrite rules.
On second page load, we get the permalink format, which is new this time, and the first time we initialize the CPT Permalinks they will be correct, so when they flush again, the new permalinks are preserved.
In plugins the permalinks for custom post types are only loaded once, early in the page load call stack. And I don’t think WP has a way of re-calling them after a flush, so they just preserve the old permalinks. The hack is to then double check the permalink structure when the old link is processed. That comparison fails because it compares a root relative url with an absolute one. But fixing the comparison via another hook in my plugin only fixes the 301 redirect, it doesn’t fix the problem that it is using an old permalink structure to find a post and so it cannot find it.
I’m still working on this but I’m hoping clicking save twice will be a valid work around. Even if I do find the problem, I may not be able to fix it without a core patch… and I hate trying to convince the core development team that they have a bug in their code.
I have confirmed that this is due to a core wordpress bug. http://core.trac.wordpress.org/ticket/21824
The temporary work around is to update to version 1.5 and save your permalinks admin setting page twice.
- The topic ‘[Plugin: Root Relative URLs] Causes permalinks not to work’ is closed to new replies.