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).
Related
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 am developing a site on my main development machine and sometimes I like to code elsewhere away from my desk and on my Chromebook but still on the same network. For other projects, I enable a VirtualHosts plugin to enable access to what I'm working on. The current one I am using is simply called "Virtual Hosts" (https://chrome.google.com/webstore/detail/virtual-hosts/fbkigokjancnolojmhcgcfhgeeljolkh?hl=en). This works fine as projects built with, say, Laravel have relative paths.
The issue I am facing is that when using this method to play around with Wordpress, I get a number of CORS warnings in The Dashboard due to the fact that WP provides absolute paths to resources such as AJAX calls. The plugin above rewrites the request entered into the address bar and maps it to an IP address. However, when editing a page, I get errors such as:
Access to fetch at 'http://dev.somedomain.com/wp-
json/wp/v2/pages/2/autosaves?_locale=user' from origin '
http://192.168.0.14' has been blocked by CORS policy: Response to
preflight request doesn't pass access control check: Redirect is not
allowed for a preflight request.
These requests are not being parsed, fail CORS and prevent me from properly interacting with the dashboard. The error above resulted from trying to save a post.
I've tried adding Header set Access-Control-Allow-Origin "*" to my .htaccess resulting in:
Header set Access-Control-Allow-Origin "*"
<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
But no change to the errors.
The server is Apache running on Ubuntu 16.04. I have access to my router as well if there is a solution configuring that.
When CORS is relevant, the browser will send an OPTIONS request(the preflight) before it sends the first POST.
Response to preflight request doesn't pass access control check:
Redirect is not allowed for a preflight request.
Apache is most likely sending a redirect, but there's no way to tell if or why unless you check apache's logs.
The simplest solution I found was to amend the site address of the Wordpress install to that of the server IP address. Clearly this should only be done for development but it solved my issue.
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).
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.