Fixing a trailing slash problem in WordPress with Apache and Multisite Language Switch plugin

It has taken me a while to find this bug.

I was getting a “Too many redirect” problem in Apache, and went crazy to check where could be the origin of the problem. I got this error message from time to time, and this is very weird. Then there was a problem with the language multisite switcher, a great plugin that I highly recommend:

Initially I thought it had to do with the “www” or canonical url, so I checked the DNS and so on. Then I thought it could be related to the WordPress multisite, since it has quite a complex url structure.

But finally I found the solution. The Multisite Language Switcher was generating urls of the type (for exmample, for the Spanish version), and that causes a redirection error because it has to have the trailing slash “/” at the end, so the correct one would be

I went to the function that was generating the urls, the_msls (), and that led me to the file MslsOutput.php. In line 61 I added the slash:

$url = $mydata->get_permalink( $language )."/";

And now it works nicely!!!

I have to find out if there is a configuration in WordPress or Apache that automatically adds the “/” always. This was a random error, but it was provoking a toxic behaviour in Apache that is not acceptable.

Update: Apache documentation refers to this issue here:

Trailing Slash Problem
Every webmaster can sing a song about the problem of the trailing slash on URLs referencing directories. If they are missing, the server dumps an error, because if you say /~quux/foo instead of /~quux/foo/ then the server searches for a file named foo. And because this file is a directory it complains. Actually it tries to fix it itself in most of the cases, but sometimes this mechanism need to be emulated by you. For instance after you have done a lot of complicated URL rewritings to CGI scripts etc.

The solution to this subtle problem is to let the server add the trailing slash automatically. To do this correctly we have to use an external redirect, so the browser correctly requests subsequent images etc. If we only did a internal rewrite, this would only work for the directory page, but would go wrong when any images are included into this page with relative URLs, because the browser would request an in-lined object. For instance, a request for image.gif in /~quux/foo/index.html would become /~quux/image.gif without the external redirect!

So, to do this trick we write:

RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo$ foo/ [R]
The crazy and lazy can even do the following in the top-level .htaccess file of their homedir. But notice that this creates some processing overhead.

RewriteEngine on
RewriteBase /~quux/
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$ $1/ [R]