Creating a mobile version of an Opencart shop – 4 Last updated:21 February 2012

Spent today mostly hacking the login/purchase forms to make them behave better, and removing the tables at the same time. Like this:

My account Login Customer form

Not sure about the styling on those radio buttons at the moment….

Creating a mobile version of an Opencart shop – 3 Last updated:23 February 2012

OK, so today I’ve reworked the header links to include a Home link but remove the Logout link – I’ve moved the latter to sit under My Account.

I’ve also redone (again..) the category page, having given up trying to fit everything onto one line, quite pleased with the result.

I also copied across all the products from the base store to the mobile store, using, for example, this SQL:

CREATE TEMPORARY TABLE tmp SELECT * FROM oc_product_to_store WHERE store_id = 0;

UPDATE tmp SET store_id=2 WHERE store_id = 0;

DELETE FROM oc_product_to_store WHERE store_id=2.

INSERT INTO oc_product_to_store SELECT * FROM tmp WHERE store_id = 2;

This needs repeating for oc_category_to_store as well. My initial thoughts on categories was to create some different categories to avoid masses of scrolling, but I’m thinking in fact that this may be handled just as well by the inbuilt pagination.

I’ve also added a “back to category” link to the product page and restyled that, removing all the tables.

And finally, styled the home page links so they look a bit nicer. Not sure at the moment whether having those links full width will get in the way of scrolling the page up and down. Results below:

Reworked home page Reworked category page Product page Reworked My Account page

Looking at these screenshots I realise I now have space to make the button on the category page larger again, also wonder whether the links on the My Account page should be buttons like the home page.

Creating a mobile version of an Opencart shop – 2 Last updated:18 February 2012

Been fiddling about with the layout again today and having checked the site on another emulator I’ve decided I need to rework the category page to make the image smaller, otherwise I’m struggling with room again. It would be quite nice to have a product image that isn’t square, but it seems Opencart doesn’t like images that break the original aspect ratio. Fair enough. Although the revised image fits better it doesn’t look as nice I think. I can feel the temptation to use tables to layout the category grid – am trying to resist this.

Anyway, here’s the latest iteration, tried the Opera Mobile Emulator today:

Reworked category page

I’ve been examining the CostCo mobile site as that was well-rated on a site I was reading, but I spotted this afternoon that if you go down the navigation until you actually get to a product detail page, then it links to the main site, so you can’t actually buy anything direct from the mobile site. Seems odd.

To do list: I think the main menu (see previous post) could actually manage with links that are less deep, and I’m also thinking about reducing the header size to fit the “My Account” and “Basket links” alongside it, also think the input fields on that category page are too large.

Creating a mobile version of an Opencart shop – 1 Last updated:20 February 2012

Yesterday I started playing around with creating a version of our Opencart store suitable for mobiles. Here’s how I got on.

I began by considering the use of css @media queries to apply a separate css to be used on mobiles, but quickly discarded this approach as there was just too much data to fit on the screen. I then switched to the current approach, which is to create a new store within Opencart, and use a different theme wherever possible to render pages differently. Opencart is fantastic in the way it supports this – in five minutes I had two separate stores, running on m.mytestdomain.com and mytestdomain.com, bot using the same data and admin suite. Further, Opencart allows the use of separate categories and products by store – so I can use categories with less products on the mobile store only to limit the amount of scrolling – one of our live categories has 59 products in it.

I’ve been trying, wherever possible, to restrict mobile-specific code to the theme itself, so as not to compromise maintainability. However, after some experimentation I decided that I wanted to display a full list of categories and products on the home page, but not at all on subsequent pages, and this required a change to catalog/controller/common/column_left.php so that I can identify whether the rendered page is the homepage or not. I used:

		$homepage = "/";
		$currentpage = $_SERVER['REQUEST_URI'];

		if($homepage==$currentpage) { 
		$this->data['home'] = true;
		} else {
		$this->data['home'] = false;
		}

and then some conditional code on column_left.tpl to display the category module only on the home page (and not display any other modules at all).

So far, I’ve done the home page and category pages. I’ve removed all the tables encountered so far, ripped out all the extraneous stuff, and simplified wherever possible. Here’s what the pages look like so far, some more styling needed (screenshots using http://www.iphonetester.com/).

Home page on an iPhone emulator Category page on an iPhone emulator

Quite an interesting and thought-provoking challenge to minimise the size of the pages. The home page is currently less than 20k and loads noticeably quicker than the main site home page, even over my broadband link.

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:

	$('.hide_js').hide();
	$('.show_js').show(); 

and this css

show_js{display:none}

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 1.4.9.5 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.