Jump to content

tmcategories causing ssl error


Recommended Posts

Ok, another problem that I missed until moving over to production server (test server only had one level of categories - so until sub-categories where introduced it looked fine.)

 

Anyway, when view in my browser the images are shown with the https prefix but whynopadlock shows all of these images as unsecure - and my padlock in chrome and firefox agree. :(

 

This is my category-tree-branch.tpl file:

<li>
	<a href="{$node.link}" {if isset($currentCategoryId) && ($node.id == $currentCategoryId)}class="selected"{/if}>{$node.name|escape:html:'UTF-8'}</a>
	{if $node.children|@count > 0}
		<div class="tmc_sub tmc_sub1">
		<ul>
		{foreach from=$node.children item=child name=child}
			<li>
{if $smarty.foreach.child.iteration <= 20}
				<a href="{$child.link|escape:html:'UTF-8'}">{$child.name|escape:html:'UTF-8'}</a>
				{* following line updated for v1.5.x *}
				<img src="{$link->getCatImageLink($child.link, $child.id, 'category_default')|escape:'html':'UTF-8'}" alt="" />
				{if $child.children|@count > 0}
					<div class="tmc_sub2">
					<ul>
						{foreach from=$child.children item=child2}
						<li><a href="{$child2.link|escape:html:'UTF-8'}">{$child2.name|escape:html:'UTF-8'}</a></li>
						{/foreach}
					</ul>
					</div>
				{/if}
				{if $smarty.foreach.child.iteration is div by 5}
			</li>
		</ul>
		<ul>
				{else}
			</li>
				{/if}
{/if}
		{/foreach}
		</ul>
		</div>
	{/if}
</li>
Link to comment
Share on other sites

That's a strange one, if the images have https in their links, they shouldn't be causing any issues with the security, not seen that happen before.

 

Would it be possible to provide a link to the page in question, or is that something you need to keep secret for the time being? Hard to debug without viewing it and seeing exactly what it's doing unfortunately.

 

If that's not an option, could you view the source on the page and post the generated html for that block?

Link to comment
Share on other sites

no worries - you can see the problem on either of these two sites:

www.thesafariclothingstore.com or www.theoutdoorsurvivalgearstore.com

 

If I use firefox 27.0.1 (what's in the help about panel anyway) and refresh the cart - the padlock stays locked. This behavior does not happen in chrome - it is always showing a warning indicator on the padlock.

 

http://www.whynopadlock.com shows the tmcategories images as well as the tmnivoslider and an icon image from the wishlist block causing warnings in the ssl indicator also.

 

I am stumped as I have never seen this behavior with the category images before.

 

(link to screenshot from whynopadlock test)

http://prntscr.com/53blsi

Link to comment
Share on other sites

Must say, I'm a bit stumped myself.. I can't see a thing wrong with it

 

Tried a whynopadlock myself, got different results on mine:

 

 

Which at first seemed positive, seemed to indicate that the unsecure images were inside the css, and might be why I couldn't find them in source.. but had a check of the css files, and all of the paths are relative.. so they should be getting treated as secure as well, far as I can see.

 

It's just very strange. My current suspicions are that the problem might be from whynopadlock picking up false positives.. that's my guess anyhow

 

Regarding the chrome one, I've tried on that and did spot some results in the developer tools (press F12 to bring those up), it's throwing the following warning:

 

The page at 'https://www.theoutdoorsurvivalgearstore.com/index.php?controller=order' was loaded over HTTPS, but is submitting data to an insecure location at 'http://www.theoutdoorsurvivalgearstore.com/index.php?controller=search': this content should also be submitted over HTTPS.

 

 

So I think that's what's causing the SSL warning there, not the images. I'm assuming there's some form of ajax in work on the search box, haven't been able to find it from a cursory look, but it should give you something to go on

Link to comment
Share on other sites

Thank You FullCircles... I upgraded the test site at www.thesafariclothingstore.com to v1.6.0.9 and modified the blocksearch code to be 1.6.x compatible (at least I think I got everything now with that one). Not sure if it was the blocksearch mod or the engine upgrade that fixed the problem, but I had missed a 'true' parameter for calling the search form securely in the module.

 

THANK YOU for having a look - not sure how long it would have taken to find this error without your pointing to the search block. :)

Edited by obewanz (see edit history)
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...