I have a folder Storage/static/css. And I want for design/css to see Storage/static/css content.
/Classes
...
...
/Storage
/static
/css
/home
design.css
/menu
/footer
/js
...
/uploads
...
...
index.php
I tried this:
<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
Options -Indexes
</IfModule>
RewriteEngine On
RewriteRule ^design/css/(.*)$ /Storage/static/css/$1
RewriteRule ^ index.php [L]
</IfModule>
For index.php works fine for a long time ago.
But for the other one doesn't work at all.
I want for example:
For design/css/home/design.css to return content from Storage/static/css/home/design.css.
Edit:
My entire web app isn't in root. It is inside a folder called /arshwell.
Looks like you accidentally re-rewrite the css requests in a second go...
Have a try with this slightly modified version:
RewriteEngine On
RewriteRule ^/?design/css/(.*)$ /Storage/static/css/$1 [END]
RewriteRule ^ /index.php [END]
This will prevent that requests rewritten to /Storage/static/css/$1 will immediately get rewritten again to index.php by the next rule.
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 set 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 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've installed Wordpress in root directory and CodeIgniter in sub directory. I'm having the following set of urls:
http://www.example.com/about-us (Wordpress)
http://www.example.com/sub-dir/users/login (CodeIgniter)
http://www.example.com/sub-dir/merchant/login (CodeIgniter)
Now I want to remove sub-dir only from second url and the remaining urls should work as they are.
Here is .htaccess code in root directory (Wordpress)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /yevma/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /yevma/index.php [L]
</IfModule>
# END WordPress
Any help would be appreciated!
Your question is vague, we can only assume that you are trying to publish the resource currently reachable via that second URL under a different, shorter URL.
Also assuming that this will not somehow collide with other resources this should point you into the right direction:
RewriteEngine on
RewriteRule ^/?users/login$ /sub-dir/users/login [QSA,END]
Note however tht this might cause issues with the internal references used in those applications you have, since you break the structure with such a single redirection.
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 redirect some URLS on the old site to specific destination on the new site and the rest of the URLS to the home page. So far I have tried the following:
Use Redirect 301 /permalink https://newsite.com/permalink1/ for all the links that need to go to a specific page on the new site
For the rest, I added a generic rule
RewriteCond %{HTTP_HOST} ^oldsite\.com$ [NC]
RewriteRule ^(.*)$ https://newsite.com [R=301,L]
but this redirects all the pages to the home page of the new site.
Then I tried to replace point 2 above with RedirectMatch
RedirectMatch 301 .* https://newsite.com
but this tries to find an exact match on the new site. oldsite.com/xyz goes to https://newsite.com/xyz
Also, some of the old site URLs have parameters, oldsite.com/a=?b=123 how can I redirect such parameters to the new site homepage.
This probably is a straight forward approach:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^oldsite\.com$
RewriteRule ^/?permalink1old(/.*)$ https://newsite.com/permalink1new$1 [R=301,QSA]
RewriteCond %{HTTP_HOST} ^oldsite\.com$
RewriteRule ^/?permalink2old(/.*)$ https://newsite.com/permalink2new$1 [R=301,QSA]
RewriteCond %{HTTP_HOST} ^oldsite\.com$
RewriteRule ^ https://newsite.com/ [R=301]
So you redirect the old permalinks on the old host name to their new counterpart on the new host name, appending anything that might follow in the path of the initial old permalink and you append the query string to preserve arguments.
If the permalinks never contain anything additional in their paths then you can simplify those redirections, obviously:
RewriteCond %{HTTP_HOST} ^oldsite\.com$
RewriteRule ^/?permalink1old/?$ https://newsite.com/permalink1new [R=301,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...
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've just moved my site onto Wordpress, which means the URL structure has now changed. I'd like to use a Rewrite Rule in the .htaccess file to redirect dynamic URLs with multiple IDs in one single statement, but am not having any success. An example is:
OLD URL: example.co.uk/seasons/season.php?ID=1819
NEW URL: example.co.uk/seasons/1819
The statements I have tried in .htaccess are:
RedirectMatch 301 ^/seasons/season.php?ID=(.*).htm$ example.co.uk/seasons/$1
and
RewriteCond %{QUERY_STRING} ^?ID=1$
RewriteRule ^/seasons/season.php$ example.co.uk/seasons/? [R=301,L]
In neither case, the redirect fires. Is there something about a Wordpress .htaccess file that I'm not considering, or is the error with the statements I'm attempting. I'm using .htaccess 301 redirects for http to https and non-www to www without issue.
This is the fixed version of the approach you chose, to make an external redirection:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)ID=(\d+)(?:&|$)
RewriteRule ^/?seasons/season\.php$ https://example.co.uk/seasons/$1 [R=301,QSD]
Since both, the old and new URLs use the same host name you can simplify that:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)ID=(\d+)(?:&|$)
RewriteRule ^/?seasons/season\.php$ /seasons/$1 [R=301,QSD]
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...
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).
I have a variation on the old WordPress problem regarding permalinks failing (404 errors) when permalinks are set to anything other than 'plain' (where plain = http://example.com/?p=123 and a 'pretty' URL = http://example.com/sample-post/ - taking the URL content from the article title, for example).
For the first time I am starting a site on a virtual rather than dedicated server (Hetzner hosted), where I at least was able to easily read the httpd.conf settings and other server configurations.
To recap here, the problem is that neither WordPress nor the default server settings are usually ready for the URL rewriting that allows 'pretty' URLs out of the box. When confronted with this problem before, on dedicated servers, I would ensure that AllowOverride was set to 'all' or '[directory]' and then would put in an .htaccess file into the web's document root with this traditional solver:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
However this does not work on my Hetzner server. I put in the above code to an .htaccess file, set the permissions correctly and restarted. But the front page still shows links to the article lists, but the articles themselves all still throw that old 404 error.
The only access I have to the core server directives is drip-fed out in sections and radio-buttons etc via Plesk. I can't even open up the httpd settings read only to see how AllowOverride is set. Hetzner consider this a 'software problem', and therefore unsupported.
There is a section in Plesk where you can add additional Apache and Nginx directives (with duplicate boxes for http and https for Apache). I tried this in the Apache boxes and rebooted, but it didn't help (obviously this is not the actual URL I wrote):
<Directory "/var/www/vhosts/example.com/httpdocs/">
AllowOverride All
</Directory>
If anyone has any suggestions as to how I can get the usual rewrite fix in, in these circumstances, it would be much appreciated.
Okay, the problem was an obscure one, as it turned out. The virtual server was running Nginx on top of Apache, and I needed to install a plugin via Plesk which provides an 'ht access translator' for Nginx in Plesk. I pasted the rewrite directives there, they were 'translated' to Nginx-understandable commands, and the problem is solved.
I am trying to redirect all requests to domain.com/drupal to domain.com, including all sub directories in /drupal.
I have seen several answers telling me how to accomplish the opposite of this with .htaccess, but nothing to go this way. I have tried the following line in .htaccess-
RewriteRule /drupal/* ^/(.*)
as well as several variations of the above, based on those answers, but haven't had any luck.
Thanks!
Try this line:
RewriteRule /drupal/(.*) /$1 [QSA,L]
Let me get this straight ... You have an installation of Drupal in <DocumentRoot>/drupal/. You do not want to alter the drupal installation directory, nor you want to change DocumentRoot in your webserver config. You want to redirect any request, for example /foobar.php, into the drupal directory, resulting in maybe /drupal/foobar.php. And all that without exposing the whole stuff to the user. Right so far? OK, I can only assume that you have an Apache webserver, else .htaccess would not work...
First, make sure that you actually are allowed to use .htaccess, so check on the relevant AllowOverride directive in your apache config.
Then try it this way in your <DocumentRoot>/.htaccess:
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/drupal.*
RewriteRule ^/(.*)$ /drupal/$1 [P]
RewriteCond ensures that you do not run into an infinite loop. The first part of the RewriteRule is always the URL requested by the client. We prefix the part matched inside the parentheses with /drupal/ and force it to be a proxy request via [P] so that apache would only do an internal redirect (instead of sending the client a "Document has moved" redirection code).
BTW: I did not test it. I may have typos in the code. Read http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriterule for more information.