Up until today, I had been happily using a customized .htaccess file to manage all my rewrite rules. I placed them above the WordPress-generated rules to ensure that they took precedence over WordPress’ default rules. Things worked perfectly this way (so far as I’ve tested), but I decided today that if I was going to deploy this plugin on multiple WordPress installs, it would probably be in my best interests to integrate my customized rewrite rules into WordPress’ inner workings. As I had already done a few things with WordPress’ internal rewrite rules, this was not all that difficult.

In order for a new rewrite rule to be recognized by WordPress, it needs to be added to the $wp_rewrite object’s rules array. This array contains all of the default rewrite rules that WordPress generates on it’s own. Adding custom rules is simple 3 step process:

1. Add a filter to intercept the rewrite rules array: add_filter('rewrite_rules_array', 'custom_rewrite_rules')
• rewrite_rules_array allows you to manipulate (a.k.a filter) the rewrite rules array whenever the permalink structure is updated
• custom_rewrite_rules is the name of my function that adds my rewrite rules to the array
2. In the function, custom_rewrite_rules(), I add a line like the following for each rule I want to add:
• $custom_rules['(.*)/([A-Za-z0-9-]+)\.html$']=$wp_rewrite->index."?name=\$matches[2]"
• The first half of the rule states what it should look for (using regular expressions), while the second half defines what WordPress should do when a matching request is encountered
• Each group of characters surrounded by parenthesis can be backreferenced and used in the new request (right side of expression). So $matches[2] will reference whatever matched ([A-Za-z0-9-]+) (which in this case would be the name of a post)
3. Once I’ve added my rules, I return the modified $rules array and let it continue on its way:

   return ($custom_rules + $rules)

   This adds merges both my $custom_rules array and the $rules array that was passed to the function by the filter and returns them as one array.

And that’s really all there is to it. One thing to keep in mind is the placement of your rules, due to way in which WordPress gives precedence to one rewrite rule over another. In my case, I found that adding my custom rules to the top of the list made sure they were evaluated first (as it appears that WordPress evaluates the rules in a top-down fashion).

Ah, but it couldn’t just work without breaking something else in the process now could it? Unfortunately, in this case, it appeared that my RSS feeds were no longer accessible. I wasn’t quite sure why they weren’t accessible (still not so sure actually), but my custom rules were obviously causing a conflict of some kind. I isolated each of my custom rules until the RSS feed links worked once again. Then, once I got them working, I carefully added by custom rewrite rules back to the array one-by-one. Oddly enough, after I had added back all of my custom rules, the RSS feeds were still working. I’m guessing that it was probably more a caching issue as opposed to a conflict with the custom rewrite rules. While I did get the default RSS feed rules working again, I have yet been able to set up a custom rule that redirects WordPress’ default feeds to my feedburner feed. I’m still not quite sure what the problem is, so I’ll just have to keep working on that.

I am happy to report that everything else seems to be working great. It’s nice to have sections in WordPress, and I finally feel that it’s a viable option to use as a CMS. My next step is to get the plugin cleaned up so that others can download it and use the new functionality. Once I do that, my next step will be to greatly improve the administrative management of sections and posts. I think it would be really nice to be able to perform mass edits on the sections/posts, so that’s what I’m going to build into the options menu.