I installed the rewrite.script but did not make any changes to the existing permalink structure.

1. The existing permalink structure works fine as long as Simple:Press Update WP Integration is done AFTER the automatic flushing of rewrite rules that occurs when the Settings>Permalinks page is viewed.  I really don’t want to introduce a new variable to this troubleshooting process by also changing the permalink structure.  If the existing structure can work some of the time (as indicated above), it should be able to work all of the time.

2. There seems to be a very tight relationship between the cause and effect noted above.  In my testing today, no cause other than flushing the permalinks produced the problem.  While I understand that other plugins could possibly create rewrite rules, that did not produce the problem during today’s testing.

Rather than introduce possibly unrelated factors such as a different permalink structure or other plugins, I think it would be best to stay focused on what exactly is the interaction between the noted cause and effect.  How does flushing the rewrite rules cause a problem for Simple:Press?  How does Update WP Integration restore functionality?  Knowing that, I expect it would be possible to circumvent the problem entirely.

Did you find any significance to the similarity of the URLs per my post #13?  I was hoping that might lead in a helpful troubleshooting direction.

Brad

Brad Siegfried said
I installed the rewrite.script but did not make any changes to the existing permalink structure.

Then there is probably little point in installing the rewrite rules script if you are not intending to use it. My intention in pointing it out was to try and discover if it actually helped.

1. The existing permalink structure works fine as long as Simple:Press Update WP Integration is done AFTER the automatic flushing of rewrite rules that occurs when the Settings>Permalinks page is viewed.  I really don’t want to introduce a new variable to this troubleshooting process by also changing the permalink structure.  If the existing structure can work some of the time (as indicated above), it should be able to work all of the time.

2. There seems to be a very tight relationship between the cause and effect noted above.  In my testing today, no cause other than flushing the permalinks produced the problem.  While I understand that other plugins could possibly create rewrite rules, that did not produce the problem during today’s testing.

Rather than introduce possibly unrelated factors such as a different permalink structure or other plugins, I think it would be best to stay focused on what exactly is the interaction between the noted cause and effect.  How does flushing the rewrite rules cause a problem for Simple:Press?  How does Update WP Integration restore functionality?  Knowing that, I expect it would be possible to circumvent the problem entirely.

Did you find any significance to the similarity of the URLs per my post #13?  I was hoping that might lead in a helpful troubleshooting direction.

No. Rewrites are processed by breaking a requested url down into it’s components and  pattern matching against the rules.

Brad

I ask again if you have any other plugins active that may be creating rewrite rules. While this may be a red herring it IS something that has to be checked for and ruled out of the equation. It certainly can not be ignored.

Take a scenario where both SP and plugin X are creating rules. If all is correctly written and working as it should then updating WP Permalinks will flush the current rules, rebuild the WP rules and then add SP and X rules to the mix. This chain reaction is performed by code hooks placed in the WP core code. As far as I am aware – and as far as the history of SP to date strongly suggests – we perform this task correctly. If X does not perform this task correctly then there is a distinct possibility that the SP rule rebuild is not carried out at all – or the rules are even removed.

Updating the WP Integration panel may then perform the same task of flushing the rules which may then correct the issue. Curiously, this should only happen if the process discovers that the stored SP base permalink (as previously saved) is different from the permalink now being returned by WP core functions. As the rules DO appear to be getting rebuilt this suggests that this is the case.

So – while it may not have anything to do with another plugin it IS necessary to determine that to be the case.

I deactivated all other plugins, resulting in this environment:

Results were the same as previously tested, so I think we can safely rule out any other plugins having a bearing on this.

I tried Save Changes from the Permalink Settings page.  Same results as previously tested.

The previous “Month and name” structure was

I tried changing to a custom permalink structure: http://wilmington.crimeboard.org/2012/08/sample-post/.  When I clicked Save Changes, the text input area where I had entered the custom permalink was cleared and the radio button for “Default” was selected, resulting in the structure

.  This broke all of my existing links.  My forum links are structured this way: http://wilmington.crimeboard.org/forum/unit-182f.  I’d like to keep them that way.  Is there anything inherently problematic in such a structure?

In regard to installing the rewrite.rules script if I don’t intend to use it, my intent was not to change the structure for aesthetic reasons. My intent was to produce the intended functionality of the existing structure.  Once I can get the links to work properly I may have a look at the aesthetics of eliminating the “index.php” from the structure.  For now, I just want the links to work.

I changed the permalink structure back to the original “Month and name” format.  Unfortunately, I now have many 404 errors where I previously had content.  I didn’t realize that changing the permalink structure would produce an irreversible change.

So, before we get back to the original problem, can you suggest the best way for me to restore access to my content?

Brad

I reactivated plugins and rebuilt permalinks again.  The site is now working, so back to the original question thankfully.

Good news in most ways that no other plugins are effecting the rules. Bad news in that it leaves the problem unresolved. Whenb you change the WP permalinks it is always a good idea to also update the forum permalink structure just in case there is any conflict. And in your case we already know that refreshing from the WP settings panel doesn’t perform the full task so it is doubly important.

Personally I have no other ideas off hand why your rewrite rules are apparently being either trashed or ignored – it is not something we have encountered before. But I will spend some time after my lunch doing some searching to see if I can turn up something that might be useful.

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.

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…

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.

Which makes sense except for the fact that I should then be able to freely replicate this – and I can’t.
Can you remind me again what WP permalink structure you are using?

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

Actually it was my fault – a simple typo in the slug!
A bug report has been opened. Thanks for the detective work.

Great!  I’m glad we persevered to a successful conclusion.

same here!