Drupal 8 with shopping carts – notes on trials – first up Shoprocket

So I’ve been trialling a few ecommerce solutions for Drupal 8 sites and thought I’d catalogue any pitfalls along the way.

I’m running Drupal 8.7 beta locally currently as I’m itching to get the native media library going – hard to believe it’s taken Drupal until 8.7 to introduce this!

I have a couple of clients wanting eCommerce adding to an existing site so decided first off to trial shoprocket – seems quite developer focused which is good, nice simple code to add, which I pasted first into an html local site to test and worked straight away with just their script lines plus markup with placeholders for products on your actual page (they provide code to display their own demo store to let you test out quickly without setting up an account or adding your own products).

So far so good; next into Drupal, tried first using D8s preferred method of loading js libraries via libraries.yml and putting inline js into a js file to load in the same way. However, shoprocket wants to load jQuery 1.10x whilst Drupal has already loaded jQuery 3.2x and there seems to be a conflict. On the html site I’d tried, shoprocket’s inline js fixed the conflict but this didn’t seem to work in Drupal.

Instead I tried adding the product markup placeholder to a drupal page, having first created a content-type ‘store-page’. Created a page template in twig for the content type so that I could add shoprocket’s js code to its footer.

All works fine, though not in a D8 recommended way. This is just showing a gallery so far; next up setting it add a single-product page in next post.

Getting the slider lightbox to show mobile screenshots to a mobile; and desktop screenshots to a larger viewport

As this site is all about showcasing examples of my responsive website designs, I wanted users on a mobile device to see screenshots of (you guessed it) mobile sites, and desktop users to see screenshots of desktop sites. The previous post handles doing that for the thumbnails, but I wanted the same for the lightbox of images you see when you click that thumbnail (on the home or design pages).

Petr Marek has done an excellent job of integrating a very nice lightbox into the Slick Carousel (see previous post), and the instructions for having an array of images linked to a carousel slide work great, but would show the same screenshots to all users. With a little simple javascript I was able to adjust this so that different devices get shown different screenshots.

To do this required an appropriate class adding to the list item (thumbnail) at different viewport sizes so that different images could be triggered in the array:


<li class="esw-home-lightbox desk" data-min-width-1024='<a href="#"><img src="img/slick/design/mob-tab-esw.png" alt="East South West Landlords page"></a>'>

I’ve removed any classes not relevant to the lightbox for this post. If that ‘data-min-width’ part looks odd to you, it’s part of issuing the appropriate thumbnail (see the previous post).


var width = $(window).width();
if(width >= 1024){

As you can see, I didn’t go crazy, just adding a ‘mob’ class for a portrait mobile screenshot to anything under 1024px, and a ‘desk’ class for a desktop screenshot to anything over 1024px. With those classes appropriately added, the addition code to supply the correct screenshots to the lightbox looks like this:

images: ['slick/mob-esw1.jpg', 'slick/mob-esw2.jpg'],
images: ['slick/desk-esw-1.jpg', 'slick/desk-esw-2.jpg'],

This of course is in addition to loading Slick and Slick-lightbox JS files, but that is amply covered in their own documentation.

For the next post I’ll take a look at including this WordPress blog within a hand-coded site; why I did that, how, and whether it was a good idea or not!

Slick slider and responsive content

The brief: A slider that looks great on all devices: more thumbnails per slide on a larger screen.

The solution: When I was designing this site (as with any site these days), responsive web design (with it’s roots in Ethan Marcotte’s classic article) was firmly in my mind. I’m keen on sending the same content to all devices, not different information for mobile devices – styled appropriately for every device’s screen of course, but the same actual content.

But there are always exceptions to a rule (and it’s not really a rule, more of a general intention), so here’s why this one breaks the rule (or general intention…): on the home page and design pages, I wanted a mobile to see a single screenshot on one slide, a description on the next; on a portrait tablet, those two slides side-by-side; landscape tablet – maybe two screenshots per project plus a description; on a desktop, three screenshots plus description.

For the slide show I’m using Ken Wheeler’s excellent Slick, it’s wonderfully simple to implement and well documented. Slick allows for some responsiveness by way of setting how many elements are shown per slide at different breakpoints, so this took care of mobile up to portrait tablet.

1 slide - 4 items

The BUT: The example above shows the desktop view, though Slick’s settings would allow two items per slide for a portrait tablet, it would show items 1 and 2, when I want to show items 1 and 4; on a landscape tablet I want to show 1, 2 and 4, Slick would automatically show 1, 2 and 3. So clearly something more is needed.

The BUT solution: After a lot of trial and error I opted for response.js, a jQuery plugin which allows you to dynamically swap content based on breakpoints and data attributes. So in the HTML, items 1 and 4 are available for all sizes, item 2 gets added by response.js via a data attribute at 1024px, and item 3 gets added at 1400px.

How? Well after linking to the response.js file (after jQuery of course) you add this to your body tag:

data-responsejs='{ "create": [{ "prop": "width", "prefix": "min-width- r src", "breakpoints": [0, 641, 961, 1024, 1400] }]}'

or whatever breakpoints you want. Then within the Slick slider elements (each <li> is an element used in the slider):

<li><data-min-width-1024='<img src="/img/slick/design/mob-tab-gen.png" alt="Generic tablet & phone">'</li>

That image will then get added if the viewport is 1024 or wider. I tried putting the <li> tags within the data attribute instead but it didn’t work. This caused a problem; because at less than 1024px there was now an empty <li>, Slick would count this and leave an empty space for the image – not good. CSS display:none is no good as it’s still there in the HTML, so still counted by Slick.

So I decided to remove the empty <li> with jQuery. There are several ways to remove items based on media queries, but I found a neat solution at Forefront which looks for a media-query change and fires your jQuery command when it happens, guaranteeing the change happens when the media query does. So adding a display:none to the list items that would be empty seemed logical, and then firing the .remove in javascript when the media query display:none happens (it’s instant), and also making sure that bit of javascript loads before Slick so that it can’t count the empty <li>.

And finally: There’s a saying that only web designers adjust their browser size – but even if that’s true, I knew there was a chance people would do that, especially when I’m blogging about it, so I had to add a little js to make sure the page reloads if the browser is resized so that the correct number of thumbnails get shown for the viewport size.

var lastWidth = $(window).width();

lastWidth = $(window).width();

There’s a compromise in that, because a user might be annoyed by the refresh if, say,  they rotate their tablet, but if the content is optimised enough, the refresh is fast, so I thought it was worth the trade-off.

In the next post I’ll explain getting the lightbox connected to the slider to show mobile screenshots to a mobile; and desktop screenshots to a larger viewport.

Introducing ~ Curly Braces

This blog is about life as a solo designer/developer.

I am not the greatest technical innovator in web development (understatement), I learn from the great work of others who so generously share their knowledge for the  enhancement of the web.

Often this involves working out how to combine several different things created by others. I will blog about this when I found something hard to make sense of (whether due to over-complicated explanations, or my own ineptitude), and I think I can explain it in a simpler way, or where I stumble across a way to do things which I couldn‘t find tutorials for elsewhere.

I will assume anyone reading this has a reasonable understanding of web development; html, css – the idea is to add to the help already out there in an understandable way, not simply repeat what’s already explained perfectly well elsewhere.

Solo developers don’t have the benefit of shouting round the studio for a solution to a problem. Hopefully this blog will help others like myself who work alone.

So I hope you’ll enjoy it, upcoming posts will focus on the development of this site as there were a few interesting challenges along the way, and getting it down while its fresh in my mind will help me if no-one else!