I am trying to remove the index.php?url=controller/method/parem
I just want to remove the index.php?url= thats it but its not working.
Now its look like this :
http://localhost/ServerSide/index.php?url=FrameWork/Index/category
I want
http://localhost/ServerSide/FrameWork/Index/category
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.+)$ index.php?url=$1 [QSA, L]
If you are using CodeIgniter then this solution works for me.
https://www.formget.com/codeigniter-htaccess-remove-index-php/
I think this is roughly what you are looking for:
RewriteEngine On
RewriteRule ^/?ServerSide/(.*)$ /ServerSide/index.php?url=$1 [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 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).
Related
I have built a React app with a PHP proxy inside. According to my .htaccess, all routes will redirect to index.html. However, I want that if an app calls example.com/proxy, the response to come from my proxy.php file inside the proxy folder and not to return an HTML file.
Here is my .htaccess:
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]
If I access /proxy, I want to have the data from example.com/proxy/proxy.php. Also, example.com/proxy will have parameters and content after (eg. example.com/proxy/compare?apiKey=saksjdskadj&sort=blablabla)
This probaby is what you are looking for:
Options -MultiViews
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/proxy/proxy\.php$
RequestRule ^/proxy/(.+)$ /proxy/proxy.php?action=$1 [QSA,END]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ /index.html [QSA,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).
I have a root directory where 2 (user & admin) project exist. Now I want to remove directory name from URL only for user. Is it possible?
My directory like
myroot
/admin
/user
What I have tried by htaccess is at /myroot/user/.htaccess
RewriteEngine on
RewriteBase /
RewriteRule ^$ myroot/ [L]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^((?!myroot/).+)$ myroot/$1 [L,NC]
But it is not working when I try http://IP/user/Login.php but when I put above htaccess into myroot then it works.
Why I dont want to put this htacces into myroot?
Because My admin link is http://IP/myroot/admin/Login.php is ok but I want to change only user URL from http://IP/myroot/user/Login.php to http://IP/user/Login.php
You need these rules in either a dynamic configuration file (".htaccess" style file) in the http server's DOCUMENT_ROOT folder (which might be myroot here, only you can tell), or, preferably, into the actual http server's host configuration:
RewriteEngine on
RewriteRule ^/?user/(.*)$ /$1 [R=301,QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/admin/
RewriteRule ^/?(.*)$ /user/$1 [END,QSA]
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 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).
I want to map links like https://website.com/test/STRING to https://website.com/test/STRING.png, how to do it with .htaccess?
Options All -Indexes -MultiViews
RewriteEngine on
RewriteBase /test/
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}/test/%1.png -f
RewriteRule ^([^/]+)/?$ /$1.png [NC,L]
but it is not working
I guess this is what you are looking for:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} ^/test/([^/]+)/?$
RewriteCond %{DOCUMENT_ROOT}/test/%1.png -f
RewriteRule ^ /test/%1.png [END]
There are alternatives obviously, this is just a suggestion. 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).
I'm seeting up a new website and want to rewrite some files with parameter in the urls.
The site isn't live right now and unfortunaly i haven't lots of experience in mod_rewrite.
So whats my Problem:
I have two files: category.php and single.php
on my index i have a menu that refers to all categories via url paramater.
For instance on sitename.com/index.php you find links to:
sitename.com/category.php?c=First
sitename.com/category.php?c=Second
sitename.com/category.php?c=Third
and so on
On sitename.com/category.php?c=First for instance you find a list of all posts that refer to category first and linked to:
sitename.com/single.php?c=Frist&name=name1
sitename.com/single.php?c=Frist&name=name2
sitename.com/single.php?c=Second&name=name3
sitename.com/single.php?c=Third&name=name4
and so on
Now i try to rewirte the urls to the following structure:
sitename.com/category.php?c=First => sitename.com/First
sitename.com/category.php?c=Second=> sitename.com/Second
sitename.com/single.php?c=Frist&name=name2 =>sitename.com/First/name2
sitename.com/single.php?c=Second&name=name3 =>sitename.com/Second/name3
I used the following Code
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ categroy.php?c=$1 [L,QSA]
RewriteRule ^(.*)/(.*)$ single.php?c=$1&name=$2 [L,QSA]
</IfModule>
Each RewriteRule works for its own but together i will not get the expected results.
so i tried it serval days now and i don't get it.
So hope someone here can help
Thanks a lot
There are several issues here with your attempt, but the main point is that you need to take care about the order of your rules. Since rules are applied from top to bottom you need to place more specialized rules first in the file (so further up), more general rules later ...
Here is a modified version to point you into the right direction:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [END]
RewriteRule ^/?(\w+)/(\w+)/?$ single.php?c=$1&name=$2 [END,QSA]
RewriteRule ^/?(\w+)/?$ category.php?c=$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.
These rules 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).
Im using right now the next .htaccess:
RewriteEngine On
RewriteRule ^(.*)$ page1.php?$1 [QSA]
its working fine with page1, but not with page2
how can i make it to work please?
I tried this:
RewriteRule ^(.*)$ $1.php?$2 [QSA]
for every php file in the folder, but it's not working.
I'd say this is what you are immediately looking for:
RewriteEngine On
RewriteRule ^/?page1/(.*)$ /page1.php?$1 [END]
RewriteRule ^/?page2/(.*)$ /page2.php?$1 [END]
But it might be worth to check if this cannot be generalized for arbitrary "pages":
RewriteEngine On
RewriteCond %{REQUEST_URI} !-f
RewriteCond %{REQUEST_URI}.php -f
RewriteRule ^/?(.+)/(.*)$ /$1.php?$2 [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 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).