Use .htaccess to load files from another folder - .htaccess

I have a good reason to do this. I feel this is the most cost effective way of providing an update.
This is my current url structure
/ <-- Contains Website
/cart
/cms
Boss wants the client to have an option to forego the website and instead load the cart in place of the website. The system is fairly old, the website and cart are completely different systems. We host a lot of websites from this single system. Configuring 2 systems for 2 different websites types will involve too much maintenence.
The least work solution would be to rewrite the /cart into /. I came up with the following.
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/cart/
RewriteCond %{REQUEST_URI} !^/cms/
RewriteRule ^(.*)$ cart/$1
This returns a server error. Adding /cart/$1 on the final line does work. I need this to work when the system isn't installed in the root directory. Does anyone know how to fix this?

You can use this rule:
RewriteEngine On
# Determine the RewriteBase automatically
RewriteCond %{REQUEST_URI}::$1 ^(.*?/)(.*)::\2$
RewriteRule ^(.*)$ - [E=BASE:%1]
RewriteCond %{REQUEST_URI} !/(cart|cms)/ [NC]
RewriteRule ^(.*)$ %{ENV:BASE}cart/$1 [L]

Related

RewriteRule does not match if folder name set to "myfolder/"

Since we migrated to a new server, some of our pages are broken (404). Reason is we have 2 broken rewrite rules.
What's really strange is that they work if I change folder's name.
For example this work:
RewriteRule ^anything/([a-zA-Z0-9-]+)/$ page.php?var=$1 [L]
This doesn't:
RewriteRule ^myfolder/([a-zA-Z0-9-]+)/$ page.php?var=$1 [L]
I can't even find a trick to make 301 redirects, because my original "myfolder/" virtual folder never matches.
Any ideas what's going on? I was thinking it could be a rule override or something like that (as it's hosted on a multidom solution), but i don't have such rules in my main site at the root. It drives me crazy.
Thx!
In practice you probably want to do 2 things. Disable multiviews and also bypass rules if the request is a real directory.
Options -MultiViews #turn off automatic URI matching, can cause weirdness
RewriteEngine on
#stop here if the request is a real file or directory
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^ - [L]
RewriteRule ^myfolder/([a-zA-Z0-9-]+)/?$ /page.php?var=$1 [L]

htaccess on one.com webspace

Recently I moved my websites to the hoster one.com. They have setup an automated mechanism (I dunno what they use to achieve that) to rewrite any first-level folder on the webspace to a subdomain.
I.e. the folder http://example.com/folder1/ will be also available as http://folder1.example.com/
Now, I have a site, that is using quite a lot javascript to include pages from a hardcoded, static source. Due to the SOP the scripts are working depending on which hardcoded reference they use.
So, to make sure that everybody gets a working version of the website, i wanted to redirect the direct folder access to the subdomain as well.
My htaccess for this - which is working localy and on various htaccess-testers out there - seems to be not working with one.com:
RewriteEngine On
#Rewrite Access to folder1-folder to subdomain.
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteCond %{REQUEST_URI} ^/folder1.*?$ [NC]
RewriteRule .* http://folder1.example.com/ [R=301,L]
Since I don't know the exact mechanism one.com is using to achieve the mentioned behaviour it might just be a conflict with my rules.
Support says, that all the used commands are fully supported, and therefore wasn't be able to tell what's going wrong...
Does anybody have encountered something similiar and has a hint for me?
just fiured out the solution:
RewriteEngine On #does not work
vs.
RewriteEngine on #does work
You need to check that the actual request was made for /folder/ and not the URI (which can internally be rewritten). Try:
#Rewrite Access to folder1-folder to subdomain.
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /+folder1/ [NC]
RewriteRule ^folder1/(.*)$ http://folder1.example.com/$1 [R=301,L]

Htaccess rule to make urls like this ?page=1 look like /page/1 in Codeigniter

This is how my urls currently look:
http://mysite.com/?page=1
How can I make this work?:
http://mysite.com/page/1
There is a post on StackOverflow that asks the same question. But the accepted solution isn't working for me. Because I am using Codeigniter and my page results in a 404 perhaps because since the url pattern of a CI site is:
domain/controller/method
The system is assuming that I am requesting a controller called "page" and a method called "1" both of which of course doesn't exist. Or maybye it's due to a conflict with the other code in my htaccess file (which I downloaded from the CI wiki, it gets rid of index.php and does a few security things). Here is my entire htaccess file:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#Removes access to the system folder by users. Additionally this will allow you to create a System.php controller, 'system' can be replaced if you have renamed your system folder.
RewriteCond %{REQUEST_URI} ^system.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
#When your application folder isn't in the system folder. This snippet prevents user access to the application folder. Rename 'application' to your applications folder name.
RewriteCond %{REQUEST_URI} ^application.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
#Checks to see if the user is attempting to access a valid file, such as an image or css document, if this isn't true it sends the request to index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]
#Pretty urls for pagination links
RewriteRule (.*) index.php?page=$1
</IfModule>
The non indented bit is the solution I got from that other SO question that isn't working for me.
Any solutions to this CI pagination issue?
UPDATE
Ok, read some of the docs and now I have this working:
http://mysite.com/home/index/2
What would be the htaccess rule to turn that into?:
http://mysite.com/page/2
You should make this configuration at /application/config/routes.php (and let the .htaccess just for hide the index.php as you are already doing).
$route['page/(:any)'] = 'home/index/$1';
Or better, like #zaherg remembered (ensures that only numbers could by matched):
$route['page/(:num)'] = 'home/index/$1';
This way all the requests to http://mysite.com/page/2 will be treated internally as http://mysite.com/home/index/2 and so forth.
I suggest you take a look at CodeIgniter User Guide - URI Routing and CodeIgniter User Guide - Tutorial − Introduction.
Good luck.
RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]
from CodeIgniter docs
That will handle removing the index.php, but what happens after that depends how CodeIgniter's query string handling is set up: it can be configured to use a query string rather than a path. See the link for more details.

