First, you may want to create and activate a new store version using stock templates. This will enable you to work on tracking down the cause of the security errors on the "broken" store version while still operating your storefront without security errors. Once you have corrected the code on your custom templates, you can reactivate your custom store version.

You can also use the "Revert to Original Version" option in Store Design to revert to the original ProStores code. WARNING: This deletes any and all of your custom elements. It also eliminates the code or elements responsible for the triggering security warnings. But if you are having trouble tracking down the cause - a fresh start might be your best option.

The two most common causes of security errors are adding images to secure pages that are not securely hosted and using standard html references (http://) when a secure reference is required (https://). So a good place to start is hosting any images you want to add to your header, footer or any of the checkout pages in your ProStores hosting account and referencing them with SSML tags.

Here are more detailed examples of the most common causes of security issues and possible solutions.

Images added to the header, footer, or checkout pages

When adding images to the header, footer or any of the checkout pages, you should host the images in your ProStores hosting account and reference them with SSML tags.  By using this approach, ProStores will automatically change how the image is rendered based on the type of page (http vs. https).   

To display a "Shared Image" - images uploaded as category photos, manufacturer logos, or favorite’s icon and stored in the "/images" directory, use code like this:

<ss:image source="$store.images['ImageFileNameHere.gif']"/>

To display a "Store Logo" - image uploaded as a store logo or created with the ProStores Store Design Image Generator tool, use code like this:

<ss:image source="$storeVersion.storeLogo"/>

To display a "Store Design Image" - images used as site design elements on templates such as images, buttons, boarders, backgrounds, etc. and stored in the "/images/StoreVersionNameHere/" directory, use code like this:

<ss:image source="$storeVersion.images['ImageFileNameHere.gif']"/>

Many browsers will generate security warning messages if a secure (https) page includes images that are accessed with an unsecure path (http).  Below are examples of links that work fine for unsecure pages (http), but not when the page is rendered under SSL security (https).  Do not use these types of links for displaying images on templates that use SSL security during checkout.  This includes the header and footer templates.

<img src=http://www.yourdomain.com/ImageFileNameHere.jpgf>
<img src="/images/storeversionname/ImageFileNameHere.jpgf">
<img src=http://www.someotherdomain.com/ImageFileNameHere.jpg>

If you are not able to host the image in your ProStores hosting account and need to use an "image URL" to display an image on your page, you have three options:

• Use secure path (https) like <img src="https://www.asite.com/imagename.jpg">
  • The external site and path must support https, test it before adding to your template
  • The image will always be served through the slower secure path, even when not necessary
• Use SSML tags to alternate image URLs between http and https pages as necessary like this:

<ss:if test="$request.getScheme() = = 'https'">
 <img src="https://www.asite.com/imagename.jpg">
<ss:else/>
 <img src="http://www.asite.com/imagename.jpg">
</ss:if>

• Consider only using the image on templates that are never displayed with SSL security (not on the header, footer or checkout pages)

Adding tracking code, security seals, banner ads, bookmarking tools, social networking tools, video, slideshows or other items using external JavaScript to the header, foot, or checkout pages

The same principles mentioned above for images also apply when adding website items or tools that utilize external JavaScript files. Store visitors may encounter various "security" warnings on SSL secured pages if the code is not compatible with secure pages. Many of the popular analytics services, tools and security seal providers automatically provide code that supports and includes https URLs. Some do not. Verify the code includes https URLs before adding it the header, footer or checkout templates. If it does not, contact the provider to determine if a version that supports SSL protected pages is available.  If the code was added to your template some time ago, an updated version that supports secure https pages may be available now.  For example, Google Analytics now provides code that supports secure pages.   If you’re not sure which version you have installed, review the Google Analytics help material.

If the service provider is not able to generate their code with https URLs, one of these solutions may work:

• Modify the code to use a secure path (https) for the script source like:

</script>
<script src="https://www.anothersite.com/thiercode.js" type="text/javascript">
</script>">

•  The external site and path must support https, test it before adding to your template
•  Use SSML tags to alternate script source URLs between http and https pages as necessary like this:

</script>
<ss:if test="$request.getScheme() = = 'https'">
 <script src="https://www.anothersite.com/thiercode.js" type="text/javascript">
<ss:else/>
 <script src="http://www.anothersite.com/thiercode.js" type="text/javascript">
</ss:if>
</script>

•  The external site and path must support https, test it before adding to your template
• Consider using the script only on templates that are never displayed with SSL security (not on the header, footer or checkout pages)