4

Solved:

unfortunately, the solution is not a satisfying one. This morning, when trying @Wige's Suggestion, I found, to my suprise, that the Expected values WERE infact sent to the page as a GET query. Apparently, 1&1 (who I know have been making changes to their environment this last couple weeks), did something behind the scenes which magically fixed my problem, and now all of my previously unworking code is working as originally expected.

New info: The Apache version of the production server is 1.3.34 vs 2.2.21 on my localhost.

I'm having trouble figuring out why my RewriteRule is not working properly in production.

RewriteRule ^page/pretty-url/(.*)$ page.php?query=$1 [L]

In my local testing environment (localhost/mysite/page/pretty-url/{...}) it works fine, but on mysite.com/page/pretty-url/{...} it doesn't work properly. It loads page.php as expected but apparently the ?query=$1 piece is ignored ($_GET is empty)

I imagine that the problem is somehow related to the server configuration. I'm on a 1&1 shared hosting account with no httpd.conf access.

What that RewriteRule does (or should do):

I want urls like

*example.com/page/pretty-url/{{info_for_dynamic_content}}

to be rewritten to

*/page.php?query={{info_for_dynamic_content}}

So I can access info_for_dynamic_content

within php as $_GET['query']

The full .htaccess file for reference:

AddHandler x-mapp-php6 .php

DirectoryIndex index.php
ErrorDocument 404 /index.php 

Options +FollowSymLinks

# per @Jacques Chester's suggestion
Options -MultiViews

RewriteEngine on
RewriteBase /

# the rule in question
RewriteRule ^page/pretty-url/(.*)$ page.php?query=$1 [L]

RewriteCond %{REQUEST_FILENAME}\.php -f 
RewriteRule ^(.*)$ $1.php

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php !-f 
RewriteRule (.*) /index.php [L]
Community
  • 1
  • 1
Zach Lysobey
  • 14,959
  • 20
  • 95
  • 149
  • What version of Apache is running on your localhost vs 1&1? – Jason McCreary Dec 18 '12 at 03:37
  • 1
    If it works in your localhost the problem can't be the mod-rewrite conditions or rules because **they work**, according to your answer. It seems you have it all resolved. ¿Then, what's the question about, finding why your rules don't work in your site? If so, I guess you should just ask that question specifically, making clear it has nothing to do with your rules because they work fine. I think this is a question for `webmasters`. That's only my opinion, but I hope is useful in any way. – PDR Dec 18 '12 at 12:24
  • You make a good point. Before adding the bounty I almost rewrote this to be "what could prevent a RewriteRule which works on one server from working on another." - or something more generalized like that. I don't think I have the rep to migrate a question - but I think you may be right about that too. – Zach Lysobey Dec 18 '12 at 14:31
  • @JasonMcCreary I'll check that out a bit later. I spent a couple minutes looking (in `phpinfo()`), but wasn't easily able to determine the version. – Zach Lysobey Dec 18 '12 at 14:34
  • `phpinfo()` lists it at the very top or very bottom. Can't remember. It *should* be on there. – Jason McCreary Dec 18 '12 at 14:44
  • Is the `apache` version within this string?: `Linux infong 2.4 #1 SMP Fri May 18 17:32:59 UTC 2012 i686 GNU/Linux` (the production server) – Zach Lysobey Dec 18 '12 at 14:56
  • To be clear, it sounds like the redirection is working, you are being taken to page.php, and it is only the $_GET that is not working as expected? To verify, if you change the destination to another script, do you get taken to that other script? – Wige Dec 18 '12 at 20:02
  • @Wige spot on. Changing the destination does indeed take you to the other script, yet still no `$_GET` values exposed :-( – Zach Lysobey Dec 18 '12 at 23:19
  • The apache version of the production server is "1.3.34" vs "2.2.21" on my localhost. – Zach Lysobey Dec 18 '12 at 23:56

3 Answers3

1

Most likely, your host is storing the variables somewhere else. I would add a call to phpinfo(); into your script and go through the environment variables there to see if you can find the values that should have been in get.

Wige
  • 3,788
  • 8
  • 37
  • 58
  • Here, have some points, lol. 1&1 apparently solved my problem, but they sure as heck ain't gettin my bounty. I'm voting to close my question as too localized. – Zach Lysobey Dec 20 '12 at 15:53
0

Seems to be connected to 1&1's hosting environment.

See this question, in particular, this answer.

Basically it appears that 1&1 enable "MultiViews". By adding

Options -MultiViews

You disable that setting for your website and according to various reports, this resolves the issue.

Community
  • 1
  • 1
Jacques Chester
  • 628
  • 1
  • 4
  • 13
  • I tried this quickly last night, and it didn't seem to fix my issue... but I only had a few minutes to play with it, and won't be able to attack it until later today. – Zach Lysobey Dec 18 '12 at 14:32
0

I struggled with RewriteRule issues on a 1&1 / 1and1 / IONOS shared server for WEEKS and eventually I found the perfect setup for a 1 and 1 shared server, start your .htaccess file like this

Options -MultiViews
Options +FollowSymlinks
RewriteEngine On
RewriteBase /

I hope this helps someone as 1&1 are useless when it comes to htaccess support

Karl Humphries
  • 328
  • 1
  • 4
  • 15