Wrong URL Rewriting Rule?

[lfrantzen]

Hi,

I enabled enabled URL writing in the blog configuration by setting it to:

Code: Select all

Use Apache mod_rewrite

After having done that, the serendipity.css was not found anymore, the rest worked fine. I checked the rewriting rules which have been added to .htaccess. The responsible rule seems to be:

Code: Select all

RewriteRule ^(serendipity\.css|serendipity_admin\.css)$ index.php?url=/$1 [L,QSA]

which does not seem to work. After removing the '$':

Code: Select all

RewriteRule ^(serendipity\.css|serendipity_admin\.css) index.php?url=/$1 [L,QSA]

it does work again.

I do not know a lot about these rules, so I am not really sure if the rule is wrong or if I am doing something wrong?

Cheers,
Lars

P.S. My motivation for this was a problem with the "Show links to services like Facebook, ..." plugin. It did not work correctly with Facebook, somehow Facebook does not like the links it transmits. With URL rewriting Facebook is happy again.

[garvinhicking]

Hi!

Are you using 1&1 by any chance? Their servers choke on "serendpity.css" and their server does not honor the rewrite rules. This was discussed in this thread:

http://board.s9y.org/viewtopic.php?f=4& ... ss+rewrite

And sadly it seems 1&1 did not respond at all to the trouble at hand. It is something in their server configuration, because the rerwite rule is properly set.

Regards,
Garvin

[lfrantzen]

Hi Garvin,

yes, I am am using 1&1...Sorry for not having found the thread you mention, it is all in there...
Well, so I did not find a bug in the rewriting rules, but a hack to get it running under a 1&1 setup
Well, good enough for now...

I will add a posting at the thread you mentioned, so maybe this does also solve the issues from Flo.

Cheers, and thanks again!
Lars

[schimanke]

Thanks for the solution, Lars!!!
Removing the "$" did indeed solve my issues.

[lfrantzen]

Hi Florian,

good to hear that this solved the issue also for you!

One last remark: after turning URL rewriting on I had to correct some links of the upper navigation buttons. Seems you have the same issue ("About" and "Projekte" for instance now just lead to the blog). I assume you use static pages for that, so if you edit those and adapt the Metadata -> Permalink by removing the index.php? part, and also adapting the link you set for the buttons in the same way, everything should be fine again.

Cheers,
Lars

[danieler]

Hi,

My problem is that a copy&paste onto Facebook of a post URL gets ALWAYS on top of my blog and not to the post. I guess this is the thread fixing the issue, but it is not clear to me where the following code should be:
RewriteRule ^(serendipity\.css|serendipity_admin\.css)$ index.php?url=/$1 [L,QSA]

The .htaccess file in the blog directory hasn't it. I can see no change adding it and restarting apache. The same issue occurs if I try to write this line into the default apache configuration file.

Any help would be appreciated.

[garvinhicking]

Hi!

What's your URL?

Regards,
Garvin

[lfrantzen]

Hi,

another point: have you enabled URL rewriting? You do this via the Serendipity administration page, go to
Administration --> Configuration --> Appearance and Options --> URL Rewriting

For 1&1 you can set it to "Use Apache mod_rewrite".

Having done so Serendipity adds a whole bunch of rewriting rules to the .htaccess file of your blog directory. There you will also find the rule you are looking for, which you have to change by removing the '$'.

Cheers,
Lars

[yellowled]

For 1&1 you can set it to "Use Apache mod_rewrite".

Lars, could you please check if the following still works for you?

In the .htaccess, right before the rule for the css files, insert

Code: Select all

RewriteCond %{REQUEST_FILENAME} !-f 

see if everything still works well and report back here? Thanks.

(This will help us make the rewrite rules compatible to more server setups, if it works.)

YL

[lfrantzen]

Hi,

I added the line, so it looks like this now in my .htaccess:

Code: Select all

...
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule ^(serendipity\.css|serendipity_admin\.css) index.php?url=/$1 [L,QSA]
...

This breaks again the thing, the stylesheet is not found anymore. If I put instead the line at the beginning of the rewriting rules it looks like this:

Code: Select all

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f 
...
RewriteRule ^(serendipity\.css|serendipity_admin\.css) index.php?url=/$1 [L,QSA]
...

This works, so the stylesheet is found again. But probably this does not help?

Cheers,
Lars

[yellowled]

This works, so the stylesheet is found again. But probably this does not help?

Not sure. We're gonna have to wait for Garvin to read this, I was merely passing this along.

YL

[garvinhicking]

Hi!

Seems like the only option then will be to revert to the old behaviour, and tell 1&1 hosted people in the notes somehow that they need to remove the '$' if they have problems. Because the new behavioir breaks on more installations than on the old ones, due to the MultiViews options it seems. But I can't figure out a way to remove MultiViews in .htacess without generating 500 errors on many hosts that don't allow AllowOverwrite.

Or maybe I can see if a new rewrite option can bre created for it.

Regards,
Garvin

[lfrantzen]

Hi,

I see. Making an extra "Apache mod_rewrite for 1und1 hosts" option in the config is probably a bit over the top.

Or maybe I can see if a new rewrite option can bre created for it.

If there is anything else I can try let me know.

Cheers,
Lars

[yellowled]

I see. Making an extra "Apache mod_rewrite for 1und1 hosts" option in the config is probably a bit over the top.

We could ship the core with a file called alt.htacess so people would only have to delete the old file and remove the prefix.

YL

[garvinhicking]

Hi!

I committed a new "rewrite2" option for URL Rewriting...sadly it's the only method I can think of ::(

It all seems to stem from the apache "MultiViews" option, which is usually enabled. If it's enabled, apache will route a call to serendipity.css to serendipity.css.php automatically, but will try to do that a second time due to the .htaccess method which leads to a missing file. When the "$" is there in the rewrite rule, this will not happen.

The reverse applies to hosts that have MultiViews disabled (1&1 seems to do that) - it will NOT route to serendipity.css.php, and somehow it chokes on the rewrite rule if a $ is there.

I don't really understand the full workings of this, only that either method does not properly work for the other config...

Regards,
Garvin