.HTACCESS Apache Mod_Rewrite not working
No need to write RewriteBase /
Use below htaccess.
# Turn mod_rewrite on
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php/$1 [L]
# add / before index.php
Hope it will work :-)
apache mod_rewrite not working with .htaccess file
Not sure if this is the cause of your problems, but you shouldn't mess with the
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
line, and it should be something like:
<Directory />
Options FollowSymLinks
AllowOverride None
Deny from all
</Directory>
You should add the directory of your document root as a different container:
<Directory /var/www/html/>
Options FollowSymLinks
AllowOverride All
Allow from all
</Directory>
apache mod_rewrite is not working or not enabled
Try setting: "AllowOverride All".
.htaccess not working (mod_rewrite)
In my case, I changed in httpd.conf:
AllowOverride None
to
AllowOverride All
and it works.
Mod_rewrite rules not working in .htaccess to change the URL
but I've seen many articles where a url such as
example.com/display_article.php?articleId=my-article
can be rewritten asexample.com/articles/my-article
for example with.htaccess
But the important point here (that I think you are missing) is that the URL must already have been changed internally in your application - in all your internal links. It is a common misconception that .htaccess
alone can be used to change the format of the URL. Whilst .htaccess
is an important part of this, it is only part of it.
Yes, you can implement a redirect in .htaccess
to redirect from the old to new URL - and this is essential to preserve SEO (see below), but it is not critical to your application working. If you don't first change the URL in your internal links then:
The "old" URL is still exposed in the HTML source. When a user hovers over or copies the link, they are seeing and copying the "old" URL.
Every time a user clicks one of your internal links they are externally redirected to the "new" URL. This is slow for your users, bad for SEO (you should never link to a URL that is redirected) and bad for your server, as it potentially doubles the number of requests hitting your server (OK, 301s are cached locally).
To quote from @IMSoP's answer to this reference question on the subject:
Rewrite rules don't make ugly URLs pretty, they make pretty URLs ugly
So, once you have changed your internal links to the "new" (expected) format, eg. /test/news/value1/value2
(or should that be /test/news/value1/value2/id
or even /test/news/id/value1/value2
? See below), then you can do as follows...
RewriteRule ^test/news/([^/]*)/([^/]*)$ /test/news/?c=$1&s=$2&id=1 [L]
This internally rewrites a request from /test/news/<value1>/<value2>
to /test/news/?c=<value1>&s=<value2>&id=1
. However, there are a couple of issues with this:
/test/news/
is not itself a valid endpoint. This requires further rewriting. Perhaps you are serving a DirectoryIndex document (eg.index.php
)? This might appear seamless to you, but this requires an additional internal subrequest and makes the rule dependent on other elements of the config. You should rewrite directly to the file that handles the request. eg./test/news/index.php?c=<value1>&s=<value2>&id=1
(remember, this is entirely hidden from the user).You are hardcoding the
id=1
parameter? Should every URL have the sameid
? Or should this be passed in the "new" URL (which is what I would expect)? What does theid
represent? If this is critical to the routing of the URL then theid
should appear earlier in the URL-path, in case the URL gets accidentally truncated when copy/pasted/shared.If the
id
is required then it needs to be passed in the "new" URL. We only have the "new" URL to route the request, so the information can't be hidden.
So, if the "new" URL is now /test/news/<id>/<value1>/<value2>
then the rewrite would need to be like this instead:
# Rewrite new URLs to old/actual URL
# "/test/news/<id>/<value1>/<value2>" to "/test/news/?c=<value1>&s=<value2>&id=<id>"
RewriteRule ^test/news/(\d+)/([^/]+)/([^/]+)$ /test/news/?c=$2&s=$3&id=$1 [L]
Then (optionally*1) you can implement an external redirect in order to preserve SEO. This is for search engines that have indexed the "old" URLs or third party inbound links that cannot be updated - these need to be corrected to inform search engines of the change and get the user on the "new" canonical URL having followed an out-of-date inbound link.
(*1 It's not "optional" if you are changing an existing URL, but optional with regards to your application being functional.)
This "redirect" goes before the above rewrite:
# Redirect old URLs to the new "canonical" URL
# "/test/news/?c=<value1>&s=<value2>&id=<id>" to "/test/news/<id>/<value1>/<value2>"
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{QUERY_STRING} ^c=([^&]+)&s=([^&]+)&id=(\d+)
RewriteRule ^test/news/$ /$0%3/%1/%2 [QSD,R=301,L]
The $0
backreference contains the full match from the RewriteRule
pattern, ie. test/news/
in this case - this simply saves repetition.
The %1
, %2
and %3
backreferences contain the values captured from the preceding condition. ie. the values of the c
, s
and id
URL parameters respectively.
Note that the URL parameters / path segments should not be optional as in your original directive (ie. ([^/]*)
). If they are optional and they are omitted, then the resulting URL becomes ambiguous. eg. <value2>
becomes <value1>
if <value1>
is omitted.
Note that the URL parameters must be in the order as stated. If you have a mismatch of "old" URLs with these params in a different order (or even intermixed with other params) then this can be accounted for with additional complexity. (It may be easier to perform this redirect in your server-side script, instead of .htaccess
.)
The first condition that checks against the REDIRECT_STATUS
environment variable ensures that we only redirect direct requests and not rewritten requests by the later rewrite (which would otherwise result in a redirect loop). An alternative on Apache 2.4 is to use the END
flag on the RewriteRule
instead.
The QSD
flag (Apache 2.4) discards the original query string from the request.
You should test first with a 302 (temporary) redirect to avoid potential caching issues and only change to a 301 (permanent) redirect once you have tested that everything works as intended. 301s are cached persistently by the browser so can make testing problematic.
Summary
Your complete .htaccess
file should look something like this:
Options -MultiViews +FollowSymLinks
# If relying on the DirectoryIndex to handle the request
DirectoryIndex index.php
RewriteEngine On
# Redirect old URLs to the new "canonical" URL
# "/test/news/?c=<value1>&s=<value2>&id=<id>" to "/test/news/<id>/<value1>/<value2>"
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{QUERY_STRING} ^c=([^&]+)&s=([^&]+)&id=(\d+)
RewriteRule ^test/news/$ /$0%3/%1/%2 [QSD,R=301,L]
# Rewrite new URLs to old/actual URL
# "/test/news/<id>/<value1>/<value2>" to "/test/news/?c=<value1>&s=<value2>&id=<id>"
RewriteRule ^test/news/(\d+)/([^/]+)/([^/]+)$ /test/news/?c=$2&s=$3&id=$1 [L]
Apache mod rewrite rule not working
Have this rule in <DocumentRoot>/al/.htaccess
:
RewriteEngine on
RewriteBase /al/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .+ ?page=$0 [L,QSA]
Laravel 5 Apache mod_rewrite not working
The .htaccess
file won't load up because it is in the public
directory, which is really meant to be your document root. As such, you should be accessing the app by going to localhost/page/public/subpage
.
If you want to use localhost/page/subpage
whilst keeping your directory structure intact, then you need to add a new .htaccess
file to the page
directory, and delete the .htaccess
file from the public
directory.
/page/.htaccess
contents:
<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
Options -MultiViews
</IfModule>
RewriteEngine On
RewriteBase /page/
# Redirect Trailing Slashes...
RewriteRule ^(.*)/$ /$1 [L,R=301]
# Send requests to public directory...
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ public/index.php [L]
</IfModule>
Unfortunately, due to the way in which Laravel obtains the request information, you will need to group your routes to the page
directory in your route configuration:
Route::group(['prefix' => 'page'], function()
{
Route::get('subpage', ['as' => 'subpage', 'uses' => 'GenericPageController@subpage']);
// Your other routes ...
});
Essentially, and in my opinion, this is the easiest way to work around this. You could also move the contents of your public
directory up one level and change the paths accordingly in the bootstrap file.
Related Topics
Dependency Walker Equivalent for Linux
How to Point a Docker Image to My .M2 Directory for Running Maven in Docker on a MAC
Linux Kernel - Add System Call Dynamically Through Module
Makefile Command Substitution Problem
Is It Ok (Performance-Wise) to Have Hundreds or Thousands of Files in the Same Linux Directory
How to Run the Cron Job as a User Instead of Root User
Why Do I Get "Suspended (Tty Output)" in One Terminal But Not in Others
Why Linux Kernel Use Trap Gate to Handle Divide_Error Exception
Difference Between Bash Pid and $$
What Character Sequence Should I Not Allow in a Filename
How to Get the Interface Name/Index Associated with a Tcp Socket
How to Install Influxdb in Windows