Earlier today I asked a question on SO regarding a redirect in the htaccess file. The answer given to me was actually correct, but because I had failed to clear my cache, my browser was still using a cached version of the htaccess file without my update. After clearing my cache, the redirect worked as expected. I've just installed an SSL certificate for a different client and added some rules to redirect from HTTP to HTTPS. However, I'm thinking about the issue I had this morning. The customer, as well as their return visitors, would have cached the old htaccess file and therefore won't use the updated version. If this was a stylesheet or an image, I'd just add a version number, change the file name, or change the path, to "force" the update. I obviously can't do that here. Is there anything that can be done to force return users to use the updated htaccess file?
There is nothing you can do about other peoples cache I'm afraid. Eventually the cache will refresh and display the new changes. All it takes is a refresh of the page.
You can tell your website not to cache by using:
ExpiresActive On
ExpiresDefault A1
Header append Cache-Control must-revalidate
But I don't really see much point in doing that unless you're making constant changes to said page. If a client asks you to make a change that requires their cache to be reset, then just tell them to do so, so that they can see it.
Related
I am working on an E-Commerce website project which I created in localhost. It worked fine, until I moved it online.
Since I moved it online, I've had issues accessing the admin page and the index.php. I've managed to make the admin page work and can now access the backoffice without any issues, but my index.php still shows me an "error: too many redirects1" page.
What's happening?
Main page of my website is stuck in a redirecting loop (chrome error message : this url tried to redirect you too many times)
Everytime I reload the main page, the url switches between www.mydomain.com and mydomain.com (might be an htaccess issue?)
What I've done to try and solve the problem:
I have checked everything in core_config_data table to make sure
the right urls are written in web/secure/base_url and
web/unsecure/base_url. They are.
I have manually cleared the var/cache and var/session from my
FTP.
I have cleared all cookies / cache from Chrome / Firefox
I have reuploaded the files and database multiple times, thinking it might be due to a corrupted file from the upload.
I have tried to edit the htaccess, but it didn't change anything.
What should I do now ?
I feel like I've tried everything.
As it's my first time with magento, I'm sure it's some dumb thing I might not know about, but I've read nearly every single post about this kind of issues on this website and haven't found anything to resolve it.
So I'm asking you. I'm willing to try every single idea you throw at me, as I've been stuck on this issue for a while now ^^
Thanks for reading :)
Weird, It seems that You make everything right. Try to find and update all url settings in core_config_data: select * from core_config_data where path like '%url%'.
You can try update web/url/redirect_to_base config to 0 (if you have 1).
Remember to clear cache.
I'm new to .htaccess file.
My site is hosted on 1and1 and by default it shows www.mydomain.com/defaultsite when nothing is uploaded to my account. Now I've uploaded my wp site and have managed to make it go to index, but if someone inputs in the url www.domain.com/defaultsite he will still get the wrong place.
How can I manage this issue with .htaccess file so that any request to defaultsite will take the user to www.mydomain.com ?
I'm not a 1and1 user, but this could be a DNS cache issue. First, check your document root for the presence of a directory called defaultsite. If it exists, remove it. If not, then you can attempt removing it using mod_rewrite. Insert this rule immediately after RewriteEngine On in your .htaccess file:
RewriteRule ^defaultsite/?$ http://yourdomain.com/ [R=302,L]
If it's working for you, you can safely change 302 to 301 to make in permanent and cache-able.
I have also seen comments referring to an index.html file in the document root. If you see one, delete it - it could be that, internally, 1and1 maps defaultsite to index.html.
Also, it will help for you to clear the cache in your browser when testing. If using Chrome, you can open the Developer Tools (Ctrl+Shift+I), click on the settings cog at the top right of the panel that opens, and check 'Disable cache (while DevTools is open)`.
I had a similar issue and was pulling out my hair trying to figure this out. 1&1 is hosting while Namecheap holds my domain. I was able to access my page without /defaultsite on Safari and mobile Chrome. But on desktop Chrome I was being redirected to /defaultsite.
To remedy this I cleared my cache, flushed my DNS cache, and cleared my browsing history. Not sure if the latter 2 were necessary but having done all three it did help resolve this issue.
Ok I'm extremely noob to nginx and did something very stupid. I wrote the following code in my sites available file. Deleting it doesn't seem to undo it.
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
rewrite ^/(.*)/$ /?page=$1 last;
rewrite ^(.*[^/])$ $1/ permanent;
}
I wrote this before I fully understood what it meant and since have removed it from my configuration file. Despite removing this it looks like it is still effecting one page of my website. I have tried different browsers other than the one that I loaded this page on when the rule was applied and it is still not serving the images correctly.
How can I undo this?
The site is not yet public so I'm not worried about other people's browsers catches still redirecting after this issue is resolved.
Is there a place in my server that is continuing to redirect despite the rule no longer in my sites-available and sites-enabled folder? It is a linux/ubuntu server and so far this is the first site that this server is running.
Thank you for any help or ideas on how to solve this!
According to the rfc2616 section 10.3.2 about http status 301
The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.
A lot of browsers use that to cache the response locally, so that it doesn't waste another request when calling the same URL, unlike 302 which redirects but doesn't cache.
To solve this you just need to clear the local cache, and not even the whole cache, if you did this today you could just clear today's cache and every thing will be back to normal.
If you have add this location block to your/one of your site conf in nginx/sites-available and thereafter symlinked the file to nginx/sites-enabled, it can only be in the nginx/sites-available/site.
However if you copied /nginx/sites-available/site to nginx/sites-enabled/site you also have to delete the file in sites-enabled...
To be sure, did you reload nginx after deleting configuration ?
I’m fairly new to the Magento platform but I have a decent amount of experience in web development on apache servers.
A few days ago I was asked to look into an issue that was first made aware of with failing filters.
I had a look at the google analytics data and it seems the SEO friendly URLs have all stopped displaying. The navigation URLs still use friendly words however on the page return the URL is redirected to a basic catalog URL.
http://www.camera-camera.com/cameras-and-accessories.html
instead now it goes to
https://www.camera-camera.com/index.php/catalog/category/view/id/9
I checked the admin config. The Web > SEO URL rewrites are set to YES
I toggled them to No saved and back to yes then saved. Tried clearing the catalog URL rewrite cache
Checked the htaccess file and it hasn’t been touched for months.
Emptied the core rewrite table and reindexed it.
So I’m outta ideas now, was hoping some of you more experienced users can have some input as to what else I can check.
I also found it strange that the URL is now ignoring postback parameters. If you look at their filters they are simply an a link to the same page with a post parameter. This gets striped and ignored now might be related?
A file restore was on the day it happened. Any files I should check it against?
Thanks for any help you can provide !
I just discovered that it was related to HTTPS. I didn't notice but seems the site keeps redirecting to HTTPS even though the filter links etc are pointing to HTTP, in the redirect the parameters are dropped. Now to figure out why its going into HTTPS
We have a black friday sale tomorrow and our site is hosted on bluehost, and is built on Magento CMS and our checkout system is totally blank.
When you click "proceed to checkout" when in the shopping cart, ourwebsitedomain.tld/index.php/checkout/onepage/ is blank.
We recently made some speed changes to our site, and we have undone all of those, to no avail, including editing the htaccess file.
We have tried everything in the Magento forums, nothing's working.
We think it might be a server issue, but unfortunately bluehost is not open today because it's thxgiving, and we cannot backup or restore to an old version of the site because our server is "under maintenance".
We are not sure if it is something we have done, or if it is a server issue.
We send this to bluehost:
// Here are our thoughts:
Maybe it's an SSL issue since the URL is https: (oursitedomain.tld/index.php/checkout/onepage/ is the page that will not pull up, won't even redirect). The ssl certificate has not expired, but coudl there be something else wrong with it?
Maybe it is another server configuration that we need reset? can you see if there is anything else wrong with the server?
We cannot restore to an old backup of the site because the backup and restore version console in cpanel is not working, says the site is under maintenance. At the very least , we need to backup an old version of the site, and get the shopping cart working.. //
Any ideas anyone has would be huge.
Even if there is a workaround, that will be fine. We are trying to bypass onepage with paypal or google, but no luck yet. worse case scenario we will throw a page up saying the checkout is down, the sale is postponed until next week, etc, or for customers to call in.
A very common (but, alas, not the only) cause of blank pages is PHP's memory limit. Your .htaccess file should have a line like:
php_value memory_limit 128M
Try increasing this value to 512M. You can confirm what the actual setting is both before and after by creating the following PHP file in your Magento folder.
<?php
phpinfo();
Then simply type the address of this new page (eg. "ourwebsitedomain/phpinfo.php") in your browser and look for "memory_limit".
If you want to diagnose the problem correctly then work on eliminating possibilities. Go to "https://ourwebsitedomain/" without the "checkout/onepage" bit and if something shows then you know it's not a problem with SSL.
If the admin section (not cpanel) is working then you have the option of disabling the secure "https" address temporarily. It's not as safe but not required when using paypal, also it's understandable if the alternative is missing out on the biggest shopping day of the year.
PHP pages only go blank (from fatal errors) when display_errors is turned off. Go into /index.php and scroll down near the end of the file. Uncomment the line
ini_set('display_errors', 1);
and let us know what the error you receive is, then we can go from there.