I have made an installation in a Linux Debian of MediaWiki version 1.31 with Apache. I installed the installation in the path /var/www/html/wiki. All right, because when I open the browser and put http://<ip_server>/wiki, it correctly enters my MediaWiki installation.
What I now want is to redirect or rewrite http://<ip_server>/wiki to http://<ip_server>/ so that if I put in the browser http://<ip_server>/ it will redirect me to my MediaWiki installation.
Try the Short URLs documentation at https://www.mediawiki.org/wiki/Manual:Short_URL/Apache
Basically, you need to create a file called .htaccess in /var/www/html/ with the following content:
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/w/index.php [L]
And add this line to your LocalSettings.php file:
$wgArticlePath = "/$1";
Note: The documentation suggests that you avoid using short URLs that are on the server root (like http://<ip_server>/) because things get complicated when you have pages named Images, Docs, Extensions, etc.
Related
I followed the steps outlined here.
I copied and paste the code below in .htaccess file. The .htaccess file is in the same repository that contains my dist folder that I am going to deploy on apache.
RewriteEngine On
# If an existing asset or directory is requested go to it as it is
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
# If the requested resource doesn't exist, use index.html
RewriteRule ^ /index.html
When I access localhost/dist everything goes fine, since it will use my index.html file and it will automatically redirect to localhost/dist/login. Now if I request directly localhost/dist/login, apache complains and displays The requested URL /dist/login was not found on this server. It seems for me that apache does not picked up my .htaccess settings. Is there something I am doing wrong?
Finally I found a way to solve my problem. Maybe this could help some. I enabled the rewrite mode of Apache and instead of
RewriteRule ^ /index.html,
I wrote
RewriteRule ^ /dist/index.html
and this solved my problem.
I am trying to get an apache RewriteRule to take a url and return the url + .html
Ex: 'www.domain.com/about' should serve the page 'www.domain.com/about.html'
I have tried numerous solutions from SO already but I believe there are some complications due to the site layout.
I am hosting on Network Solutions, so it's shared hosting, and this is a development site so I currently have the dev.domain.com pointed to /htdocs/dev
Directory Structure
-htdocs
--(contains existing sites files)
--.htaccess
----dev
------(contains dev site files)
------.htaccess
So as you can see there is an existing .htaccess file that maybe doing something and there maybe a subdomain issue, I'm not entirely sure, this is my first time working with Apache.
Here's my existing .htaccess which resides in the /htdocs/dev folder
RewriteEngine On
RewriteBase /dev
RewriteCond %{REQUEST_URI}.html -f [NC]
RewriteRule ^ %{REQUEST_URI}.html [L]
Thanks for the help!
You are instructing Apache to make a file check (-f), but it doesn't know where to look. Just change
RewriteCond %{REQUEST_URI}.html -f [NC]
to
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}.html -f [NC]
That way Apache has a fully qualified path from your filesystem's root.
I have been using the Zend Framework for years but have realised some crucial problems with our error handling that we are now fixing.
(I posted a different question here: Why my site is always using the ErrorController for all types of errors irrespective of HTTP Status code? explaining the story there).
My question here is a quick one. What does a common .htaccess file of Zend Framework look like?
According to the latest ZF documentation,
SetEnv APPLICATION_ENV development
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
However, the above is new to me - can someone explain what it does exactly?
My current .htaccess file has a lot of 301 redirect code but for the purpose of this post I'll only paste the relevant information here:
ErrorDocument 404 http://www.mydomain.com/pagenotfound/
ErrorDocument 503 http://www.mydomain.com/service-unavailable/
RewriteCond %{REQUEST_URI} !^/liveagent
RewriteCond %{REQUEST_URI} !^/blog
RewriteRule !\.(js|ico|gif|GIF|jpg|JPG|jpeg|png|PNG|pdf|css|html|xml|swf|php|mp3|mp4|webm|ogv|f4v|flv|txt|wsdl|css3|ttf|eot|svg|woff)$ index.php
The above has been working fine for us, and basically disallows the "liveagent" and "blog" (Wordpress) directories from running with Zend, but I realise I now need to make the following change:
ErrorDocument 404 definitely has to be removed from the code, as Zend Framework should handle all errors. However, when I remove this, going to a URL like www.mydomain.com/this-does-not-exist.php results in a 404 error standard Apache page - it does not load the ZF or the ErrorController. This is because of the "php" exclusion in the above RewriteRule. I do not simply want to remove this since we sometimes want to be able to access php files on the root, such as a separate "holding.php" file which we use for putting the site on maintenance mode.
What is the standard practice? Should I remove the php extension? However this will not solve other 404's like
www.mydomain.com/this-does-not-exist.css
which is also an exclusion (i.e. CSS) in the above RewriteRule.
Therefore, should I completely change the above to Zend's new code for .htaccess as I mentioned above?
If so, I'm a sort of beginner at htaccess - how can I modify that .htaccess code to allow CSS, JS, video files etc. and the blog and liveagent directories to be excluded from the Zend Framework?
I'd switch to the standard ZF rewrite rules instead of the one you have which uses a long regex to redirect to index.php.
Here is an explanation of what the standard .htaccess rules do:
RewriteCond %{REQUEST_FILENAME} -s [OR] # The request is a regular file with size > 0
RewriteCond %{REQUEST_FILENAME} -l [OR] # The request is to a file that is a symlink
RewriteCond %{REQUEST_FILENAME} -d [OR] # The request is to a directory that exists
# if any of the above conditions are true, then simply handle the request as-is
RewriteRule ^.*$ - [NC,L]
# if none of the above match, then rewrite to index.php
RewriteRule ^.*$ index.php [NC,L]
These default ZF rules don't prevent you from accessing existing php files or any other files that are accessible from your document root. If the file requested exists, then the request for that file is served as is. If the file requested does not exist, then the request is forwarded to index.php
Once the request is forwarded to ZF, if there is no matching route, then the ZF ErrorHandler is called and a 404 page (from ZF) is served.
Using the stock ZF rules won't prevent you from having the desired behavior in your application and server settings, and should be a bit more efficient that the regex you currently have. The only things that will really change is that now requests for files that don't exist will be handled by ZF's error handler and no longer by Apache.
Hopefully that answered your question, if not feel free to comment for clarification.
I've been looking on various sites reading mod_rewrite examples for a few hours, and have used it many times before successfully... but I'm trying something new with it now and can't for the life of me get it working!
I'm using a PHP file manager tool called AjaXplorer, I have it in a subdirectory on the root of my server /ajaxplorer-core-4.0.4. When I go to the root of my site http://domain.com/ I want it to invisibly redirect to the /ajaxplorer-core-4.0.4 folder (but still show the root domain in the address bar).
I still want to be able to access the other files/directories on the root as normal just typing in the path.
I assume this is possible? Seems relatively simple but I just can't get it working.
AjaXplorer seems to load js files and images etc from /ajaxplorer-core-4.0.4/plugins, I have a feeling that's where it's tripping me up.
Any pointers would be massively appreciated! Thanks
Found it on another answer luckily :)
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?site.com$
RewriteCond %{REQUEST_URI} !^/subdir/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /subdir/$1
RewriteCond %{HTTP_HOST} ^(www.)?site.com$
RewriteRule ^(/)?$ subdir/index.php [L]
Here's the wiki of serverfault.com
The howto's htaccess official guide
The official mod_rewrite guide
And if that's not enough:
Two hints:
If you're not in a hosted environment (= if it's your own server and you can modify the virtual hosts, not only the .htaccess files), try to use the RewriteLog directive: it helps you to track down such problems:
# Trace:
# (!) file gets big quickly, remove in prod environments:
RewriteLog "/web/logs/mywebsite.rewrite.log"
RewriteLogLevel 9
RewriteEngine On
My favorite tool to check for regexp:
http://www.quanetic.com/Regex (don't forget to choose ereg(POSIX) instead of preg(PCRE)!)
I am looking to run WordPress and Magento on the same domain. Wordpress is installed at the root of the site and Magento would be installed at /store/.
I have had the Apache config setup for WordPress (having all requests redirect to index.php), what Apache configuration logic do I need for all requests to /store/* to goto /store/index.php ?
You should be able to simply keep the default Magento .htaccess file in the store directory along with the other Magento files, then exclude anything with that path from your wordpress rewrites. I'm not up to date on what wordpress .htaccess files may look like, but it should simply be a case of adding a RewriteCond.
I would guess that the rewrite for wordpress will look something along the lines of...
RewriteCond %{REQUEST_URI} !-f
RewriteCond %{REQUEST_URI} !-d
RewriteRule (.*) /index.php?$1 [QSA,L]
If this is the case simply add another RewriteCond should do the trick...
RewriteCond %{REQUEST_URI !^store/
Posting the Wordpress .htaccess file may lead to more accurate advice.