Ignore magento admin directory in GeoIP Htaccess Rewrite

I've got a magento install that is using the htaccess mod_geoip to redirect people from specific countries to other store fronts. It's working like a charm (after I got it to ignore javascript and skin files), but I'm going to be having someone from Australia input some orders into the backend of magento.
The issue is that they can't access the main backend at store/index.php/admin (they are rewritten to austore/index.php/admin) and when they go to put orders in, they are missing some integral components of the order process which I think is due to the url being rewritten to austore/index.php/admin. Wondering if there is a way that if the request uri is store/index.php/admin that they won't get rewritten. My code is below from my htaccess:
RewriteRule ^(skin|js) - [L,NC]
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(AQ|AU|MY|BV|BN|BN|MM|KH|CN|CX|CC|CK|GQ|FJ|PF|GU|GW|HM|HK|ID|KI|KR|KP|KR|LA|MO|MY|MH|FM|MM|NR|NC|PG|NZ|NU|NF|PG|CN|PH|PN|WS|SG|SB|KR|LK|BN|TW|TW|AU|TH|TL|TK|TO|TV|VU|VN|VN|WF)$
RewriteCond %{REQUEST_URI} ^/store(/.*)$ [NC]
RewriteRule ^ /austore%1 [L,R]
Thanks for the help!
Taken from this, http://www.sonassi.com/knowledge-base/magento-kb/secure-your-magento-admin/ you can use the same rewrite logic in what you want to do.
RewriteCond %{REQUEST_URI} !^/store/(index.php/)?(admin|custom_extensions_go_here)/ [NC]
RewriteCond %{REQUEST_URI} !^/store/downloader/ [NC]
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(AQ|AU|MY|BV|BN|BN|MM|KH|CN|CX|CC|CK|GQ|FJ|PF|GU|GW|HM|HK|ID|KI|KR|KP|KR|LA|MO|MY|MH|FM|MM|NR|NC|PG|NZ|NU|NF|PG|CN|PH|PN|WS|SG|SB|KR|LK|BN|TW|TW|AU|TH|TL|TK|TO|TV|VU|VN|VN|WF)$
RewriteCond %{REQUEST_URI} ^/store(/.*)$ [NC]
RewriteRule ^ /austore%1 [L,R]
Just bear in mind, doing this through .htaccess could potentially cause some bizarre issues in the long run with 3rd party extensions, that have custom admin routes (that are not prefixed with /admin) break. So just be mindful of this.
I would advocate the use of a Magento extension (PHP based), mod_geoip store switcher - as then you can make it apply only to the frontend area of the Magento store (to prevent the potential errors I've described above)

.htaccess subdomain to folder

I've recently made some minor changes to my website's folder structure, and now one of my rewriterules seems broken.
in the past I had a /mydomain.com/ folder in public_html in which a wiki was set up. In the same folder were some folders that I used for subdomain access, like members and files.
The old setup:
#www to main website
RewriteCond %{HTTP_HOST} ^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/$1 [L]
#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*).mydomain.com$
RewriteCond %{HTTP_HOST} !^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/%1/$1 [L]
Fairly easy, and when I typed in files.mydomain.com/myfile.zip it worked without any problems.
Recently I installed several languages of my wiki (which is in fact irrelevant to the question, but just to elaborate the situation) and I made the following rule:
#to the right language folder (www = en)
RewriteCond %{HTTP_HOST} ^(www|nl|es).mydomain.com$
RewriteRule ^(.*)$ mydomain.com/%1/$1 [L]
#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*).mydomain.com$
RewriteCond %{HTTP_HOST} !^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/misc/%1/$1 [L]
Obviously, the different language wikis are set up in mydomain.com/www/, mydomain.com/es/, etc. This works perfectly fine.
The problem lies in the second part, the subfolders. In the same mydomain.com/ folder I created a misc/ folder to store all the misc stuff (including the subdomain folders). I figured just adding the /misc/ in the path (like I added the language folder name in the first rule) would make it work.. but it gives me a 500 error.
Neither the old setup nor the new setup have any .htaccess lines in any folders that could conflict with the second rule.
Can anyone spot the error, or tell me how to systematically check this setup for bugs?
The easiest way to prevent the redirection loop I believe is happening is to just check if you've already rewritten the URL to where you intended it to go. We can do this a few different ways; if you know that the file will exist once you've rewritten it, you can condition on %{REQUEST_FILENAME} !-f, for instance.
In your case, since you're rewriting everything to a common folder within your /public_html directory, we can just check if that's already been done:
#to the right language folder (www = en)
RewriteCond %{HTTP_HOST} ^(www|nl|es)\.example\.com$
RewriteCond %{REQUEST_URI} !^/example\.com
RewriteRule ^(.*)$ example.com/%1/$1 [L]
#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*)\.example\.com$
RewriteCond %{HTTP_HOST} !^www\.example\.com$
RewriteCond %{REQUEST_URI} !^/example\.com
RewriteRule ^(.*)$ example.com/misc/%1/$1 [L]
Admittedly, I'm not sure why you're experiencing issues now, but weren't before. I ran your original rule set on my test server and ended up with an internal server error due to too many internal redirections, so there must be differences in our setup. In any case though, hopefully this will get things working for you.

Resources