I’ve been working on a new project customizing another Xsilva Lightspeed Web store with WordPress integration because that has been my ultimate goal and everything has been going along perfectly except it came down to testing the SSL connection for the customer registration and checkout pages (these 2 urls auto redirect to https:// if you turn SSL on in the admin panel). Well, the addressbar would start off a beautiful deep blue and the lower right hand of the locationbar lock icon would load but when it was all done zam! Lock icon broke, blue address bar disappeared. Nooooo.
The 1st thing I did to troubleshoot was make all links use / instead of http:// even though you can use http in urls that are not scripts or images. Then I took out some of my WordPress footer widgets,thinking it might be the Twitter Pro widget or something, but nope. Then I thought why not check all the media files with Tools >> Page Info >> Media? But every media file listed began with https:// so I closed the Page Info window and went back to work but it kept nagging me.These 2 pages must be secure, no way around it. So I opened Tools >> Page Info >> Media again and clicked on each image url to get the preview and there was the culprit, the default search icon -even though I did not want to use it it was being loaded into the page anyway. I’d loaded my own image folder to use in my stylesheet to reduce the clutter a bit and I did not have a search_go.png yet. So even though the path to the file was redirecting correctly to SSL, because it returned a 404, the secure connection was breaking.
The developers of Web Store give us a lot to work with but oftentimes some things are out of our hands. Things like input value and in this case image src are coded into the the template like this:
[php]<span style=""><?= $this->misc_components[‘search_img’]->Render(); ?></span>[/php]
Src file searchbox.tpl.php
Thankfully this is the easiest thing to fix, I just uploaded my search_go .png and it overwrote the default. Then I clicked back to my register page and this time the SSL connection remained alive! Who would have thought it could be something so small causing this much trouble?