RewriteRule rewriting in another directory - apache

my problem is that in root directory I have this rewrite rule in my .htaccess file
RewriteRule main-page /index.php
and it works when I go to the root directory in browser.
But when I visit page.com/panel/main-page it also redirects to the index.php in root directory.

You need to be more precise in your matching pattern. Your current matching pattern main-page will match any path in this list of examples, which is not what you actually want:
/main-page
/folder/main-page
/folder/main-page/whatever
/some-other-main-page
/some-other-main-page-in-green
Instead you want to be precise and only match the literal string "main-page" as absolute path and nothing else:
RewriteEngine on
RewriteRule ^/?main-page$ /index.php [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).

Good question.
That line is correct:
RewriteRule main-page /index.php
But in that case, we've got if URL contains main-page it always be redirected to the /index.php.
In pure apache2 configuration, below lines always do what you want:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^main-page /index.php
RewriteRule ^(*.)/main-page $1/index.php

Related

301 url redirect .htaccess in Apache server

How can i direct the search engines from one domain to other domain for better SEO optimization. I want to make 301 redirect from domain.uk to language directory of another domain domain.com/gr
How can to change last line code? Thanks!
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example-old\.uk$ [NC]
RewriteRule ^(.*)$ http://example-new.com/gr [R=301,L]
RewriteCond %{HTTP_HOST} ^example-old\.uk$ [NC]
RewriteRule ^(.*)$ http://example-new.com/gr [R=301,L]
You've not actually stated the problem you are having. However, if you want to redirect to the same URL-path, but with a /gr/ path segment prefix (language code) then you are missing a backreference to the captured URL path (otherwise there's no reason to have the capturing group in the RewriteRule pattern to begin with).
For example:
RewriteRule (.*) http://example-new.com/gr/$1 [R=301,L]
The $1 backreference contains the value captured by the preceding (.*) pattern.
I assume that is what you are looking for:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example-old\.uk$ [NC]
RewriteRule ^ http://example-new.com/gr%{REQUEST_URI} [R=301,END]
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).

Remove trailing forward slash and question mark

Quick summary, I have implemented the following .htaccess file which successfully redirects http:// and any www. searches to https://
My issue - After redirectrule has been applied it then leaves a trailing //? so for example: http://www.example.com becomes https://example.com//?
Another example of another page: http://www.example.com/test becomes https://example.com//test?
So to clarify further. I am happy with the http to https redirect however I only need one final trailing slash and nothing else to my URL, any help and advice would be great as I cannot for the life of me find any other example like this.
Required - http://www.example.com to become https://example.com/
Here is my .htaccess code...
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^(.*)$ https://settlerslodge.co.uk/$1 [R,L]
Use below rewrite rule and test.
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/?(.+)/?$ https://%{HTTP_HOST}/$1 [L,R]
This would be a clean setup:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.+)/?$ https://example.com/$1 [R=301,QSD,END]
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).

.htaccess rewrite rule change url automatic

I'm new to htaccess and I need some help
how do I change the url automatically from from .htaccses
if I write url like:
url/index.php/pages
url will change automatic to:
url/pages
Thanks in advance.
This appears to be pretty straight forward, you would have found hundreds of existing answers and examples alone here on StackOberflow...
RewriteEngine on
RewriteRule ^/?index\.php/pages/?$ /pages [R=301]
This assumes that in your question, in the given path url/index.php/pages the "url" refers to a prefix of protocol scheme and host name, so would usually be written as https://example.com/index.php/pages...
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
I dare say however that you also need the corresponding internal rewrite to again be able to process such redirected requests. Adding that the example looks like this:
RewriteEngine on
RewriteRule ^/?index\.php/pages/?$ /pages [R=301]
RewriteRule ^/?pages/?$ /index.php/pages [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This get more complex if your question does not only target the single, specific path /index.php/pages but actually any "pages" to follow in the path after the leading /index.php/. For that you'd need something a bit more complex:
RewriteEngine on
RewriteRule ^/?index\.php/(.*)$ /$1 [R=301]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index\.php/
RewriteRule ^/?(.*)$ /index.php/$1 [END]
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).

Can you help me removing index.php in Rewrite Rule?

Here's my code in .htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([0-9]+)/$ index.index?pm=$1 [L]
It doesnt work using this link:
http://localhost/display/1001
but it does when you add ? before the number
http://localhost/display/?1001
Your question is unclear, you did not provide enough information about your actual situation and what you are trying to achieve. So we have to do a bit of guess work here and hope that this is what you are looking for:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?display/(\d+)/?$ /index.php?pm=$1 [END,QSA]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).

accessing same file with different name using htaccess

I am clarify my problem into steps and this help to understand what I am trying to do.
I am trying to build url shotner using htaccess, let say https://example.com/index.php/A43DS4 where index.php is the main file which can be excess as https://example.com/index/A43DS4 by writing this htaccess code:
RewriteEngine On
# by writing the below rule: we can excess the index.php page with:http://example.com/url
# its convert index.php to url/image/invite
# its remove .php extention
RewriteRule ^url?$ index.php
RewriteRule ^image?$ index.php
RewriteRule ^invite?$ index.php
# by writing the below rule: we can excess the URL-CODE with:http://example.com/index/[URL-CODE]
# its convert index.php to index/
# its remove .php extention
# Accepts all alfa-numeric $_GET[link]
RewriteRule ^index/([0-9a-zA-Z]+) index.php?link=$1
but what I want is instead of writing single individual line like:
RewriteRule ^url?$ index.php
RewriteRule ^image?$ index.php
RewriteRule ^invite?$ index.php
I want:
RewriteRule ^url|image|invite?$ index.php
same as for:
RewriteRule ^index/([0-9a-zA-Z]+) index.php?link=$1
to:
RewriteRule ^index|url|image|invite/([0-9a-zA-Z]+) index.php?link=$1
but unfortunatly ^url|image|invite?$ index.php is not working. I am not good at apache. if anybody provide some sort of direction and poinout my mistake it would be a great.
I think this is what you are looking for:
RewriteEngine on
RewriteRule ^/?index/(\w+)/?$ /index.php?link=$1 [END]
RewriteRule ^/?(?:url|image|invite)/?$ /index.php [END]
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).