When we go to the quick checkout page I try to start setting up an ad and the wheel spins with no action when I select a category. The categories were active previously to our installing the module, and it appears that the categories may not be valid. A friend looking at this came up with the error "The category chosen is not valid." from the page https://www.professionalwashington.com/modules.php?mod=quick_checkout&cmd=vcheckout1&category=85, but I'm not sure how he got to that page on his own. This may or may not have something to do with this issue, but we just had the SSL certificate installed, and though the address says https, the certificate does not appear to be active. Thoughts on this?
Taking the s out of the URL does make it work. But of course we don't want to allow transactions without it
So then, my next recommendation in trying to isolate the issue would be to test it with the default template. First with the secure link, if that fails then try it without. If it only works without the security, then obviously the issue is with the https/SSL/certificate. None of which would have anything to do with 68 Classifieds or TemplateCodes Quick Checkout.
As Mike says the full process should be this Default template and no QC module installed - does it work with https Default template with QC modules installed - does it work TC template without module installed - does it work TC template with module installed - does it work Otherwise it is impossible to know whether it is your SSL certificate / server setup, the template or the QC module itself.
We're going to be using the purplicious template for the site. We tried using the default template and one of the Sigmas and that didn't make a difference. Turned off the QC and we're still not hitting the secure site. It seems like the ISP is trying to push this off of the certificate, though. This is the message that I get from my ISP:
There may be validity to what your hosting service is saying if you have added additional links into your template. One of the items that I have run into on many client sites is the addition of display ads, such as google adsense ads. If you have used the smarty call for the an url like this: {$smarty.const.URL} instead of this: {$smarty.const.URLS} on pages within the checkout process could cause this as well (also the layout.tpl, which is used on ALL pages). I have also seen this in some modules as well that are used during the checkout process, like adding a map or some other special field in the listing that aren't considering the fact that the site might be in secure mode. Although I have seen the warning of some links not being secure, I have not seen the server FAIL to continue the process or connection to the web page(s) due to that. That claim by the hosting service seems bogus.
I did just test the certificate through sslshopper.com and everything checks out as installed. I added one link to the layout.tpl page, but it wasn't added to any of the other templates so that doesn't seem to be the issue. I did add the S to smarty construct call just to be safe, though not all of the links use URLS on the template. I've also looked through my install and checked permissions, and everything seems to be in place. I'm just not sure where to go from here.
I doubt very much that it is an issue with any template. This certainly exists in TC templates and in the default. {if $smarty.server.SERVER_PORT == '443'} <base href="{$smarty.const.URLS}/" /> {else} <base href="{$smarty.const.URL}/" /> {/if} There should not be an issue either for non https pages. Its the first time I have heard that all pages need to be https throughout a whole site. Why would displaying an advert need to be secure or your home page? There is no transaction going to take place. This is specific to your hosting provider from what I can see. Otherwise you are going to have to find every instance of a non https url. I would just dump them and run with Hostgator. You will not have any issues afterwards.
Perhaps, you are misunderstanding what I was referring to and/or how the code you posted works. The code you posted simply sets the base href. The base href is only used for relational urls. That's what allows you to make an url simply, href="uploads/upload.doc", rendering the full url from the base like this: http://yourbaseurlref/uploads/upload.doc Which is why I previously referred specifically to smarty url calls, because if you put a full url in, that over rides a base reference. As an example, if in your layout.tpl, you place a link like this, <img src="{$smarty.const.URL}/myads/advertise.gif" /> If you are then in checkout (which triggers the secure base href), The Advertise with us link is still not a secure link. The same thing if you have an affiliate advertisement on the page like this: <img src="http://myaffillitatesite.com/affiliate.php?id=B4Z2WD&ad=8KDFLKH> In both of these examples, because it has the "http" in the href or the src, that over rides a base href. So in the case that these are in the layout.tpl template file which is used on every page in the 68 Classifieds site, these links and/sources WILL generate a not secure message, because they are NOT secure links. Don't misunderstand what I am saying, because I am NOT suggesting or indicating that ALL links throughout your classified site have to be https. Not in any way, shape, form, or fashion. What I am saying is that if you are using an SSL protocol Which is triggered by checkout, then all links on any template file during the checkout process does have to be secure links. That includes links in your layout.tpl template file, which again is USED during checkout. The most common issue that I've run across is a banner ad that is in the header of the layout.tpl which is NOT a secure link. I just used the same smarty code logic that is used for the base href, to NOT show the ad if it is in SSL mode. Like this: PHP: <div id="ad_container"> {if $smarty.server.SERVER_PORT == '443'} {else} <div id="h_leaderboard"> google ad code goes here </div> {/if}</div>
If he sends his login details to me and admin control panel details I will take a quick look to see what is breaking it. I notice just looking at the source of the page, the url is not https where the QC module is declared. Its still http. However, I have looked in the QC module - the hooks.php file, we have this - lines 43-46 $url = URL; if (defined("URLS")) { $url = URLS; } This should be working if defined("URLS") is true. Interesting to just replace these 3 lines with $url = 'https://www.domain.com'; This will force it to take the value of URLS. So still not sure if this is the issue but even if it is not, something would appear to be breaking with URLS either in the core software or in the TC module.
In most cases, a SSL warning occurs because some element on the page that has a src value or href value (like an image, an external javascript file, an external css file, an anchor tag, an external web service, google ads, etc) points to an 'unsecure' value. Many hosts want you to place elements in a secure area. For example, our hosting has an 'http_docs' location but also offers an 'https_docs' location. However, the most thorough thing to do is take a look at the source code of the page that's throwing the error and make sure that all the values pointing to elements of the page use absolute values (including the 'https://') instead of relative values. Hope this helps.
Also, on this page, even though "https" is in the address, if you view the source code, you can see the base tag is assigned with a "http" value. Have you included your SSL URL in your main settings in administration?
What is also interesting in the URL that you posted is that although the URL you posted is hard coded to be in SSL protocol with the https:// the browser is not registering the fact that it should be in SSL protocol (e.g. no lock) which indicates that the server is NOT triggering the certificate or SSL protocol. If this is the case, which it appears that it is, then even IF the URLS is set in admin, it still would NOT be triggered, because since the server isn't using the secure port by protocol, the secure URL wouldn't be triggered since that is based off of the port not the url text of https. In FireFox, when trying to access the page in https, it redirects back to http as it can NOT establish a secure link. These things all indicate that this is indeed an issue at the server level with the SSL protocol and the certificate.
We removed the address from the secure line entirely in the control panel so we could do further testing, but I have put it back in so you can look at the source code. David, I am emailing you login information for the ftp site.
OK but Mike has a point. This would mean that the line I mention for testing if it is URLS is probably not failing. As Blair says 1. Do you have https set in your main settings of the admin panel? 2. Have you changed the code above that I gave to force it to use the URLS value? Do send your admin login too. You did not do so. Impossible to proceed.
Well although I cannot log in and test the rest of the steps I can say 100% that the URLS is defined correctly within the header generated by the QC module. I just displayed it on your template using an echo out within the module so it is not the code I supposed earlier.
I agree completely. Now that the URLS is set in the admin, all of the secure URLs render correctly, however the base href is still NOT in secure mode, because it isn't using the secure SSL port by protocol. This is definitely not the script that is causing an issue. The server is not following SSL protocol. Not using the secure port. So either the certificate is not installed correctly or the web server is not configured correctly for SSL.
