I was starting to implement mod_rewrite rules on my site when I came across some weird behaviour. I removed my htaccess file for this test, to take it out of the equation.
My local dev site is at http://dev.mydomain.com and is a virtual host.
If I go to, eg "http://dev.mydomain.com/blog/", that folder doesn't exist, but apache finds a matching php file "blog.php" and instead displays that.
This only happens when there is a matching php file - when there isn't, eg "http://dev.mydomain.com/barfblurg/" I just get a 404.
It's like there are some extra mod_rewrites going on above where the site htaccess would be - that when /file/ couldn't be resolved, it searches for other matching files and instead serves this - but there are no other htaccess files that would have an effect, so this must presumably be a config thing? I can't see anything in the apache.conf or php.ini that would cause this behaviour.
(This also doesn't happen on my live host elsewhere, so it's definitely a config thing.)
Anyone point me to where to turn that behaviour off, because it's interfering with the url rewrites I want to do?
(Apache2, OSX, 10.10.5)
This behavior is due to enabling of option MultiViews.
Option MultiViews is used by Apache's content negotiation module that runs before mod_rewrite and makes Apache server match extensions of files. So /file can be in URL but it will serve /file.php.
To turn this off use:
Options -MultiViews
at top of your .htaccess or in Apache config/vhost file.
Related
The Apache2 docs recommend mod_rewrite as a last resort for specifying which directory to send a given host request to. They said use mod_vhosts_alias. I set that up and its working without problem. However, I have a specific case that entails some mod_rewriting.
I have a domain like mydomain.com and a large number of subnames like sub.mydomain.com and sub2.mydomain.com. These subdomains all map to corresponding directories. But the subdomains will also have full top-level domains that map to respective directories. For instance:
sub.mydomain.com will map to the same directory as awesomeproducts.com sub2.mydomain.com will map to the same directory as widgets.com
What would be the best way to make sure both these methods of accessing each site will work without conflict?
Since the docs only say mod_rewrite isn't as "graceful" as mod_vhosts_alias, I didn't know if I ought to use mod_rewrite completely by itself for my situation or if I should be trying to mix the two approaches somehow.
Is mixing them the way to go or will that create problems?
The behaviors of RewriteRule and RewriteCond change when using mod_vhost_alias. Its been a few days since I tinkered with it so I'm sketchy on it, but watch out for the way RewriteRule interprets the portion of the URL to be rewritten. It may change when using mod_vhost_alias... and RewriteCond behavior might change too.
To accomplish the question I was asking about, I ended up using symbolic links for the actual domains. I setup a bunch of subdomains with associated folders so that sub1.stddomain.com would go to the folder sub1.stdomain.com. Then I added a symbolic link that maps domain1.com to the sub1.stddomain.com folder. That way anyone who visits domain1.com is shown the site in the sub1.stddomain.com folder.
IMPORTANT: After all that work and testing, I ended up going back to to a collection of virtualhost files WITHOUT mod_vhost_alias. Turns out that there is a known problem with mod_vhost_alias. DocumentRoot isn't correctly set when using it. This breaks tons of scripts. It was patched in February 2012 with new special variables and the programming team at Apache dropped the ball. They never wrote any documentation explaining how to use the patch or new variables.
I reopened the issue and stated that its still a bug since you can't write code and not tell anyone how to use it and then call it fixed. Unfortunately the issue had already been ignored for YEARS and it will probably continue to get ignored even though they supposedly wrote code for it.
RECOMMENDED LESSON FROM ALL THIS: Don't use mod_vhost_alias. Write shell scripts to manage your vhost files using one more template files.
I've noticed that on several web pages e.g. StackOverflow instead of stackoverflow.com/questions/ask.php they have stackoverflow.com/questions/ask.
How is this done?
If I understand your question right, you just want to have file-names|tags|titles|categories after the last slash to route semantically to the according file or a hidden path;
If so, you will gain this dependent on the possibilities you have:
A) Do you have access to httpd.conf on your Server?
Look out for the DirectoryIndex;
OR
B) If you are not able to edit httpd.conf, do you have access to .htaccess on your server?
Look out if DirectoryIndex is already set anywhere, in most cases it won't; so you want to create your own new entry;
TODO:
Now define the DirectoryIndex by letting this reserved word be followed by the filenames you want to have
been routed to another filename or path/filename
GODO:
DirectoryIndex
[SPACE]
file-name.ending OR file-name OR tag OR title-with-some-words-bond-together
[SPACE]
repeat step 3 and 4 until you have a set of catchers to be caught ...
at least: add the target of your set by spending a path
DOJO:
RELOAD your server
OR
RESTART if necessary
EXAM:
DirectoryIndex index.html index.htm index.pl index.asp index.jsp index /routed/to-path_of/index.php
DirectoryIndex ask ask.php
MOJO:
This is a quant of what you can achieve; Look out for pretty-printing URL's, apache mod-rewrite, DirectoryIndex, URI URL hiding, domain forwarding and similar keys you can google for.
In most cases it would have been realized by well-known BLOG/CMS-SoftWare like WordPress, JOOMLA, DruPal, etc. via mod-rewrite, as this is the controlled and preset way if necessary rights are given.
Personally i would recommend to use the simple format of setting DirectoryIndex via .htaccess, as i explained before, because if you realize your own magic-words you may want to write a script that checks for hash-changes, sniffs history and responds accordingly to server-errors.
If you program it in DJango, NodeJS, or other WebApp language, they actually parse the URL and do not give you files. Instead it is known as views and map into a certain piece of code.
I suggest your learn NodeJS.
It is done through a .htaccess file...
I noticed Joomla, Wordpress and other CMSs have blank index.html files in ALL their sub folders to prevent people from peeking into the folder structure. My question is why can't they forbid folder viewing using the .htaccess file instead of putting a blank index.html file into all the folders. What's the difference and why have they chosen index.html?
Turning off folder 'Indexes' is best done in the master httpd.conf or vhosts.conf file rather than local .htaccess files.
Joomla (and Mambo before it) have been around quite a while and are used widely on shared hosting servers. The decision was taken to use index.html files as a safe fallback given the 'mixed' nature of shared hosting. Obviously .htaccess files are apache only, can cause server 500 errors if present on servers not expecting them or if they contain directives not supported by certain server setups. Consequently by default Joomla doesn't ship with a .htaccess file as such. There is a htaccess.txt file which the user needs to put in place manually if they activate certain features. It is assumed that a user knowledgeable enough to put the file in place will understand the consequences and if it does kill their site they will immediately understand the cause - due to the error immediately following their actions.
As server setups have advanced there is (sometimes heated) discussion about the current validity of the use of index.html files - but for now the policy is that all add-ons should ship with 'blank' index.html files in all folders.
I recently migrated my magento website to a different server, and here's the process I used:
made a dump of the database.
copied all the system files from the FTP to my hard drive.
emptied the VAR folder
emptied the media cache folders
replaced the strings in the SQL dump from http://www.oldsite.com to http://www.newsite.com
restored the database on the new server
modified the local.xml file to suit the new database host, login and password.
uploaded the system files to the new server
Everything seems to work fine, except for the fact that the product images are not being displayed on the frontend for some reason.
For example, here's a path from an image that was supposed to be showing, which I got through firebug:
http://www.newsite.com/media/catalog/product/cache/1/small_image/113x113/9df78eab33525d08d6e5fb8d27136e95/1/_/1_9.jpg
When I search for the path of the image the site is supposed to show in the FTP, the file is actually there. I can download it and display it on my computer. I don't know why this is happening. It doesn't make any sense to me.
This /media/catalog/product/cache/ was generated by the system, because I erased it myself before uploading the site, so I guess it isn't a cache related issue.
Well, I described the issue the best I could. I hope you can help me out.
EDIT:
Hmm, it turns out the problem was the .htaccess file inside the media folder! Removed the file -> Problem solved!
Just in case anyone else has the same problem, removing the .htaccess in the media folder did the trick. I don't know if that's the best possible solution though! Thanks!
Change Options All -Indexes to Options -Indexes in the above mentioned .htaccess file.
copied all the system files from the FTP to my hard drive.
This one makes me a bit suspecting. Magento has case-sensitive folders in the media folder. There would be, for instance, an 'a' folder and an 'A' folder in the same location.
If you downloaded your files unarchived (file by file) via FTP to a Windows machine, this would cause a conflict and would omit up to half your images.
Ok, since everything checked out with the base URL, my next suggestion is a migration path option if you have cPanel on the old server, and since most do, this should help:
Create a full backup of the account using cPanel. This will create a tar.gz of the entire account.
Download the tarred backup to your computer and unzip.
Find home_dir.tar - this is what contains your HTML root information. You can either upload this directly to the server and untar there using SSH, or do it on your local computer and upload.
Find the SQL folder in the untarred backup. There should be a dump of your database there. Use source to put that information into a new database.
On the server, delete use_cache.ser and change config information for the new database.
Your .htaccess should have come over in the home_dir.tar, but make sure that it's correct per our other question
Once that's done, you should be fully functional, unless you need to make changes in the database base_url for the new server.
Images not showing in Magento 1.7 to 1.9 upgrade:
My solution:
in /media/.htaccess
fixed options syntax:
# Options ExecCGI Includes IncludesNOEXEC SymLinksIfOwnerMatch -Indexes
Options +ExecCGI +Includes +IncludesNOEXEC +SymLinksIfOwnerMatch -Indexes
removed these. Maybe conflict with .htaccess in site root directory??
# For security reasons, Option followsymlinks cannot be overridden.
# Options +FollowSymLinks
# Options +SymLinksIfOwnerMatch
# RewriteEngie on
also changed ownership of .htaccess to apache
chown apache:apache /var/www/mystore/media/.htaccess
Would like opinion of why these may be causing 500 errors.
php bin/magento catalog:images:resize
This helped me, but it take's a lot of time to complete
for magento 2.4.5
in pub//media/.htaccess
change „FollowSymLinks“ to „SymLinksIfOwnerMatch“. example:
############################################
enable rewrites
Options +SymLinksIfOwnerMatch
RewriteEngine on
## you can put here your pub/media folder path relative to web root
#RewriteBase /magento/pub/media/
############################################
I'm trying to install SilverStripe and during the installation, it returns an error saying that friendly links aren't working. However mod_rewrite is enabled and AllowOverride is set to All. I'm using CentOS Linux on a dedicated server with Webmin as the cp (yes, I know.. not my choice).
The installer should have set things up as best it can, even if you receive that error message.
This question is a little tricky to answer because the problem could lie in a number of different places, but I've tried to put together a troubleshooting guide below.
Note: Many of the links below have been deliberately broken because Stack Overflow think I might be a spammer. ;-)
Assuming that your site is at http:/www.example.com, try visiting http:/www.example.com/dev/build - you should see a page with a heading "Environment Builder (formerly db/build)". If that works, then you have no problems with rewrite, and the installer gave you that message in error.
If that gives you a 404, try http:/www.example.com/sapphire/main.php?url=dev/build - this will visit the same feature, but bypasses mod_rewrite. If that gives you the heading "Environment Builder (formerly db/build)" and the previous URL didn't, then you have a problem with mod_rewrite and not some other problem.
Check the content of your .htaccess file. It should look something like this but may have RewriteBase line.
Try putting some junk text - e.g. 'asdfsahjadsfasdf' - into the .htaccess file and saving. Open your site. Does it give you a 500 error? If not, then your AllowOverride All setting isn't working. Check that you have set it in the right place. Remember - it needs to be in your Apache config file, and not the .htaccess. If you don't have access to the relevant config files you might need to ask your ISP to help you answer this question.
If that doesn't uncover the issue, we'll have to tinker with the rewrite rules to see if we can explore what's going on. Try changing this line:
RewriteRule .* sapphire/main.php?url=%1&%{QUERY_STRING} [L]
To this (it will turn the rewrite rules into redirection rules):
RewriteRule .* sapphire/main.php?url=%1&%{QUERY_STRING} [L,R]
Visit http:/www.example.com/dev/build again Did it redirect anywhere? If not, then mod_rewrite isn't working. It should be redirecting to http:/www.example.com/sapphire/main.php?url=dev/build. Is it redirecting somewhere else? For example, has extra junk been inserted into the ?url= parameter? This can sometimes happen if you are running SilverStripe in a subdirectory. In this case, check that the RewriteBase setting is set that subdirectory. Something like RewriteBase /mysubdir.
If you're still unable to get friendly URLs working, then congratulations - you've found a really nasty edge-case! Post the details of what you discovered following the steps above to the SilverStripe IRC channel or Forum on www.silverstripe.org.
Step 1. Put some garbage in your .htaccess file and see if the web server gives you an error.
The point here being to find out - assuming the server is running Apache - whether the .htaccess file the SS installer generated is actually being read. If you've still problems, try asking on the SS IRC channel.