I am migrating an old website and as part of the task is the migration of the old URLs to the new format.
In the old format, we have lang2 that identifies ENglish, and in the new webpbage I see that the URL has changed to "en".
An old url looks like:
page/lang2/1111/some-title.html
I can extract the variables I need (pattern="page/([^/])/([^/])/([^/]*).html" from the above URL and handle a forward in a Rewrite Rule. What seems hard to do is alter the variable holding "lang2" into "en".
Any one has an idea how to do this?
The new URL should loook like /en/title.id and a full rule would have been:
ReWriteRule ^page\/([^/]*)\/([^/]*)\/([^/]*).html$ /$1/$3.$2 [L]
Problem is the $1 should be changed to "en" if lang2 and another code if "lang1"
So there are only two options, "lang1" and "lang2"? Then simply make two separate rules:
RewriteEngine on
RewriteRule ^/?page/lang2/(\d+)/(.*)\.html$ /en/$2.$1 [END]
RewriteRule ^/?page/lang1/(\d+)/(.*)\.html$ /xx/$2.$1 [END]
Note: "xx" obviously is meant as a placeholder, you did not specify what you mean by "another code".
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).
Related
The URL in my site is https://www.artmail.xyz/single.php?id=37
I want to make it https://www.artmail.xyz/single/37.html
I added the following line in my .htaccess:
RewriteRule ^([^/]*).html$ /single.php?id=$1 [L]
But nothing is happening. No error also.
Is it possible Mod rewrite is 'off' with my server? How can I check. Please help.
Thanks
Certainly it is possible that the rewriting module is not active:
it is an optional module that needs to be loaded into the server
you need to enable it for the specific location (check the documentation for the AllowOverride directive)
you need to use the well known RewriteEngine on initially
But more important is that your matching pattern actually matches what you want it to match:
RewriteEngine on
RewriteRule ^/?single/(\d+)\.html$ /single.php?id=$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).
I am trying to create an image generator with a path that looks like a normal image path. If the image is generated on the URL http://example.com/img/gen/?v1=a&v2=b&v3=c&v4=d I want it to be accessed from this URL: http://example.com/img/gen/a/b/c/d.jpg
I am trying with this .htaccess rule:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/img/gen/([^/]*)/([^/]*)/([^/]*)/([^/]*)\.jpg$ /img/gen/?sn=$1&v=$2&ref=$3&t=$4 [L]
</IfModule>
I have trying placing the file on https://example.com/ and https://example.com/img/gen/ but nothing works.
You made a classical mistake which prevents your rule from getting applied. And though there still mighty be other issues you definitely have to understand that inside a dynamic configuration file (".htaccess") the request URL is examined as a relative path. So your pattern trying to match an absolute paths can never match.
Instead implement your rule in a more flexible way:
RewriteEngine On
RewriteRule ^/?img/gen/([^/]+)/([^/]+)/([^/]+)/([^/]+)\.jpg$ /img/gen/?sn=$1&v=$2&ref=$3&t=$4 [END]
Note the leading 11/? which makes the leading slash optional. That way your 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.
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).
I am trying to 301 redirect some url from my old site structure to my new simpler site structure.
My original urls are formatted: /my-place-name-33/ for example, which I need to redirect to just /my-place-name/ completely omitting the -33
I tired adapting the solution from this thread: htaccess - 301 redirect removing part of url but my separator isn't strong enough (if that makes sense). I only have a hyphen to separate, but in most cases on the site, the my-place-name already contains hyphens.
I'm pulling my hair out trying to get around this. Any help would be amazing.
Many thanks
D
I'd say that this simple approch should do what you are looking for:
RewriteEngine on
RewriteRule ^/?(.+)-\d+/?$ /$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).
I am using htaccess. I try to pass a value in url like '/?'
like "domain.com/?detail.html"
I am retrieving the value in htaccess like
RewriteRule ^?(.*).html$ index.php?key=detail
But it returns only 'detail'. Symbol '?' not accepted. I need the the value '?detail.html'
Is there any solution?
You did not understand how URLs are build. The ? has a special meaning in it. It separates URL and query string. You cannot capture or detect it in a rewriting rule since it is not part of the URL.
If that URL really is what you get as a request, then this would rewrite it as you want:
RewriteEngine in
RewriteCond %{QUERY_STRING} ^(\w+)\.html$
RewriteRule ^/?$ /index.php?key=%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).
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).