Not loading few icons when it loads 1st time at any browser in OpenCart 2.0.3.1, also add to cart button dose not works at 1st time load.
Site URL- http://www.allcardecor.com/
I tried clearing my cache, reinstalling all my modules.
You're having a cross-domain issue with your request. When I load that page in my console I see this error:
Font from origin 'http://allcardecor.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.allcardecor.com' is therefore not allowed access.
You'll note that your site http://www.allcardecor.com, is calling on the FontAwesome files from http://allcardecor.com. The browser is seeing this as two different domains.
You'll want to setup a canonical name for one of the domains in your DNS so that it's recognized as a legitimate alias for the other.
https://en.wikipedia.org/wiki/CNAME_record
You should also setup CORS so that you can call scripts from approved sites without running into cross domain errors:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
For someone who might still need this. The problem is due to cross domain issue as Jocko has pointed out.
Another way to fix this is to redirect all requests to your site to particular subdomain, e.g. yourdomain.com => www.yourdomain.com and link all resources as such.
On Apache, in .htaccess file, add the following lines:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [L,R=301]
On Nginx, checkout this link.
Related
I have been trying to redirect all of my website's pages to a new website but would like to rule out one single page as an exception. This is the code I am using:
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/en/planning/$
RewriteRule .* https://www.target.example/ [R=301,L]
As you can see, I am trying redirect all pages to a new domain but leave the /en/planning/ page intact. However, when I use the code above, all pages were redirected without an exception. From the server, I found out that /en/planning directory does not really exist. The template to the page however, exists in a different directory.
They are here > /home/indo/src-20220316-200538/apps/front/templates/planning/views/planning-view.html.
The header & footer of the page was built in a different directory.
Meanwhile the public_html of the website lies on /home/indo/www/
In this directory, there is a shortcut to the original location that is named "front". Here is a screenshot from WinSCP:
So, based on this, what is the best way to make /en/planning/ as an exception? the website I am trying to redirect is http://source.example/ to https://www.target.example/. In addition, the website is running with Fat-Free Framework.
I have been stuck here for weeks and this is frustating.
RewriteCond %{REQUEST_URI} !^/en/planning/$
RewriteRule .* https://www.target.example/ [R=301,L]
You no doubt have other directives (a front-controller pattern) that rewrites URLs of the form /en/planning/ to the front-controller, which performs the underlying routing. Your front-controller might be index.php, or something else.
The "problem" here is that when the request is rewritten to the front-controller, the REQUEST_URI server variable is no longer /en/planning/, but is updated to /index.php (or whatever the front-controller is) and the redirect occurs, since the negated condition is now successful. The rewrite engine makes multiple passes, the undesirable redirect is likely occurring on the second pass (the exception is successful initially).
You need to ensure that the you only check the originally requested URL and not the rewritten URL.
However, you also likely need to make an exception for any static resources (images, CSS, JS, etc) that are used by this page, otherwise these would also be redirected.
Try the following instead:
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{REQUEST_URI} !^/en/planning/$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ https://www.target.example/ [R=301,L]
The check against the REDIRECT_STATUS environment variable ensures that we only test the initial request from the client and not the rewritten request by Apache.
The additional check against REQUEST_FILENAME ensures that the requested URL does not map to an actual file (a static resource). However, the obvious downside of this is that static resources (for other pages) are not redirected.
You also need to make sure the browser cache is cleared, since the erroneous 301 (permanent) redirect will have been cached by the browser. Test first with 302 (temporary) redirects to avoid potential caching issues.
I would add, however, that a many-to-one redirect to the homepage, as you are implementing here is generally bad for SEO since search engines (particularly Google) will see this as a soft-404 and not honour the redirect, ultimately dropping the pages from the search results.
I'm having difficulty finding out what it means when I have the response header Non-Authoritative-Reason : HSTS
I have searched a lot but just came up with some explanations about HSTS (redirection from HTTP to HTTPS). Can anyone help me with that? By the way I'm using Chrome.
Thanks
The server you are trying to connect with uses strict-transport-security (HSTS) to ensure https only is used with this site rather than the default http.
This means if you enter http://www.servername.com then Chrome will automatically convert this to https://www.servername.com.
This is a security feature to prevent use of http, which is unencrypted and which can be read and altered by a hacker. This can be set by the server telling Chrome (via a special HTTP Header sent in response to requests) that it uses HSTS. This setting is then cached by Chrome for the given amount of time as defined in the max-age value in that header. Additionally the site owner can submit their site to a preload list that is automatically included in Chrome - which protects even the first visit as normally you need to visit the site to receive the header to activate this.
The way Chrome shows this in the network tab is by creating a dummy 307 response with a redirect to the https version of the address. But that's a fake response and is not generated by the server - the reality is Chrome did that internally before the request even went to the server.
To clear this setting for a site you can type the following into Chrome's URL field: chrome://net-internals/#hsts and then search for your site and delete it. You may also set this at a top level domain and include subdomains so you may need to delete from there. Alternatively you can just alter your server config to publish the header with a max-age of 0 and revisit the site to clear this, then stop publishing the header, which can be helpful for other browsers where it's not quite as easy to clear this.
Note you cannot clear this setting if a site is on the preload list as this is embedded in the web browser's code. The site owner can submit a request to be removed from the preload list but this takes several months to go through the release cycle for Chrome and no defined timeline for other browsers. Chrome also provides no way to override preloaded settings - for security reasons.
Some additional info to BazzaDP's answer...
The Non-Authoritative-Reason : HSTS returned in the response is not something you have configured, but rather Chrome itself. Since Chrome hijacks the request, Chrome will also add this particular header to tell HSTS is enabled. Looking at the network tab, you will see the fake 307 response with this header set.
All this is done since you included the Strict-Transport-Security header on your server.
If you want to go all in, here's the HSTS preload list
According to MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security):
The Strict-Transport-Security header is ignored by the browser when
your site is accessed using HTTP; this is because an attacker may
intercept HTTP connections and inject the header or remove it
And the HSTS Preload list deployment recommendations mention:
Add the Strict-Transport-Security header to all HTTPS responses
The HTML5 Boilerplate shows how to only set Strict-Transport-Security over HTTPS (in apache):
# Set 'Strict-Transport-Security' over HTTPS only!
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ %{ENV:PROTO}://%1%{REQUEST_URI} [R=301,L]
</IfModule>
My goal was to prevent the user from having to type in .html in order to access the page they are looking for on our site. On other sites I have left the file name as /pagename.html and the user could type in only /pagename and the page would load. For some reason, that was not possible with our server settings (GoDaddy Plesk Parallel server) so my workaround was to create a folder for every page I wanted and the actual file would be /index.html. My goal was accomplished and now the user doesn't have to include .html to load the page. The problem now is that Google and SEOmoz reports are reading tons of duplicate content. The reason is that the user could type in 3 different things to get to the same page - technically 6 if you include "www":
sitename.com/services
sitename.com/services/
sitename.com/services/index.html
Search engines are displaying it the 2nd way (http://sitename.com/services/) and if you type it without the "/" it redirects to showing it with the "/". SEOmoz is saying I have 301 redirects for each page in order for that to happen but we never manually did that.
I've tried creating an .htaccess file with redirects from sitename.com/services/ to sitename.com/services but the page won't load because of too many redirects.
Did I break some big rules setting it up this way?
Please note that "sitename.com/services/" is just an example of a page and our entire site of 50 pages is set up in this nature. The actual site is http://www.logicalposition.com.
The preferred way is to set up your server to manage the URL handling. If you are on an Apache server, for example, you could use the following suggestion and create/change the .htaccess file to get the desired affect.
http://eisabainyo.net/weblog/2007/08/19/removing-file-extension-via-htaccess/
The most straightforward way is to use Apache's .htaccess (which if I remember correctly GoDaddy allows access to, though I may be wrong) to do redirects.
See this post: https://stackoverflow.com/a/5730126/549346 (mods: possible duplicate?), which directs you to place something like the following in your .htacess file:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)\.html$ /$1 [L,R=301]
Firstly it sounds like you haven't done basic leg work to minimize this. You need to decide do you want www.samplesite.com or just samplesite.com? Then you can very easily set this with .htaccess (see this handy tool). This will mean at most you will have three variations, not 6.
I would take #Jassons's suggestion and use URL Handling - 2 of my clients currently use GoDaddy and both of which use this method so should be fully supported.
Some more helpful links for URL Handling/htaccess rewrites (although note: setting up 301 redirects takes time, patience and careful monitoring of crawl errors on Web Master Tools, so URL Handling is preferable!)
http://net.tutsplus.com/tutorials/other/using-htaccess-files-for-pretty-urls/
Extreme example, but still relevant :) Handling several thousand redirects with .htaccess
Edit Forcing trailing slash
You can easily force the trailing slash to appear by using the Rewrite rule
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*) $1 [L]
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ $1/ [L,R=301]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?category=$1
I think you have already done that in part, but what you will notice is there is a 301 redirect header sent, that means the as spiders visit your site they will update the URL to have the trailing slash - it won't be over night. You might be able to use Web Master Tools to speed things up in terms of changing the URLS.
Source: In part this website, it give's you a good explanation of how it works
hello i have the following problem regarding mod_rewrite:
i have build a page that is called example.php
now i'm still searching for a rewriterule for the following issue:
because of different languages but the same content of the page example.php i would like to have a rewriterule when an user is entering for example site.com/beispiel.php
what will be the same word for example in german. so there is only one page. but the imaginary url site.com/beispiel.php would be the same content.
so if there is someone who knows how to solve this problem i really would appreciate. thanks a lot.
I was thinking about it :
If you use the google translator as shown in translate a PHP $string using google translator API
Then redirect from PHP to
www.yoursite.com/translate.php?translated_language=keyword_from_script
Then use a mod_rewrite from the last answer with that parameter, it should work?
Redirections and internal redirections are two different things.
An HTTP Redirection with a code 302 or 301 imply several HTTP request and the user will see at the end that he has been redirected to /example.php. An internal redirection means serving one file B on the server for a file A requested, without the user knowing it.
Internal Redirection does not need mod-rewrite's rules. The Alias and AliasMatch directives could be used to map some requested files to a real file.
Alias /beispiel.php /path/to/my/docroot/example.php
External Redirection could also be performed without mod_rewrite, by using Redirect and RedirectMatch directives.
Now you could also use mod_rewrite to perform these two types of redirections (internal & external).
# internal alias
RewriteRule ^beispiel.php$ /path/to/my/docroot/example.php [L]
# Or external redirection, with a R tag
RewriteRule ^beispiel.php$ example.php [L, NC, R=302]
With external redirections qlways Start by trying some rewriteRiles handling 302 redirections. When it will be working you could use 301 redirects as the browser store 301 results and do not ask anymore before restart.
If you have a big number of rediirection to perform and you are not stuck with .htaccess files (i.e. you can edit the real apache configuration files), you could have a look at RewriteMap to speed-up your rewriteRules.
I just noticed today that a website I am creating has the WWW or non-WWW problem. If you go to http: //www.taskconductor.com, it is a different page with the same content as just http: //taskconductor.com.
If you were to login (username: show#412customs.com, Pass: tester) at http: //www.taskconductor.com, then try to go to http: //taskconductor.com (without the WWW), it will make you log in again. Then as you can see, when you check your cookies, you can see that there are two sets of cookies. One for http: //taskconductor.com and one for http: //www.taskconductor.com.
I have seen that this is a problem, but do I need to make a redirect? and if so, does it have to be index.php? I would really prefer to have all of my main content on index.php.
How can I get around this?
Do you know what web server you are using? If you're using apache, you can rewrite the URL in the .htaccess file. This will allow you to funnel all your traffic to with your non-www domain. I did a quick google and found this sample code:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
Source: http://yoast.com/how-to-remove-www-from-your-url-with-mod_rewrite/
I was able to set my php "setcookies" to have a specified domain.
My original setcookie string was: setcookie('ver_ame', $email, time()+2592000);
This only allowed the cookie to be set on whatever type of page it was on. If it were on http: //taskconductor.com it would set the cookie for that, and also the same if it were http: //www.taskconductor.com.
If your setcookie string is: setcookie('ver_ame', $email, time()+2592000, "/", ".taskconductor.com");
The additional "/" shows the cookie to work on any of the directories under the root. The ".taskconductor.com" part would be showing which domain to use. The fact that it has a period before the web name shows that this cookie will work on any subdomain or its own domain.
Thank you all for the responses and help! It all works now! THANK YOU!
Better than using URL rewrites is to set your cookies to work for subdomains. For example, if you set the cookie for mydomain.com, then it will not work for sub.mydomain.com. However, if you set the cookie for .mydomain.com (notice the period), then it will work for mydomain.com, sub.mydomain.com, foobar.mydomain.com etc.
If you explicitly set your cookie domain to taskconductor.com (no www), then the same single set of cookies will be used for both the www and the naked domain. You'll just need to modify your PHP to specify a cookie domain.
I would recommend you do as others are suggesting and do a redirect to whichever version you want to use as the canonical URL. It's bad practice to have duplicate content across multiple (sub) domains. But, it's also a good idea to understand the domain scope of cookies that you set.