I have this URL
https://www.example.com/detail.php?slug=ashutosh&event=c7da097d2c5a11e9821a01ec0a18050e&eventID=cb20a1fcb9bd8c3d8240d3ccb903c32637e044f10c6a2d09b&utm_source=t&utm_campaign=main&utm_medium=Test
i need this type of URL
https://www.example.com/user/ashutosh?event=c7da097d2c5a11e9821a01ec0a18050e&eventID=cb20a1fcb9bd8c3d8240d3ccb903c32637e044f10c6a2d09b&utm_source=t&utm_campaign=main&utm_medium=Test
pls help any one
Since you did not specify any condition when to apply this rule I assume that it is to get always applied when the base URL starts with /user/ followed by a user name (a word) and nothing else. And that the user name should get specified as `slug``parameter, that at least is what your example suggests...
That would result in a rewriting rule like the following:
RewriteEngine on
RewriteRule ^/?user/(\w+)/?$ /detail.php?slug=$1&%{QUERY_STRING} [END,QSA]
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).
Related
The url of my app is http://example.com/public/login. I want my url to be http://example.com/account/login.
How do I replace text with .htaccess
This thread hides the text only. But I need to replace the text
If you really only want to redirect that specific URL, then this should do the work:
RewriteEngine on
RewriteRule ^/?public/login$ /account/login [R=301,END]
RewriteRule ^/?account/login$ /public/login [END]
If your "app" actually consists of more than just that single URL you will have to modify your question and add more precise details...
For above rule set to work you have to implement it either in the http server's host configuration or, if that is not possible for you, in a distributed configuration file (".htaccess"). In the second case you also need to make sure that the interpretation of such files is actually enabled and the rules are implemented in the DOCUMENT_ROOT folder of your host. See the excellent documentation for more details and good examples: https://httpd.apache.org/docs/current/mod/mod_rewrite.html
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 need a rules that find a folder in my url and rewrite folder before.
Example:
www.site.it/folder1/sub1/detail/page.html =>
www.site.it/newfolder/sub1/detail/page.html
www.site.it/folder2/sub1/detail/page2.html => www.site.it/newfolder/sub1/detail/page2.html
www.site.it/folder1/fodler2/sub1/detail/page3.html => www.site.it/newfolder/sub1/detail/page3.html
Sounds pretty straight forward:
RewriteEngine on
RewriteRule ^/?([^/]+)/sub1/(.*)$ /newfolder/$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 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).
How to rewrite domain from:
"localhost/test/?p=1" to "localhost/test/yoyoyo"
and
"localhost/test/?p=2" to "localhost/test/gogogo"
Well, you simply rewrite each incoming request to its desired target:
RewriteEngine on
RewriteRule ^/?test/yoyoyo/?$ /test/?p=1 [END]
RewriteRule ^/?test/gogogo/?$ /test/?p=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 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).
This obviously only makes sense for a static set of URLs to be rewritten. For larger, dynamic sets you want to implement a routing script. That script is executed regardless of the specific request and compares the URL it has been requested with against entries in a database, then performs a redirection or whatever action you want. That is much slower, obviously, but offers more flexibility.
I have a list of state urls like this, which are identical except the state name
/Wyoming_Red_Widgets
/Ohio_Red_Widgets
and want to redirect all to:
/red-widgets
Various patterns, although I am newer to Modrewrite / htaccess
Rewrite /([a-z]+)_Red_Widgets /red-widgets/
Nothing happens (no redirect)
Your question is vague, but strictly speaking this probably is the closest answer to what you actually asked:
RewriteEngine on
RewriteRule ^/?.+Red_Widgets/?$ /red-widgets [END]
For this to work you need to make sure that dynamic configuration files (".htaccess" style files) are considered at all by the http server for this location (hint: AllowOverride) and they file is readable for the http server process.
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 need to write a rewrite rule in my .htaccess file,
I readed tutorials but always fails.
What I want is:
domain.com/en/111/page-title ->redirects to-> domain.com/viewPage.php?language=en&id=111
I dont need the page-title parameter, only the language and id
You most likely do not actually want a redirection rule, but an internal rewriting:
RewriteEngine on
RewriteRule ^/?([a-z]{2}])/(\d+)/ /viewPage.php?language=$1&id=$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).