Support Forum
Thank you for continuing to think about potential causes of this problem.
I'm still looking at the peculiar similarity of the actual versus desired destination when the problem does manifest. See my post #13 above. It seems to me that it might be a situation where rewrite rules are indeed always in effect but not necessarily in the desired sequence.
For example, if a "non-Simple:Press" rule gets matched before a "Simple:Press" rule, it would map to the Unit page. This would be the undesired "problem" scenario. This happens when Simple:Press Update WP Integration is NOT done AFTER the automatic flushing of rewrite rules that occurs when the Settings>Permalinks page is viewed
If, on the other hand, the "Simple:Press" rule matches first, it would map to the Forum page. This would be the desired "no problem" scenario. This happens when Simple:Press Update WP Integration IS done AFTER the automatic flushing of rewrite rules that occurs when the Settings>Permalinks page is viewed.
If this is the explanation, then changing the Unit page slugs so as not to conflict with the Forum page slugs should resolve the problem. I'll try this and let you know what I find.
Brad
It is a reasonable analysis... but - the SP rewrite rules are specifically looking for the existence of the forum slug which would not be present in other pages and posts.
One question I do have... when you update the site permalink structure in the WP admin Settings, do the urls displayed always include the 'index.php' component? I ask this simply because when the the SP rules are compiled they make a call to the WordPress function to check on whether the site is using pathinfo permalinks and if yes the 'index.php is prepended to the forum slug. If this returned a false for any reason then this part would be missed and that might explain what you are seeing. But why that would happen I am unsure unless there were a bug in the Wp code.
YELLOW
SWORDFISH
|
Success!
The problem was apparently related to a conflict between slugs.
My Units (which were in fact posts, not pages) were set up with slugs that were identical to the slugs used by the Forums for those Units.
I didn't realize that slugs need to be globally unique across all post types, including Forums. Now I know better.
Perhaps some additional uniqueness validation could be done in the Simple:Press code to make sure that another user doesn't follow in my unwitting footsteps by creating a non-unique slug for a Forum.
Brad
Ah light dawns. I was about to say that that should not happen because - as I said earlier - the SP rewrite rules are looking specifically for the forum slug.
But - possibly what is happening is that the WordPress is running through the base set of rules first - getting a match even though the earlier part of the url is wrong and then stopping there. Although that doesn't explain why if you rerun the flush on the Wp integration panel it works...
YELLOW
SWORDFISH
|
I think it was a case of the "non-Simple:Press" rule matching the slug first, then sending to the post URL. The "Simple:Press" rule was never run because the other rule matched first. When the SP Update WP Integration is done, it puts the "Simple:Press" rule before the "non-Simple:Press" rule, causing the slug to subsequently match the "Simple:Press" rule first, sending to the forum URL.
And yes, the "index.php" is indeed always present in the URLs.
Enforcing unique slugs should prevent the problem in any case.
I'm using "Month and name" structure:
To create the same scenario as I had, you would want to
1. create a post with the slug "dupe-slug"
2. create a forum with the slug "dupe-slug"
3. create a page with a link to the forum in #2.
4. View the Permalink Settings.
5. View the page in #3, then click the link to the forum. You should land instead at the post in #1.
6. Update WP Integration.
7. Repeat #5. You should land at the forum as desired. (Until you next view the Permalink Settings.)
Brad
1 Guest(s)