Just tried editing the release notes blog post to test, and confirmed that this rewrites the rules. Updating the WPS Permalinks on Installation page puts them back. So certainly next week I'll sort that out.

It's a a bit of a mind f*%k really......!!!!

I've switched off the permalinks following reports of the occasional page not found. I'm sure it can be sorted out, but better to switch them off over the weekend as I won't be around to reply to forum posts. Sorry.

Ok, I'm trying an even more straight forward way, adding rewrite rules with the generate_rewrite_rules filter.

I've noticed a few -1 and -2 being appended to categories and posts that I wouldn't expect to see. Maybe they should be there, maybe not, not sure, going to try and investigate before putting next release candidate up for download.

v12.06.23 RC1 is available for download.

 ATTENTION! NERDGASM ALERT!! 

The following, once the defaults work (ahem) would all go on behind the scenes. Consider yourself warned. If you're still interested, read on.... 

This uses a slightly different way to add rewrite rules, probably best so far. It uses the generate_rewrite_rules filter to add rules dynamically, so they are effectively added for each page load. A flush is not performed, so performance is not hit.

The added rules are those set up on the Installation page, so you can tailor them to your site if, for any reason, the suggested values don't tie in with your site. But they should work as suggested.

What is really good, is that you can check and see that the rewrite rules have been added. To do this, on Symposium->Settings switch on debug mode (remember this adds a lot of what appear as nonsense to your site visitors). Then, at the top of the page on your site, is a link to "Show rewrite rules" which will display the rules that WordPress is trying to interpret - they are analysed in the order they are listed. WP Symposium rewrite rules for the forum should appear at or near the top, so that they get considered first.

This will let you see if another plugin is getting their rewrite rules in first.

Attached here are images showing the installation page setup, the link shown in debug mode, the output from rewrite rules if you click on the link. WP Symposium entries are highlighted.

In the rewrite rules shown, you can test the redirect by copying the target after the => and replacing $matches[1]  and $matches[2] with one of your forum categories and topic titles. Remember to make them match what the stub would be with spaces replaced with a hypen, and only the letters A-Z, a-z and 0-9 included. 

For example, using WP Symposium website, from:

discuss/([^/]+)/([^/]+)/? => index.php?pagename=Discuss&stub=$matches[1]/$matches[2]

I take the target after => and replace with a category and a forum topic title:

index.php?pagename=Discuss&stub=forum-plugin/wysiwyg-toolbar-broken

then add that to my site root: 

http://www.wpsymposium.com/index.php?pagename=Discuss&stub=forum-plugin/wysiwyg-toolbar-broken

and entering that into the browser, I get to see the topic on the forum. Try the above URL and you'll see it in action.

This will let you test that the target of the rewrite rules work on your site.  

The way the rewrite rule gets the category and topic title from the URL entered is from the part of the rule before => which above is

discuss/([^/]+)/([^/]+)/?

Translated this means a URL of the site name followed by discuss, a slash, anything other than a slash (ie. the category), a slash and then anything other than a slash (the topic) with maybe a slash at the end. So

http://www.wpsymposium.com/discuss/releases/v120616/

would match because, after wpsymposium.com and a slash, the word discuss is there, then a slash, then the category (releases), another slash, the topic title (v120616) and then a slash at the end.

Note that WordPress will assume the site address (URL) as the "base" of the rule.

You can play around with what you put in the Installation page, but it should tie in with the structure of your site, and ideally what is suggested on the Installation page.

This will let you test the complete rule and change it if you want to.

Still reading? Well I sympathise.... congratulations or commiserations, not sure which.  

Ok, so in 12.06.23 RC4 (available to download) I thought I share with you member permalinks. Notice that you can go to http://www.wpsymposium.com/member/simongoodchild to see my page.

How it works (using the above example):

• member is entered into the Installation->Permalinks (note that this is different to /profile which is the profile page, member just works better)


• simongoodchild is the same as my tag (whether in use of not). It's constructed on the displayname without spaces. I strongly urge you to force unique display names on the Symposium->Profile Plus admin page. I would use user login names, but they can be naff. To be blunt. And the user cannot change them, and may want them not to be displayed.

Are "Groups" permalinks next?

Updating is such a monster task for me that I might just wait for group permalinks if they are not too far off...

Thanks for the feedback @EllsWeb, I appreciate it, I think this way (v12.06.23 RC3+) is the way to go. It uses the commonly used method by many (if not all) plugins to deal with rewrites. Seems very stable on WPS.

Groups should have a unique permalink like:

http://www.example.com/group/simons-test-group

@TR4NSeND, I don't want to run before walking, but it's looking good so far I think. However, in terms of being in an official release, I think it may remain BETA for a while until it's thoroughly tested. So the option will be there, but not core or a reason to upgrade for necessarily (unless there is something else in the release upgrading for).

Not sure, I'll admit I've not thoroughly tested on WPMS, will have a go and see what's going on and why. Thanks for letting me know. Sure it's just a path thing.

Thx very much, as ever very helpful feedback.

Thanks EllsWeb, I'm going to try and find some time today to look at the WPMS profile redirect. The /$matches[1] and $matches[1] is actually correct, as the forum script will be looking for / to split the category and topic, it's just that /$matches[1] is used if no category is used in the rewrite.

Hi @ElssWeb, just to let you know I could replicate the problem locally, and fix, included in tomorrow's v12.06.23 release. Attached are a couple of images to show it working in multisite.