Archive for February 2012

CSS3PIE/ and https and IE6 Last updated:21 November 2012

Came across an interesting one last week using https on an Opencart installation. After implementing https I discovered that all the secure pages generated a warning in IE6: “This page contains both secure and insecure items”. I couldn’t work out why this was happening at all and ended up with a test page with virtually nothing on it still generating the error.

After some more messing about it became apparent that the error was being caused by the CSS3PIE code – specifically the use of a reference to url(about:blank) in the script. There’s more info here. The suggested solution is to replace a.backgroundImage="url(about:blank)" with a.backgroundImage="none" which seems to have done the trick for me. I was a little nervous about that replacement so have created a separate version of just for IE6, with no problems so far.

Posted here in case anyone else has the issue as it took me a while to find the solution.

jQuery fadeOut in Firefox 10 Last updated:20 June 2012

Having an odd week this week.

While viewing a client’s site today in Firefox 10 I noticed that the crossfade on the site, loaded just before Christmas, wasn’t quite right – the images should crossfade into one another (using this script), but what happened was the image faded to black and then the next image appeared. I observed the same effect on the malsup cycle plugin, used elsewhere on the site.

Now the same script works fine in Opera 11 and Chrome, and it works fine in Firefox 10 on my demo page listed above. So what’s the difference? The only difference is that one image has a border, and one doesn’t. Add the border and the crossfade works fine, take it away and it doesn’t. Here’s a cut down illustration – the left hand image has a border and fades to transparent, the right hand image has no border and fades to black then transparent.

Having checked a couple of other sites I’ve built, if the image is wrapped in div, all seems to be OK as well, it’s just an issue with images.

This is only an issue in Firefox 10 as far as I can see. FF9 is fine.

I’ve logged this as a bug with jQuery. If you’ve come across the same issue please leave a comment below, or, if you’ve got a spare second and Firefox 10, have a look at the test page and let me know if you see the same thing. Apparently it’s OK on Mac/OS X. I’m on W7 Pro 64-bit.

Update 10 February Thanks to Oblik for the updates below – this is reported as a Firefox bug as well. It also seems that applying background-color to the image also solves the problem. I’ve further noted that this does not affect a different machine running W7 Home with FF10 – the links suggest it may be related to the graphics card.

Update 18 February This looks like it’s mostly likely to get resolved by a Firefox update to me. I’ve noticed the problem today on another couple of sites. It’s now being logged under this ticket.

Update 24 April Still not fixed in FF11…I’ve noticed the problem a lot on a wide variety of sites. Looks like it might be scheduled for a fix in FF13.

Update 20 June Fixed in FF13!!

Creating a mobile version of an Opencart shop – 5 Last updated:16 March 2012

Nearly finished this stage now I think. I’ve now worked through all the pages (I think…) and updated them. This morning I realised that although the site works mostly OK without javascript, without it the zones (counties in the UK) are not populated, so it’s impossible to enter an address. Ugh. Resolving this needs the following adding to /catalog/controller/account/create.php, /catalog/controller/account/address.php, /controller/checkout/address.php and /controller/checkout/guest_step_1.php

$this->data['zones'] = $this->model_localisation_zone->getZonesByCountryId($this->data['country_id']);

And the following editing in /catalog/view/theme/[your theme]/template/create.tpl, /catalog/view/theme/[your theme]/template/address.tpl, /catalog/view/theme/[your theme]/template/address.tpl and /catalog/view/theme/[your theme]/template/guest_step_2.tpl:

<select name="zone_id">
   <option value="FALSE"><?php echo $text_select; ?></option>
   <?php foreach ($zones as $zone) { ?>
     <?php if ($zone['zone_id'] == $zone_id) { ?>
     <option value="<?php echo $sone['zone_id']; ?>" selected="selected"><?php echo $zone['name']; ?></option>
     <?php } else { ?>
        <option value="<?php echo $zone['zone_id']; ?>"><?php echo $zone['name']; ?></option>
     <?php } ?>
   <?php } ?>          

(It would be nice if the code used functions a little more for repeated things like the address form.) This then allows selection of zone even with javascript disabled. There’s still a much more minor problem, which is that if the country is changed, with javascript disabled the zone list is not refreshed. This resolves itself when the form is submitted since the zones are then correctly populated by the posted data, but is less than perfect. We get very few orders from outside the UK anyway, so I’m going to park that one for now. The solution, I think, would be to add a button to let the user manually refresh the page, minus the validation, after changing the country.

Anyway, back to the mobile site specifics. I showed it to the client (to whom, coincidentally, I’m married…) yesterday, and she is happy so far. Hoorah! Next step is to test it with some tame users I think.

Concerns I have at the moment: not sure about scrolling the menu on the home page; I wonder whether clicking through from the category page to the product page is too difficult (although in fact most of our sales come direct from the category page not the product page); think the general text might be a bit small. We’ll see.

Creating a mobile version of an Opencart shop – 6 Last updated:25 February 2012

I should have said, if anyone’s reading this and would like to have a look at the test site, it’s currently available at:

Note you won’t be able to checkout at the moment as it’s pointed at the Paypal sandbox. At the moment at least I’m more concerned with the usability of the site anyway. If you do view the site then any and all comments are welcome. If you see a problem, do let me know – it would be helpful to know the model of phone with which you viewed it. Thanks!

Opencart and support for javascript disabled Last updated:23 February 2012

I realised recently that my Opencart installation does not allow users to checkout if they have javascript disabled. It’s a little unfortunate because there’s no warning of this at all to the user – you can fill your basket OK, and then you’re stuck. This is a shame since otherwise I like Opencart, it’s pretty easy to configure once you’ve got the hang of its MVC architecture. These threads on the Opencart forum make it look like this isn’t likely to change.

Now, not many people are going to have their js disabled, but do we really want to disenfranchise the few, or even one, that do/does? I think not.

There are two situations where Opencart uses javascript on navigation. The first is for a simple link:

<a onclick="location = '<?php echo str_replace('&', '&', $back); ?>'" class="button">

This is simply fixed by making this:

<a href="<?php echo str_replace('&', '&', $back); ?>" class="button">

The other situation is slightly more complex and happens where forms need to be submitted. As a default Opencart has, for example:

<a onclick="$('#payment').submit();" class="button"><span><?php echo $button_continue; ?></span></a>

The quick and dirty solution is to replace this link with a “normal” input tag of type submit. However, these are more difficult to style. Conseqeuntly, I’ve amended the html to:

<span class="button hide_js"><input class="hide_js" type="submit" value="<?php echo $button_continue; ?>"/></span>
<a onclick="$('#payment').submit();" class="button show_js"><span><?php echo $button_continue; ?></span></a>

with some simple jQuery, which I’ve added to ajax_add.js:


and this css


So, for a user without javascript, the link which relies on javascript is hidden by the css and a simple input button is used instead. For a user with javascript enabled, on page load the input button is hidden and the javascript link displayed. Using OC I found one situation where the form does not extend to include the div which contains the button – I just extended it so it did.

With a bit of judicious css, the “non javascript” buttons can be virtually identical (not pixel perfect) to the javascript ones – that’s why I’ve wrapped the inputs in the span as shown above, and then extending the styling used for .button span to include .button input.

Update 23 February: I subsequently spotted another issue with javascript disabled which is that it’s impossible to select the zone in an address since this is populated only by javascript. Fixing this is slightly more complex – see this post.