Having a custom post slug that clashes with an existing directory

Question

I'm currently transitioning a website from their existing CMS to WordPress.

I have a custom post type of 'Episodes', with a URL of myurl.com/episodes/

There is also an existing directory at myurl.com/episodes/ which needs to remain in place for historical reasons - it contains a large number of images and static HTML files which will still need to resolve.

At the moment, because the /episodes/ directory exists, WordPress won't go anywhere near it, so the pages under my custom post type don't load.

This happens because WordPress's default .htaccess has two rules, which state that any existing file or existing directory should be not be handled by WordPress:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

But these rules stops /episodes/ from being handled by WordPress at all. I want WordPress to handle /episodes/ by default, and only not do so if the file in question exists.

But having the first line on its own - i.e. pass everything to WordPress unless the file in question exists - doesn't seem to do the trick.

Is there a way I can re-write these rewrite rules so that WordPress will still handle the request if the directory exists, but not if the file exists?

Answer 1

Not using WordPress. With that directory in place, your web server doesn't even touch WordPress when it handles the request.

I would:

• Move as much of your stuff as possible away from using that folder
• Rename the rewrite rule so that it's not just /episodes/ so that it doesn't clash

You could try moving the folder and adding redirects, but at that level you're at the Apache/Nginx level, not the WordPress level

Answer 2

broad lines of what you need to do

1. change the .htaccess to let wordpress have priority over the directory
2. handle wordpress url parsing

You have two good options for handling the parsing

• hook on the init action and check if the url is of a file that exists in the directory
• do the file check in your theme's 404.php file before outputting any html.

(step skipped: detecting the file type and sending it with the proper encoding via php functions)

I think that the 404 approach is more robust as it gives the lowest priority to those historical files. You can find the hook that is called to load the theme's 404 file and use it if you prefer to leave the functionality out of the presentation oriented code.

The biggest problem you might face is performance as for each small file you will have to load wordpress, connect to the DB etc. It might not be a huge problem if there is no traffic going to those files, but it is a risk.

Therefor what you should consider is refining the .htaccess to keep the current algorithm of files first when the url ends with .png .jpg .gif .pdf and only if not go pass control to wordpress.