X-Cart forums

[DavyMac]

Originally Posted by carpeperdiem

After all that...

One file needs to be patched in xTreme Gear:

/skin/xtreme_gear/customer/main/register.tpl

I had to patch /skin/xtreme_gear/customer/dialog_message.tpl too

[carpeperdiem]

Originally Posted by DavyMac

I had to patch /skin/xtreme_gear/customer/dialog_message.tpl too

Sorry -- you're right.
SInce I have CFL_ System Messages for X-Cart, the patch wasn't needed.

For everyone else, 2 files.

[albertchui]

Originally Posted by carpeperdiem

Albert,
Use firebug.
Identify the insecure images.
Most likely, they are xtreme placed images in /images/directory.
Don't use these images.
Instead, hard code the images to a path, such as:

<img src="{$AltImagesDir}/custom/

This is not a tutorial in how to hard code an image --
The point of this is to explain that xTreme's images if placed using the interface, will not be secure at https.
So simply hard code image paths to a skin images dir, such as $ImagesDir or $AltImagesDir

Got it?

i am not familiar with that, do you know what file need to be adjusted, i contacted them and seems they denied it's their image path caused it, below is their respond:

We use the same signin/register links as the standard X-Cart skins use.
Just compare 2 files:
/skin/common_files/customer/authbox.tpl
/skin/xtreme_gear/customer/authbox.tpl
and you will see that there is no difference.

[carpeperdiem]

Originally Posted by albertchui

i am not familiar with that, do you know what file need to be adjusted, i contacted them and seems they denied it's their image path caused it, below is their respond:

We use the same signin/register links as the standard X-Cart skins use.
Just compare 2 files:
/skin/common_files/customer/authbox.tpl
/skin/xtreme_gear/customer/authbox.tpl
and you will see that there is no difference.

No. The insecure images on https pages have nothing to do with those files.
The images that xtreme still serves http when secure are in the file,

/skin/xtreme_gear/customer/banners-quicklinks.tpl

Some of these images, are served as http, even on https pages.
Simply re-code the offending images using relative image paths, such as:

<img src="{$AltImagesDir}/custom/image-name.png" width="280" height="150" alt="image name" title="image title" />

Obviously, this an oversimplification.

What you need to do:

1. Go to the https page that is tossing the error.
2. View page source.
3. Search for "http:" -- you will see the offending image(s)
4. Change the paths to the offending images so they use a relative path, such as {$AltImagesDir}

You may also find insecure images served from file:
/skin/xtreme_gear/customer/head.tpl

(the header logo)

The <problem> here is that xtreme interface is very convenient -- and easy to add/change images -- so use the tool for development -- then hard code the relative image paths once you like your design.

These images should not be served from an absolute path if they will be used on an https page. Easy enough to fix.

[albertchui]

Originally Posted by carpeperdiem

No. The insecure images on https pages have nothing to do with those files.
The images that xtreme still serves http when secure are in the file,

/skin/xtreme_gear/customer/banners-quicklinks.tpl

Some of these images, are served as http, even on https pages.
Simply re-code the offending images using relative image paths, such as:

<img src="{$AltImagesDir}/custom/image-name.png" width="280" height="150" alt="image name" title="image title" />

Obviously, this an oversimplification.

What you need to do:

1. Go to the https page that is tossing the error.
2. View page source.
3. Search for "http:" -- you will see the offending image(s)
4. Change the paths to the offending images so they use a relative path, such as {$AltImagesDir}

You may also find insecure images served from file:
/skin/xtreme_gear/customer/head.tpl

(the header logo)

The <problem> here is that xtreme interface is very convenient -- and easy to add/change images -- so use the tool for development -- then hard code the relative image paths once you like your design.

These images should not be served from an absolute path if they will be used on an https page. Easy enough to fix.

many thanks for your info, i found that most of the images are banner image with full path, but how can i hard code them, i have no idea which file should be modified.

i also found in some var/cache, will these affect as well:

<script type="text/javascript" src="http://www.iphonecasestudio.com/var/cache/2.521cd28594526ba33a652f290b1f52f3.js"></script>
<link rel="stylesheet" type="text/css" href="http://www.iphonecasestudio.com/var/cache/2.b6b6b944c0a52645af1fc0174f949ed5.css" />


many thanks for the help.

albert

[carpeperdiem]

Images and css/js have different methods. Let's ONLY talk about images for now.

YOUR GOAL is to have your header or banner or footer images not trigger a secure warning in a customer browser if page goes https. Yes?

1. - understand how xTreme is calling the images.
then comment out the code in the calling template.

2. upload your images to a skin images directory {$AltImagesDir}

3. Replace the image call with the new path.

If you don't know html, this will be challenging, and I would ask that you NOT try this at home, and possibly get professional help.

[DavyMac]

The navigation images used on the tabs are causing me problems during website speed tests. Specifically, for the following images I'm getting the "Serve the following static resources from a domain that doesn't set cookies" warning:

/skin/xtreme_gear/images/button-slide-next.png
/skin/xtreme_gear/images/button-slide-prev.png
/skin/xtreme_gear/images/tabs-arrow-bottom.png

These images are served up from a cached css, but so are other images and they don't raise this performance warning, so I'm at a loss why this is happening.

Anyone got an idea how to prevent these from raising the warning?

[carpeperdiem]

Originally Posted by DavyMac

The navigation images used on the tabs are causing me problems

I had a crash and burn/give it up experience with the "recently viewed" module in the tabs on product pages. I asked TXS support to help -- but before I made a thing about it -- I simply bailed on the recently viewed module entirely on product detail pages. It was just too cluttered for my taste. If I ever want "recently viewed" on my product pages,

I just tested the recently viewed tab on the CAT page, and it is fine -- and in speed test (http://www.webpagetest.org/) - no secure warnings or cookie warnings.
What pagespeed test tossed you this warning? I can test on my site...

[DavyMac]

Originally Posted by carpeperdiem

What pagespeed test tossed you this warning? I can test on my site...

I've been using http://tools.pingdom.com/fpt/ as I find it the easiest to understand - www.webpagetest.org/ probably tells me more except I don't really understand it

[DavyMac]

When you check the box for "Enable "AddThis" feature" on the Main page > xtreme Gear - Addthis Setup (product page) the xtreme_gear template populates the global variable $xg_extra_meta with open graph tags, which are not only used by facebook but Pinterest's rich pins.

I discovered that with the "addThis" feature enabled my product pages were failing Rich Pins Validation . The reason for this is the open graph tags set within an encrypted file within the xtreme_gear template used the descriptor "name" instead of "property", e.g. <meta name="og:type" content="product" />

When I changed the descriptor to "property" my pages passed validation.

Here is what I did -
Within file /skin/xtreme_gear/customer/meta.tpl

After line:

{foreach from=$xg_extra_meta item="xg_meta"}

Replace:

{$xg_meta}

With:

{$xg_meta|replace:'name=':'property='}