Everyone has their own build process, I've contracted at many agencies and they all have a slightly different setup. Some use an old school Grunt/Gulp setup, some use NPM scripts and some use Vite/Parcel or similar. Sometimes these build processes work with no issues but I can't count the amount of hours I've seen wasted due to build process problems, usually down to dependency issues, e.g. having the wrong version of Node/NPM installed.

I remember when Shopify released Slate, it came with a complex build process which tried to do way too many things in my opinion. There was a lot of frustration from developers having issues with it and the project eventually got deprecated. Too many moving parts = more things that can potentially break. Since then, Shopify has released Dawn and then Horizon as their flagship starter themes which both use a "no-build" approach, there's less to go wrong without a build process and no time wasted trying to debug related issues due to a package discrepancy or operating system inconsistency.

I've experimented with all kinds of build processes over the years, I settled with a very lightweight NPM scripts based approach for a while and was quite happy with it. In recent times though, I've started to favour not using a build process at all. I kicked off a new full build theme project without a build process and I wanted to see how far I got until I caved, now I never want to touch a build process ever again!

In my previous, simple NPM scripts based build process, it handled a few things for me:

• Javascript compilation/transpilation via Babel, this read my source JS files and outputted minified bundle JS files to serve to the browser
• SVG icons, this went through a folder of SVG files and outputted an SVG icon sprite
• Tailwind compilation, this read my source Tailwind CSS file and outputted a minified CSS file, using the JIT compiler so it only included classes used within the theme HTML

Javascript

To cut out the JS compilation step, I adopted a similar approach to Dawn/Horizon, just use separate JS files served directly to the browser with web components - this was considered bad practice for a while as it hindered page speed performance. This is no longer the case with modern HTTP/2 as it's multiplexed, meaning it can request hundreds of resources in parallel using a single TCP connection. Shopify also automatically minified these JS files when served in the browser, this gives us the best of both worlds, great developer experience with all the performance gains of using a bundler.

Icons

For SVG icons, I stopped using the sprite approach and leveraged the new(ish) inline_asset_content Liquid filter. Each SVG icon is a separate file within the theme "assets" directory and to output the icon, simply do:

{{ 'icon.svg' | inline_asset_content }}

Tailwind

The Tailwind compilation was the trickiest part of going "no-build", Tailwind has been my go-to solution for scalable CSS for years now and is it's usage is non-negotable for me so I had to find a decent solution for this. It turns out that Tailwind has a feature they call the Play CDN, this enables you to use the compiler directly inside of the browser without a build step. It's not meant for production use, it's a Javascript-based solution which dynamically generates CSS based on the page HTML and is meant to be used to test Tailwind features and to build prototypes.

You can also provide the Tailwind Play CDN with config, I assumed it'd eventually break with a complex config setup with many colors, font sizes, variants etc. but it's very stable in my experience. To get started with this approach, I added a new file /assets/tailwind.css and populated it with a simple config:

@import "tailwindcss";

@theme {
  --color-primary: red;
  --color-secondary: green;
  --color-tertiary: blue;
}

Within my /layout/theme.liquid file, I added this snippet:

<script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>

<style type="text/tailwindcss">
  {{ 'tailwind.css' | inline_asset_content }}
</style>

That's it, we now have full use of Tailwind during theme development without the need for a build process. See the below demo video of this in action, notice how new classes are automatically generated as the HTML changes, the Play CDN uses a mutation observer to detect HTML changes and the Tailwind JIT compiler dynamically generates new classes on the fly and injects the necessary CSS into the DOM, it makes for very a very smooth developer experience.

This is a great workflow during development but what about production? This is where it gets a bit more complex, I started off by adding this snippet to my /config/settings_schema.json file:

{
  "name": "Mode",
  "settings": [
    {
      "type": "select",
      "id": "mode",
      "label": "Mode",
      "options": [
        {
          "value": "production",
          "label": "Production"
        },
        {
          "value": "production-css-inline",
          "label": "Production (CSS inline)"
        },
        {
          "value": "development",
          "label": "Development"
        }
      ]
    }
  ]
}

Then within my /layout/theme.liquid file, I changed my previously added CSS snippet to this:

{% case settings.mode %}
  {% when 'production' %}
    <link rel="stylesheet" href="{{ 'tailwind.min.css' | asset_url }}">
  {% when 'production-css-inline' %}
    <style>
      {{ 'tailwind.min.css' | inline_asset_content }}
    </style>
  {% when 'development' %}
    <script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>

    <style type="text/tailwindcss">
      {{ 'tailwind.css' | inline_asset_content }}
    </style>
{% endcase %}

This adds the following section to the global theme settings within the theme customiser:

This "Mode" setting has three options: "Production", "Production (CSS inline)" and "Development". if set to "Production", the theme will use a regular CSS file reference and look for the file /assets/tailwind.min.css. If set to "Production (CSS inline)", the theme will output the contents of the file /assets/tailwind.min.css within a <style></style> tag (this can be beneficial for performance, but only if the file is small enough, be careful with this and run performance tests if unsure). If set to "Development", the theme will use the Tailwind Play CDN as discussed above.

Build process and chill?

The only problem we have here is how do we go about using the /assets/tailwind.min.css file if it doesn't exist? This part does technically need a build process unfortunately, in theory this can be automated via a Git pre-commit hook and/or GitHub Action but I haven't looked into this yet. I handle this via a simple NPM script within my `package.json` file:

{
  "name": "shopify-theme-no-build",
  "scripts": {
    "build": "npx @tailwindcss/cli -i ./assets/tailwind.css -o ./assets/tailwind.min.css --minify"
  },
  "dependencies": {
    "@tailwindcss/cli": "^4.1.13",
    "tailwindcss": "^4.1.13"
  }
}

I simply just run npm run build before I push to production and that's it. I know this sounds like it defeats the purpose of not using a build process but the main thing I wanted to avoid was needing to use a build process during active development. When it comes to making changes to a project with this setup, it's just a case of pulling down the repo, running shopify theme dev, changing "Mode" to "Development" within the theme settings and I'm ready to go.

I've added a very bare-bones example of this setup within a Shopify theme in a GitHub repository tomblanchard/shopify-theme-no-build if you'd like to nerd-out further - enjoy and thanks for reading! ✌️

At first glance, it looks like the only way to use Functions is inside of a full blown Shopify app. The thought of letting a client know that they’ll have to purchase hosting for an app and pay a monthly fee just to replace functionality they currently get for free with Scripts rubs me the wrong way.

Luckily, we can use an extension-only app to avoid having to create a proper app, which means we don’t have to worry about setting up all the app boilerplate, setting up a server, dealing with authorisation and developing app UI pages etc.

What I’ll be detailing in this blog post is how to get started with Functions and translating an existing Ruby-based Script into Javascript which will be used by a Function and internally compiled into WebAssembly.

Example Script

Here’s the Script I’ll be using as an example:

BULK_DISCOUNTS = [
  {
    quantity: 10,
    discount: 20.0,
    message: "20% off 10 or more"
  },
  {
    quantity: 40,
    discount: 30.0,
    message: "30% off 40 or more"
  }
]

cart_lines_quantity_total = 0

bulk_discount_active = nil

Input.cart.line_items.each do |item|
  cart_lines_quantity_total += item.quantity
end

BULK_DISCOUNTS.each do |discount|
  if cart_lines_quantity_total >= discount[:quantity]
    bulk_discount_active = discount
  end
end

unless bulk_discount_active
  Output.cart = Input.cart
  exit
end

Input.cart.line_items.each do |item|
  item.change_line_price(item.line_price - (item.line_price * (bulk_discount_active[:discount] / 100)), message: bulk_discount_active[:message])
end

Output.cart = Input.cart

This Script applies a discount to all line items if the total line item quantity reaches a certain threshold based on a config object. E.g. If total cart item quantity is 1 then no discount is applied, if total cart item quantity is 10 or more then apply a 20% discount to all line items, if total cart item quantity is 40 or more then apply a 30% discount to all line items.

Creating the app

To get started with migrating the Script to a Function, I’ll assume you have the following:

• Shopify Partners account
• Shopify development store
• Installed Node.js 16 or higher
• Installed Shopify CLI 3.0 or higher

Start off by opening up Terminal and entering the following command:

npm init @shopify/app@latest

This will create a new app directory on your local machine, give it a name e.g. “tom-blanchard-functions-test”:

Next, choose the “Start by adding your first extension” option:

This will create the app directory for you:

Deploying the app

Navigate to this directory in Terminal and run the following command:

npm run deploy

This will create the app on your Shopify Partners account, choose the Partners organization you want the app to be associated with:

Next, choose the “Yes, create it as a new app” option:

Next, give it a name e.g. “tom-blanchard-functions-test”:

Next, choose the “Yes, release this new version” option:

You should now be able to see this app listed under Shopify Partners -> Apps:

Next, run the following command:

npm run shopify app config link

Select the Partners organization you chose before then choose “No, connect it to an existing app” and find the app you created in the above steps. This will pull down your remote app config and update your local “shopify.app.toml” file:

Creating the app extension (Function)

Run the following command:

npm run shopify app generate extension -- --template product_discounts --name product-discount

Choose the “Javascript” option:

This will create a new directory “extensions/product-discount” which will house the configuration and logic to this specific Function:

Next, open the file “shopify.app.toml” and change the scopes value to "write_products, write_discounts":

Open the file “extensions/product-discount/shopify.extension.toml” and change API version to “2023-10”:

Open the file “extensions/product-discount/input.graphql” and replace it with this:

query Input {
  cart {
    lines {
      quantity
      merchandise {
        __typename
        ...on ProductVariant {
            id
        }
      }
    }
  }
  shop {
    metafield(namespace: "tom-blanchard-functions", key: "config") {
      type
      value
    }
  }
}

Open the file “extensions/product-discount/src/index.js” and replace it with this (this is a direct code translation of the original Ruby-based Script):

import { DiscountApplicationStrategy } from "../generated/api";

var EMPTY_DISCOUNT = {
  discountApplicationStrategy: DiscountApplicationStrategy.First,
  discounts: [],
};

var BULK_DISCOUNTS = [
  {
    quantity: 10,
    discount: 20.0,
    message: "20% off 10 or more"
  },
  {
    quantity: 40,
    discount: 30.0,
    message: "30% off 40 or more"
  }
];

export default (input) => {
  var config = BULK_DISCOUNTS;

  var targets = input.cart.lines
    .filter((line) => line.merchandise.__typename == 'ProductVariant')
    .map((line) => {
      var variant = line.merchandise;

      return {
        productVariant: {
          id: variant.id
        }
      }
    });

  var cartLinesQuantityTotal = input.cart.lines.reduce((total, line) => {
     total += line.quantity;
    return total;
  }, 0);

  var bulkDiscountActive = config.find((bulkDiscount) => {
    return cartLinesQuantityTotal >= bulkDiscount.quantity;
  });

  if (!bulkDiscountActive) {
    console.error('No cart lines qualify for this discount.');
    return EMPTY_DISCOUNT;
  }

  return {
    discounts: [
      {
        targets,
        value: {
          percentage: {
            value: bulkDiscountActive.discount
          }
        },
        message: bulkDiscountActive.message
      }
    ],
    discountApplicationStrategy: DiscountApplicationStrategy.First
  };
};

Now run the following command:

npm run shopify app function schema -- --path extensions/product-discount

This uses the API type and version of your Function, as defined in your extension TOML file, to generate the latest GraphQL schema. The schema is written to the schema.graphql file.

Now run the following command:

npm run shopify app function typegen -- --path extensions/product-discount

This creates GraphQL types based on your input query for a Function written in JavaScript.

Now run the following command and choose “Yes, confirm changes”:

npm run shopify app config push

Deploying the Function

Run the command:

npm run deploy

Installing the app

Let’s install this app on your store; head Shopify Partners dashboard -> Apps and find the app you just created:

Click the “Choose distribution” button and select the “Custom distribution” option:

Next, enter in the store URL you’d like to install this app on:

Next, click “Generate link”:

You’ll now be able to visit this URL and install the app on your store:

Scroll down and click “Install app”. This will have installed the app on your store but the Function we created still needs to be activated.

Activating the Function

Install the Shopify GraphiQL App by visiting this URL: https://shopify-graphiql-app.shopifycloud.com

Enter in your store URL and make sure the scopes “discounts/read” and “discounts/write” are enabled then click the “Install” button. This will bring you to this page:

This app allows you to run GraphQL queries and mutations against your store. Now, copy/paste this code into the app and click the run button:

query {
  shopifyFunctions(first: 25) {
    nodes {
      app {
        title
      }
      apiType
      title
      id
    }
  }
}

You should see something like this:

The ID highlighted in the above screenshot is the ID of the Function we need to activate so make a note of it. Next, copy/paste this code into the app, replace “YOUR_FUNCTION_ID_HERE” with the Function ID and click the run button:

mutation {
  discountAutomaticAppCreate(automaticAppDiscount: {
    title: "tom-blanchard-functions-test",
    functionId: "YOUR_FUNCTION_ID_HERE",
    startsAt: "2022-06-22T00:00:00"
  }) {
     automaticAppDiscount {
      discountId
     }
     userErrors {
      field
      message
     }
  }
}

You should now see something like this:

If you head to Shopify Admin -> Discounts you should also see this discount there:

This means your Function is now active and enabled, you should be able to see it in action by heading to the store and adding over 10 products to the cart:

You can now make any changes you want to the logic by changing the JS code in the file “extensions/product-discount/src/index.js” and run the command:

npm run deploy

This will automatically reflect on the storefront.

Client-friendly configuration

With Scripts, tech-savvy clients could navigate to the Scripts editor app and manually make code changes to tweak the logic of their Scripts. I make this easier for them by defining configuration at the top of the file inside if objects, e.g. “BULK_DISCOUNTS” and walking them through how to make simple changes. This is no longer possible with Functions in the same way because clients don’t have access to the Functions code via the Shopify admin.

I’ve figured out a way to enable clients to be able to tweak Functions config in a similar fashion, leveraging shop-level metafields (credit to Sammy Isseyegh for letting me know about this). To enable this, head to the file “extensions/product-discount/src/index.js” and replace it with this:

import { DiscountApplicationStrategy } from "../generated/api";

var EMPTY_DISCOUNT = {
  discountApplicationStrategy: DiscountApplicationStrategy.First,
  discounts: [],
};

export default (input) => {
  var config = input.shop.metafield && JSON.parse(input.shop.metafield.value);

  if (!config) {
    console.error('No config metafield setup for this discount.');
    return EMPTY_DISCOUNT;
  }

  var targets = input.cart.lines
    .filter((line) => line.merchandise.__typename == 'ProductVariant')
    .map((line) => {
      var variant = line.merchandise;

      return {
        productVariant: {
        id: variant.id
      }
    }
  });

  var cartLinesQuantityTotal = input.cart.lines.reduce((total, line) => {
    total += line.quantity;
    return total;
  }, 0);

  var bulkDiscountActive = config.find((bulkDiscount) => {
    return cartLinesQuantityTotal >= bulkDiscount.quantity;
  });

  if (!bulkDiscountActive) {
    console.error('No cart lines qualify for this discount.');
    return EMPTY_DISCOUNT;
  }

  return {
    discounts: [
      {
        targets,
        value: {
          percentage: {
            value: bulkDiscountActive.discount
          }
        },
        message: bulkDiscountActive.message
      }
    ],
    discountApplicationStrategy: DiscountApplicationStrategy.First
  };
}

This code does exactly the same thing, except the configuration is no longer hard-coded and uses the metafield defined under “shop.metafields.tom-blanchard-functions.config”.

Next run the command:

npm run deploy

This will cause the Function to stop working on your storefront because the config metafield hasn’t been created yet:

To create this metafield, install your favorite metafield editor app, e.g. Metafields Guru. Once installed, you should see this:

Head to “Shop”, click the “Create metafield” button:

Set “Type” to “JSON string”, set “Namespace” to “tom-blanchard-functions, set “Key” to “config” and set “Value” to the below code:

[
  {
    "quantity": 10,
    "discount": 20.0,
    "message": "20% off 10 or more"
  },
  {
    "quantity": 40,
    "discount": 30.0,
    "message": "30% off 40 or more"
  }
]

Now, click the “Save” button and the Function should now work again on the storefront:

Now, the client will be able to change this metafield whenever they please via the Shopify admin to update config such as quantity amounts and wording etc. See the below example:

I’ve added “hello world!!” to the discount message and it’s now automatically reflected on the storefront with no need to re-deploy the entire app.

Parting thoughts

This seems like a lot of steps to reproduce the functionality we get with the more easy to use Scripts approach but I like the fact that I can use my local IDE for development instead of writing code in the browser editor. You could also place this app inside a Git repository and use source control to keep track of changes which you can't do with Scripts without manually copy/pasting every time you make changes.

One thing I haven't covered in this guide to keep it concise is the development preview feature that Functions gives us via the "npm run dev" command. This allows us to make changes to the Function code and it'll automatically be rebuilt and pushed to Shopify so you can immediately test your changes and iterate quickly before finally deploying.

Shopify Functions are still a work-in-progress and are constantly being improved on so I imagine the amount of steps taken to get setup will reduce over time. A developer at Shopify let me know that they're specifically looking to eliminate the GraphiQL step for extension-only apps so keep an eye out for that.

We don’t quite have feature-parity with Shopify Scripts at this time of writing but once they do, I think they’ll be a game changer and make Scripts look very inferior. See this article for more details about the limitations of Functions.

The limitations with multi-currency left us with a few options, none of them were great:

• Create currency-specific duplicates of each product, e.g. "T-shirt - GBP", "T-shirt - EUR", set a different price and code logic into the theme which includes/excludes products based on active currency
• Create a different Shopify store instance for every currency and set different product prices per-store

In a nutshell, these solutions are brittle, hard to maintain and/or overly expensive.

Shopify changed this last month by launching a new feature which allows merchants to manually control product/variant prices per-country/region, it's not perfect, but it's a game-changer in my opinion. Here's a little video of it in action:

Notice how the price is set to £20.00 for GBP users and €100 for EUR users - awesome!

Now, let's look into how these prices are set in the Shopify admin, spoiler alert: it's not great. Here's the basic workflow (this assumes that you've setup Shopify Payments and added at least one other country/region which uses a different currency to your shops base currency):

• Head to Shopify Admin -> Products
• Select the products you wish to change the prices of
• Export them as CSV
• Open the CSV in your favourite spreadsheet editor
• Scroll all the way to the last column and for each country/region you've added, there's two new columns titled "Price / COUNTRY" and "Compare At Price / COUNTRY" where "COUNTRY" is the actual country/region. I've setup my Shopify Payments to include "United Kingdom (GBP)" and "Germany (EUR)" so I have the columns "Price / DE" and "Compare At Price / DE"
• Populate the product/variant prices as you wish and save the CSV file
• Go back to Shopify Admin -> Products and import the CSV file making sure the "Overwrite any current products that have the same handle." checkbox is checked
• Confirm the prices have been successfully set by visiting your store, selecting a different currency and viewing the products

I don't know about you, but that seems like a pretty cumbersome process to me! It would have been much better if Shopify just extended the variant edit pages to include a nice UI for merchants to input country/region-specific prices.

Here's an example of what the CSV file looks for a product which has variants and a country-specific price set for each variant. The regular price for each variant is £20 but when the customer is viewing the store with the Euro currency, they'll see €100 for variant "S", €200 for variant "M" and €300 for variant "L":

It's worth noting that this functionality requires you to use Shopify Payments and the Checkout will persist whichever currency the user selects - see more about the requirements/limitations of this feature in the Shopify documentation.

While the UX of inputting the country/region-specific product prices isn't ideal, I think this feature is well overdue and it's promising to see it finally land. There's also a GraphQL API mutation "priceListFixedPricesAdd" which can do this programmatically so I imagine third-party app developers will be keen to monopolise on this and merchants will have to rely on apps to manage product prices. It seems annoying to have to pay for an app to do this but it's a lot better than importing via CSV every time!

Another feature which landed last month includes being able to use percentage price adjustments to increase/decrease product prices globally based on the customers active currency. This is done via Shopify Admin -> Settings -> Payments -> Shopify Payments -> Countries/regions -> Edit:

From here you can globally increase/decrease all product prices for this specific country via inputting a percentage into the "Price adjustment" field (value has to be between -99% and 999%). Pretty cool - I've never needed this functionality in the past but it's good to know it now exists!

These latest changes to the Shopify multi-currency feature certainly bridges the gaps and the need to use the dreaded multi-store approach is getting smaller. My only wish now is the ability to have country/region-specific products/collections, probably a pipe dream but we'll see.

• Refund policy - shop.com/policies/refund-policy
• Privacy policy - shop.com/policies/privacy-policy
• Terms of service - shop.com/policies/terms-of-service
• Shipping policy - shop.com/policies/shipping-policy
• Subscription policy - shop.com/policies/subscription-policy

They're setup via Shopify Admin -> Settings -> Legal:

By default, a Policy looks something like this on the front-end:

It doesn't look terrible, but I recently worked on a project where the designer wanted these pages to be more interesting with a different layout, images and other varied content. Shopify doesn't give you much creative freedom with Policies, all you have access to is a rich text editor for the content and you can use the theme CSS file to style the Policy pages - there's only so far you can go with this.

My first thought was to just stop using Policies to display this content and revert to using Pages, this way I can create a custom page template for each policy and make use of Sections as the content-input mechanism to code the page however I please. It turns out this isn't feasible if the store uses the Google channel because the Google Merchant Centre requirements state that you must use actual Policies and not regular Pages for this content.

With some Liquid trickery in the store theme, I was able to achieve the best of both worlds with keeping the Policy URL structure the same while using a custom template to code up each Policy page to look however I please, with theme Sections as the content-input mechanism.

It all starts within theme file "/layout/theme.liquid", look for this line:

{{ content_for_layout }}

To render a custom Section for the Refund Policy instead of the default Policy content, I changed it to this:

{% if request.path == '/policies/refund-policy' %}
  {% section 'refund-policy' %}
{% else %}
  {{ content_for_layout }}
{% endif %}

With this in place, I'm able to format the "refund-policy" Section however I please and ended up with this design:

Notice how the URL path is still "/policies/refund-policy" and the page content is structured via a custom design.

If you want to add other custom Sections to other Policies, tweak the above code to something like this:

{% if request.path == '/policies/refund-policy' %}
  {% section 'refund-policy' %}
{% elsif request.path contains '/policies/privacy-policy' %}
  {% section 'privacy-policy' %}
{% elsif request.path contains '/policies/terms-of-service' %}
  {% section 'terms-of-service' %}
{% elsif request.path contains '/policies/shipping-policy' %}
  {% section 'shipping-policy' %}
{% elsif request.path contains '/policies/subscription-policy' %}
  {% section 'subscription-policy' %}
{% else %}
  {{ content_for_layout }}
{% endif %}

This will render a custom Section for every Policy setup in the store.

This seems like a convoluted solution but I don't think there's any other way to achieve this for now - as always, it's all fun and games with Shopify development!

Update (4 Oct 2022) - This script was broken for a while as Shopify made some updates to the admin but I finally found some time to fix it so enjoy it once again! 😎

Shopify comes with a pretty good file storage solution, as documented on their help center, you can upload, manage, and delete files from the Files page in Shopify. All files uploaded to Shopify end up here, this means all product images, collections images and images uploaded via Theme/Section settings.

You can upload many files at once using the uploader, you can delete multiple files using the bulk actions toolbar but one very strange quirk is that you cannot bulk-download these files. This is a huge problem when migrating from one Shopify store to another, think moving from a development shop to the merchant's production shop.

I figured out a way to bulk-download these files, it involves scraping the client-side admin UI code via the browser development tools Javascript console then using a Node.js script to download the files to your local machine.

If you need to do this, start off by making sure you've got Node.js installed on your machine, download and run the installer from the Node.js website - opt for the version which they state "Recommended For Most Users".

Next, open a Terminal window, if you're not sure how to do that, see this tutorial.

Now, click this link to download the Shopify Bulk File Downloader, save it to your desktop and unzip it.

Open your Terminal window and run the command cd ~/Desktop/shopify-bulk-file-downloader-master, then run the command npm i.

Next up, click this link, select all the code and copy it to your clipboard, with that code copied head over to the Files page of your Shopify acccount, that looks like this:

https://shop.myshopify.com/admin/settings/files

With this page open, open the Chrome Developer Tools (View -> Developer -> Development Tools) then click the "Console" tab, paste the code copied to your clipboard in here and press the Enter key - eventually you'll see an alert which states "File URLS have been copied to your clipboard!".

Now head over to your Desktop directory in Finder and open the file file-urls.json, you can open this on any text-editing app (TextEdit, Notepad, etc.) and paste the results into this file, save and close it.

Go back to your Terminal window and run the command node server, a new directory will be created in the shopify-bulk-file-downloader-master directory called "files", all files will be downloaded there and you'll see a "Success!" message in the Terminal when finished.

Enjoy. :)

Lazy loading images is a pretty common practice nowadays, why load all images on each page if you can't garuantee your users will actually see them? To prevent your users from downloading every image, you can instead load all images which are visible/close to being visible within the users browser viewport as they scroll.

There's a ton of libraries in the wild which implement lazy loading functionality, I'd reccomend to do some research and choose one that fits your needs or even roll your own. The only assumption I'll make here is that your markup for a lazy-loaded image looks something like this:

<img data-src="//domain.com/image.jpg" alt="" />

This image will only load when it's visible/close to being visible within the users browser viewport.

Here's a screenshot of the page we'll be building:

The content will be fed from a Section:

{% schema %}
  {
    "name": "About",
    "settings": [
      {
        "type": "text",
        "id": "title",
        "label": "Title"
      },
      {
        "type": "image_picker",
        "id": "image",
        "label": "Image"
      },
      {
        "type": "richtext",
        "id": "copy",
        "label": "Copy"
      }
    ]
  }
{% endschema %}

{% assign title = section.settings.title %}

{% assign image = section.settings.image %}
{% assign image_url = image | img_url: '2000x' %}

{% assign copy = section.settings.copy %}

<h1>
  {{ title }}
</h1>

<img data-src="{{ image_url }}" alt="" />

<div class="rte">
  {{ copy }}
</div>

Here's a video of this page loading on a fast 3G connection:

Notice how initially, the copy text is visible, then once the image has loaded, the content reflows and the text gets pushed out of view underneath the image. This happens due to the browser having no knowledge of the image prior to it loading, including the image width and height.

We're working with a Shopify "image" object here which provides extra info about the image, including it's width and height; if we have access to this info prior to downloading the image in the browser, we can work out it's aspect ratio like so:

{% assign image_box_ratio = image.height | append: ".0" | times: 1 | divided_by: image.width | times: 100 | append: "%" %}

From there, you can wrap the image in a container which uses this aspect ratio:

<div style="--box-ratio: {{ image_box_ratio }};">
  <img data-src="{{ image_url }}" alt="" />
</div>

Sprinkle in some CSS:

[style*="--box-ratio:"] {
  height: 0;
  padding-bottom: var(--box-ratio);
  background: #F8F8F8;
}

The Section will look like this:

{% schema %}
  {
    "name": "About",
    "settings": [
      {
        "type": "text",
        "id": "title",
        "label": "Title"
      },
      {
        "type": "image_picker",
        "id": "image",
        "label": "Image"
      },
      {
        "type": "richtext",
        "id": "copy",
        "label": "Copy"
      }
    ]
  }
{% endschema %}

{% assign title = section.settings.title %}

{% assign image = section.settings.image %}
{% assign image_url = image | img_url: '2000x' %}
{% assign image_box_ratio = image.height | append: ".0" | times: 1 | divided_by: image.width | times: 100 | append: "%" %}

{% assign copy = section.settings.copy %}

<h1>
  {{ title }}
</h1>

<div style="--box-ratio: {{ image_box_ratio }};">
  <img data-src="{{ image_url }}" alt="" />
</div>

<div class="rte">
  {{ copy }}
</div>

With that in place, the loading experience has dramatically improved:

Notice how the image is displayed as an empty placeholder (grey) box before the image is actually downloaded, once the image has loaded, there's no content jump because the grey box uses the same aspect ratio as the image itself.

I use this method throughout all Shopify sites I build and work on, it's such a huge performance boost with very minimal effort.

What about images which aren't "image" objects?

It's quite common to have theme references to image URLs instead of "image" objects when you use metafields to store data via a metafield editor app. Depending on the app, this method is still possible with a bit of tweaking - I make use out of Accentuate Custom Fields when I need resources to have non-global section data (e.g. each collection needs a different hero image).

While Accentuate supports an "image" field type, it's impossible for it to return an actual "image" object due to the limiations of metafields; it just returns an image URL:

{{ collection.metafields.accentuate.hero_image }}

Will return an image URL like:

https://cdn.accentuate.io/69262540870/4651314610246/image.jpg?2000×1334

This URL contains the image width and height in the query paramters; we can take advantage of this to calculate it's aspect ratio like this:

{% assign image_url =  collection.metafields.accentuate.hero_image %}
{% assign image_url_width = image_url | split: "?" | last | split: "x" | first | times: 1 %}
{% assign image_url_height = image_url | split: "?" | last | split: "x" | last | times: 1 %}
{% assign image_url_box_ratio = image_url_height | append: ".0" | times: 1 | divided_by: image_url_width | times: 100 | append: "%" %}

We can then use it like this:

<div style="--box-ratio: {{ image_url_box_ratio }};">
  <img data-src="{{ image_url }}" alt="" />
</div>

When developing apps with Express, at some point you'll probably need to store user data across different requests, that's where sessions come in. I was using express-session when I came across an issue, I needed to store Shopify-api-node instances across sessions.

This is how the app was structured at first:

// entry-index.js

var express = require("express");
var session = require("express-session");
var RedisStore = require("connect-redis")(session);

var middlewareShopify = require("./middleware-shopify");
var routerRoutes = require("./router-routes");

var app = express();
var appPort = process.env.PORT || 3000;

app.use(session({
  store: new RedisStore({ host: "localhost", port: 6379, ttl: 260 }),
  secret: "gu2cQL7z2z4pKypm",
  resave: false,
  saveUninitialized: true
}));

app.use(middlewareShopify);
app.use(routerRoutes);

app.listen(appPort, () => {
  console.log(`App listening on port ${appPort}!`);
});

// middleware-shopify.js

module.exports = (req, res, next) => {
  if( !req.session.shopName || !req.session.apiKey || !req.session.password ) {
    req.session.shopName = req.query.shopName;
    req.session.apiKey = req.query.apiKey;
    req.session.password = req.query.password;
  }

  var { shopName, apiKey, password }  = req.session;

  if( !shopName || !apiKey || !password ) {
    return res.status(500).send("Something broke.");
  }

  return next();
};

// routes-routes.js

var express = require("express");

var Shopify = require("shopify-api-node");

var router = express.Router();

router.get("/", (req, res) => {
  var { shopName, apiKey, password }  = req.session;

  var shopify = new Shopify({
    shopName,
    apiKey,
    password,
    autoLimit: true
  });

  shopify.shop.get()
    .then((shop) => {
      return res.send(JSON.stringify(shop));
    })
    .catch((err) => {
      return res.status(500).send("Something broke.");
    });
});

router.get("/other-route", (req, res) => {
  var { shopName, apiKey, password }  = req.session;

  var shopify = new Shopify({
    shopName,
    apiKey,
    password,
    autoLimit: true
  });

  shopify.shop.get()
    .then((shop) => {
      return res.send(JSON.stringify(shop));
    })
    .catch(() => {
      return res.status(500).send("Something broke.");
    });
});

module.exports = router;

This works like so:

1. Visit the URL: https://localhost:3000 and you'll get an error due to the lack of required query parameters (shopName, apiKey and password).
2. Visit a URL like: http://localhost:3000/?shopName=your-shop-name&apiKey=your-api-key&password=your-app-password and you'll see data displayed from an API call to the your-shop-name shop.
3. The query parameters are now saved to your session, so you can now visit routes without the query parameters and it'll still work.

This is great and almost works exactly how I want, but there's one issue; every route defines a new Shopify instance. If you take a look at the Shopify-api-node documentation, you'll see it provides a autoLimit option, this is a simple way around hitting the Shopify API call limit. The only catch is that for autoLimit to work properly, there needs to be just one Shopify instance per shop.

My first thought was to setup the Shopify instance in the middleware-shopify middleware, like this:

// middleware-shopify.js

var Shopify = require("shopify-api-node");

module.exports = (req, res, next) => {
  if( !req.session.shopName || !req.session.apiKey || !req.session.password ) {
    req.session.shopName = req.query.shopName;
    req.session.apiKey = req.query.apiKey;
    req.session.password = req.query.password;
  }

  var { shopName, apiKey, password }  = req.session;

  if( !shopName || !apiKey || !password ) {
    return res.status(500).send("Something broke.");
  }

  if( !req.session.shopify ) {
    req.session.shopify = new Shopify({
      shopName,
      apiKey,
      password,
      autoLimit: true
    });
  }

  return next();
};

Then in my router-routes.js router, I could use it like this:

router.get("/", (req, res) => {
  var { shopify }  = req.session;

  shopify.shop.get()
    .then((shop) => {
      return res.send(JSON.stringify(shop));
    })
    .catch((err) => {
      return res.status(500).send("Something broke.");
    });
});

This doesn't work because you can only store JSON-serializable data in req.session, instances can't be serialized. What I ended up doing was creating a session/Shopify instance map, each session gets it's own Shopify instance, identified via the session.id. I started off by creating a new object-shopifys.js file which exports an empty object:

// object-shopifys.js

module.exports = {};

I then changed the middleware-shopify middleware, like this:

// middleware-shopify.js

var Shopify = require("shopify-api-node");

var shopifys = require("./object-shopifys");

module.exports = (req, res, next) => {
  if( !req.session.shopName || !req.session.apiKey || !req.session.password ) {
    req.session.shopName = req.query.shopName;
    req.session.apiKey = req.query.apiKey;
    req.session.password = req.query.password;
  }

  var { shopName, apiKey, password }  = req.session;

  if( !shopName || !apiKey || !password ) {
    return res.status(500).send("Something broke.");
  }

  if( !shopifys[req.session.id] ) {
    shopifys[req.session.id] = new Shopify({
      shopName,
      apiKey,
      password,
      autoLimit: true
    });
  }

  return next();
};

By default, the shopifys object is empty, but after the middleware has executed for the first time of the users session, it'll look like:

// `Shopify...` refers to the actual instance, I left it out
// due to brevity.
{
  "Xur_jku_V-pUfwu3tuNtAqEydp8CTxbK": Shopify...
}

I then changed the router to reference the new shopifys object:

// router-routes.js

var express = require("express");

var shopifys = require("./object-shopifys");

var router = express.Router();

router.get("/", (req, res) => {
  var shopify = shopifys[req.session.id];

  shopify.shop.get()
    .then((shop) => {
      return res.send(JSON.stringify(shop));
    })
    .catch((err) => {
      return res.status(500).send("Something broke.");
    });
});

router.get("/other-route", (req, res) => {
  var shopify = shopifys[req.session.id];

  shopify.shop.get()
    .then((shop) => {
      return res.send(JSON.stringify(shop));
    })
    .catch(() => {
      return res.status(500).send("Something broke.");
    });
});

module.exports = router;

There we go, each session gets one Shopify instance and we don't have to worry about hitting the API call limit if we navigate to multiple API-heavy routes at the same time.

One thing we do have to worry about is a potential memory leak. Over time the shopifys object will build up and get larger. A simple solution would be to setup a cron-job which periodically checks the session IDs in the shopifys map and compares them to the redis sess:* keys, if the key no longer exists in redis, then remove it from the shopifys map.

I'd like to thank Luigi Pinca (the main contributer of the Shopify-api-node module) for walking me through this on a GitHub issue I opened.

I recently spent a couple of days building a tool in the form of a small web app Shopify Liquid REPL, it's similiar to the Bable REPL, but it takes Shopify Liquid (different to vanilla Liquid) and outputs the compiled code.

I built this because I was tired of spinning up a new development shop/theme every time I wanted to simply test out the capabilities of Liquid, I used to rely on another tool named DropPen for this, but that seems to be broken nowadays.

I originally planned on using Shopify/liquid (what I call "vanilla Liquid") on my own server and handling the compiling through that, but there's quite a lot of differences between vanilla Liquid and the Liquid used on the actual Shopify servers. As stated here, Shopify claim:

Shopify Themes use an extended version of Liquid with a variety of additional objects, tags, and filters

For my REPL to function properly, the input Liquid needs to be run through the actual Shopify servers, luckily this isn't too hard when you combine usage of the REST Admin API with the ability to access alternative theme templates via a view query paramater. The mechanism behind this works like this:

• Get Liquid input from the form POST data
• Upload the Liquid input as a new alternate template via the Asset API, e.g. /templates/index.1nfn38hgj38g.liquid
• Request the shop with the new alternate tempalte active, e.g. https://shop-name.myshopify.com/?view=1nfn38hgj38g
• Return the content
• Delete the alternate template from the theme

My Express route for this looks like:

app.post("/", (req, res) => {
  // Get Liquid input from the form POST data
  var input = `{% layout none %}${req.body.input}`;

  // https://github.com/klughammer/node-randomstring
  var template_suffix = randomstring.generate({
    length: 12,
    charset: "alphabetic"
  });

  var asset_key = `templates/index.${template_suffix}.liquid`;

  // Upload the Liquid input as a new alternate template
  shopify.asset.create(shop_theme_id, {
    "key": asset_key,
    "value": input
  })
    .then(() => {
      // Request the shop with the new alternate tempalte active
      return request({
        url: `${shop_url}/?view=${template_suffix}`,
        headers: { "User-Agent": "Mozilla" }
      });
    })
    .then((template_res) => {
      // Delete the alternate template from the theme
      shopify.asset.delete(shop_theme_id, {
        asset: {
          "key": asset_key
        }
      });

      // Return the content
      return res.send(template_res);
    });
});

Now on the front-end we just need a form like:

<form method="post" action="/">
  <textarea name="input"></textarea>
  <button type="submit">Submit</button>
</form>

That'll hit the Express route and give us the compiled Liquid output. I wanted a split-screen editor so I do this via AJAX with an input field to the left and the output field to the right.

In the end I opted to develop the entire front-end with Shopify Polaris - Shopifys own app React powered JS framework. I broke everything down into their own dedicated components, moved all state and methods into a container component EditorContainer and used the new React 16.3.0 Context API to avoid prop-drilling.

You can see the source code to the app on my GitHub.

After spending a fair amount of time spent tweaking existing "off-the-shelf" Shopify themes, I've come to realise one of my biggest annoyances with them (most of them anyways, some of them are genuinely beautifully coded.) It's not the lack of CSS structure / conventions, it's not the massive spaghetti code Javascript file, it's not even the never-ending theme settings (newsflash: no site needs over 20 colour options); it's the ridiculously long HTML attributes filled with Liquid logic.

What I'm talking about looks something like this:

<div class="collection-banner" style="{% if settings.collection_header_bg_color != blank %}background-color: {{ settings.collection_header_bg_color }};{% endif %} {% if collection.image %}background-image: url('{{ collection.image | img_url: 'master' }}');{% endif %}">
  <div class="columns sixteen {% if settings.collection_image_text_align == 'left' %}text-align-left{% elsif settings.collection_image_text_align == 'right' %}text-align-right{% else %}text-align-center{% endif %}">
    <h1 class="headline" style="{% if settings.collection_image_text_color != blank %}color: {{ settings.collection_image_text_color }};{% endif %}">
      {{ collection.title }}
    </h1>

    <p class="subtitle" style="{% if settings.collection_image_text_color_2 != blank %}color: {{ settings.collection_image_text_color_2 }};{% endif %}">
      {{ collection.description }}
    </p>
  </div>
</div>

I can't express how much I loathe working with code like the above, the logic-filled HTML attributes cause so much unreadability, it's a mess and it makes debugging a bit of a nightmare.

I've started to use a little convention to avoid this problem, it involves creating a lot of variables, but separates the logic from the attributes pretty nicely. The above [bad] code could be re-factored to the following [improved] code:

{% assign bg_color = settings.collection_header_bg_color %}
{% assign bg_color_style = "background-color:" | append: bg_color | append: ";" %}
{% if bg_color == blank %} {% assign bg_color_style = "" %} {% endif %}

{% assign bg_image = collection.image %}
{% assign bg_image_src = bg_image | img_url: "master" %}
{% assign bg_image_style = "background-image: url(" | append: bg_image_src | append: ");" %}
{% unless bg_image %} {% assign bg_image_style = "" %} {% endunless %}

{% assign text_align = settings.collection_image_text_align %}
{% assign text_align_class = "text-" | append: text_align %}

{% assign headline_color = settings.collection_image_text_color %}
{% assign headline_color_style = "color:" | append: headline_color | append: ";" %}
{% if headline_color == blank %} {% assign headline_color_style = "" %} {% endif %}

{% assign description_color = settings.collection_image_text_color_2 %}
{% assign description_color_style = "color:" | append: description_color | append: ";" %}
{% if description_color == blank %} {% assign description_color_style = "" %} {% endif %}

<div class="collection-banner" style="{{ bg_color_style }} {{ bg_image_style }}">
  <div class="columns sixteen {{ text_align_class }}">
    <h1 class="headline" style="{{ headline_color_style }}">
      {{ collection.title }}
    </h1>

    <p class="subtitle" style="{{ description_color_style }}">
      {{ collection.description }}
    </p>
  </div>
</div>

There we go, our logic and markup are completely separated now. You could argue that at 31 lines of code, this brings in the re-factored version at almost three times the size of the original 11 line version and that this is "bad", but it really isn't; more lines of code != worse code, in this case it's 10x more readable and pretty much self-documenting, which is awesome!

As long as the above code is kept in it's own snippet (something like snippets/collection-header.liquid), as most of the main components of each template should be, then I think it's completely fine. It's not like we're adding bloat to the front-end and sacrificing load times for a little developer convenience / code readability, we're just throwing a few more lines of Liquid at the blazing fast Shopify servers, which is no biggie at all.

I recently worked on a Shopify theme project where images uploaded to the products on this store were all quite large in height compared to their width, a grid of the products looks something like this:

Shopify will generate a lot of images from each image uploaded to a product, all with different sizes, these sizes are documented here. The problem I faced is that the different sized images generated all preserve the original aspect ratio (which is expected I guess), for example, if I uploaded an image which was 600x975px and used the large generated size variation of this image it would be 295x480px because the large image size returns the image at a maximum size of 480x480px pixels whilst preserving the original aspect ratio. This is how you use the image with the preserved original aspect ratio:

<img src="{{ image.src | img_url: 'large' }}" alt="{{ image.alt | escape }}">

What if I wanted to use a square cropped version of this image like you can with WordPress? Well it turns out Shopify generates a cropped variation of each image uploaded to a product too, but for some reason this isn't documented anywhere. This is how you use the square cropped version of the image:

{% assign cropped_img_size = 'large' %}
{% assign cropped_img = image.src | img_url: cropped_img_size | replace: '.jpg', '_cropped.jpg' | replace: '.gif', '_cropped.gif' | replace: '.png', '_cropped.png' %}

<img src="{{ cropped_img }}" alt="{{ image.alt | escape }}">

The best thing about the cropped variation is that you can still use any of the already documented image sizes, just change the cropped_img_size variable to what size you want. So the above code would spit out a 480x480px image from any size image uploaded to the product, even very small images (below 480x480px), small images get enlarged to fit the square. The only caveat I've found with this method is that you can't control the crop position, both the x and y axis crop positions default to center and cannot be changed.

My use case

I needed this functionality because the product images needed to be responsive, what I mean by this is that on large displays the longer image should be displayed, but on smaller displays the square cropped image should be displayed instead (art directed responsive images). This is how I did it on the product.liquid template; listing all the images uploaded to the product, with a little help from Picturefill.

{% for image in product.images %}

  {% assign img = image.src | img_url: 'grande' %}
  {% assign cropped_img = img | replace: '.jpg', '_cropped.jpg' | replace: '.gif', '_cropped.gif' | replace: '.png', '_cropped.png' %}

  <picture>
    <source srcset="{{ img }}" media="(min-width: 768px)">
    <source srcset="{{ cropped_img }}" media="(max-width: 767px)">
    <img srcset="{{ img }}" alt="{{ image.alt | escape }}">
  </picture>

{% endfor %}

Responsive web development can be tricky at the best of times, but even more so if the site in question has to support any version of Internet Explorer below version 9 (most of the time it's just IE 8 you need to tame due to the low usage statistics of IE <= 7). Old IE makes things harder because media queries (the backbone of responsive websites) aren't supported, so all code inside media query blocks is ignored. Below are the various solutions I've tried out which I wasn't 100% happy with:

• JS based media query polyfills (Respond.js, css3-mediaqueries.js)
  - Performance issues, also what about users with no JS and old IE?
• Mobile-first / progressive enhancement
  - This is a great solution, I use a similar method on this site, but what if the client insists the layout needs to look the same on both modern browsers and old IE?
• Only ever using max-width based media queries
  - On larger sites this will lead to horrible CSS as it will require a lot of style resetting at certain breakpoints.

The solution I've found to be the best does require a bit of setup but once you're up and running supporting old IE has never been so easy. It also require Sass, in my opinion this functionality alone is enough to try Sass if you haven't before (yes, this solution is that useful). In it's simplest form the file structure consists of:

- project/
  - css/
    - _base.scss
    - _config.scss
    - lt-ie-9.scss
    - style.scss
  - index.html

_base.scss is the file which contains all of your SCSS / CSS, you can write it straight into there or if you prefer to be modular about it you can import all of your CSS components into that file. With no project CSS thrown in there all it's doing is importing the _config.scss file:

@import "config";

_config.scss contains a map of your common breakpoints along with a media query mixin:

/**
  Specify breakpoints here.
 */
$breakpoints: (
  'small':    '(min-width: 480px)',
  'medium':   '(min-width: 768px)',
  'large':    '(min-width: 1024px)'
);

@mixin media-query($media-query, $lt-ie-9-support: false) {
  /**
    If we're not in the old IE stylesheet, then output the media query block.
   */
  @if $is-lt-ie-9-stylesheet == false {
    @each $name, $declaration in $breakpoints {
      @if $media-query == $name and $declaration {
        @media only screen and #{$declaration} {
          @content;
        }
      }
    }
  }
  /**
    If the media query has been set to support old IE and we are in the old IE
    stylesheet, then output the code inside the media query block but strip the
    actual media query from around it.
   */
  @if $lt-ie-9-support == true and $is-lt-ie-9-stylesheet == true {
    @content;
  }
}

lt-ie-9.scss consists of the following, this file will compile to lt-ie-9.css when ran through a Sass compiler:

$is-lt-ie-9-stylesheet: true;

@import "base";

style.scss consists of the following, this file will compile to style.css when ran through a Sass compiler:

$is-lt-ie-9-stylesheet: false;

@import "base";

Almost done now, the last step is to add the reference to the CSS files into the HTML like so:

<!--[if (lt IE 9) & (!IEMobile)]>
  <link rel="stylesheet" href="css/lt-ie-9.css">
<![endif]-->
<!--[if (gte IE 9) | (IEMobile)]><!-->
  <link rel="stylesheet" href="css/style.css">
<!--<![endif]-->

This tells the browser which CSS file to use based on what browser the page is being view on, if the browser is IE and below version 9 it will load lt-ie-9.css, however if the browser is either IE version 9 and above or not IE at all it will load style.css.

Usage

In _base.scss you'd write your SCSS / CSS as per normal but when you want to use a media query you'd do it like so:

.element {
  @include media-query(small) {
    width:50%;
  }
}

If you want the code in the media query to be read by old IE then you just simply add a second argument of true to the media-query @include like so:

.element {
  @include media-query(small, true) {
    width:50%;
  }
}

The above code will output the following in the style.scss file:

@media only screen and (min-width: 480px) {
  .element {
    width:50%;
  }
}

And the following in the lt-ie-9.scss file, stripping the media query wrapped around it:

.element {
  width:50%;
}

There you have it, almost no effort required to make old IE behave with media queries, I've used this method in a few projects of mine now and I haven't had any issues at all. I actually use this method by default on my personal front-end boilerplate which you can check out here.

Other uses

This isn't just useful for responsive stuff either, it can also be used as an alternative to Paul Irish's IE conditional classes on the <html> element. With this method you'd target elements being viewed in a specific version of IE like so:

.element {
  /*html*/.lte9 & {
    width:50%;
  }
}

The problem with that method is the IE specific styles would get loaded be the browsers no matter what browser it is, downloading CSS which doesn't get used is just wasted bytes which can add up and cause a slow-loading site. With the Sass method you'd do it like:

.element {
  @if $is-lt-ie-9-stylesheet == true {
    width:50%;
  }
}

Or if you want CSS outputted only in the non-IE stylesheet you'd do:

.element {
  @if $is-lt-ie-9-stylesheet != true {
    width:50%;
  }
}

This way the browser specific CSS only ever gets loaded by the browser which actually needs it, awesome right?

If you're an advocate of OOCSS (Oriented CSS) then you have most likely worked with Sass before as it makes development of OOCSS a lot more efficient. Here's a simple example of an object (stolen / slightly modified from inuit.css):

.nav {
  margin-left:0;
  margin-bottom:0;
  list-style:none;

  > li {
    &,
    > a {
      display:inline-block;
       *display:inline;
      zoom:1;
    }
  }
}

This object turns a regular unordered list into a horizontal row of list items, mostly for use in navigation menus. To use this I can just drop in a class in my HTML like so:

<ul class="nav">
  <li><a href="/home">Home</a></li>
  <li><a href="/about">About</a></li>
  <li><a href="/contact">Contact</a></li>
</ul>

Alternatively I can use Sass's @extend directive like so:

.menu {
  @extend .nav;
}

Just recently I've worked on a lot of responsive front-end projects in which the design briefs I'm supplied with involve usage of certain CSS objects that are only active in-between specific breakpoints. If Sass enabled usage of the @extend directive inside media queries then I could just do something like:

.menu {
  @media (min-width:768px) and (max-width:1023px) {
    @extend .nav;
  }
}

This throws the following error:

You may not @extend an outer selector from within @media.
You may only @extend selectors within the same directive.

My work around for this is changing the way I author my objects in the first place, instead of limiting the object from just being contained in a class (which limits usage to either a class in the HTML or the @extend directive in Sass) also have it in a mixin, like so:

@mixin nav {
  margin-left:0;
  margin-bottom:0;
  list-style:none;

  > li {
    &,
    > a {
      display:inline-block;
       *display:inline;
      zoom:1;
    }
  }
}
.nav { @include nav; }

Now when I want to use this object I have three options, I can either drop a class in the HTML, @extend it and thanks to the mixin and I can now @include it. The good thing about mixins is that they can be used pretty much anywhere, even inside of media query blocks, so say I wanted a .nav object which was only active in-between a certain media query I can do it like so (the tablet class prefix is just for brevity, make sure the actual media query specific class names have context):

@media (min-width:768px) and (max-width:1023px) {
  .tablet-nav {
    @include nav;
  }
}

This makes it all a lot more DRY, there are other ways of doing this like having the object styles active at all times and then undoing those styles during specific media queries but that it far from ideal, but yeah this is my take on the solution and it seems to work quite well. I have open-sourced my own personal front-end boilerplate which makes use of this CSS object authoring method, so if you want to check out more examples (including objects with sub-components etc.) then be my guest.

Ever since I started out as a front-end developer I've worked on a PC running Windows, it's served me well over the years, despite all the issues that most people in this industry seem to have with the Windows operating system I don't really have anything to complain about.

I spent a long time mulling over whether or not I was going to join the Apple bandwagon and get a Mac. Well around a month ago I took the plunge and purchased a 13.3-inch MacBook Air and I couldn't be happier with it, I've waited a few weeks to see if this purchase has turned out to be a good investment and it definitely has. The only thing that's caused some problems is transitioning from Windows to OS X which I fully anticipated considering this is my first ever Mac.

Apps

As I'm explicitly a front-end dev it was a breeze setting up the machine for work purposes, as my requirements are very lean. It was just a case of installing all the CLI tools I use (Git, Node, Ruby, Grunt etc.), installing software (Photoshop, Skype etc.) then leaving my Dropbox to download all of my files and boom, ready to twerk work! There were a couple of Windows-only apps I had to sacrifice but it didn't take long to find OS X alternatives, all together, the setting up process was mostly painless.

For a while I've gotten into the habit of using Dropbox for pretty much everything, this includes hosting of my app data, so it's easy to have the same software settings / plugins synced across different machines. I do this mostly for 1Password (all of my login details, encrypted of course), Sublime Text (all settings and packages) and XAMPP (web project files which require a local Apache / SQL server to run). I'm so glad I got everything synced on Dropbox prior to upgrading my work machine, it saved a lot of headaches and it's so efficient because I can pretty much work from any machine (given an hour or two to set it up).

Internet Explorer

Just when I thought I was done for good with Windows... It turns out the best way to run IE on Mac machines is through installing virtual machines that run the Windows operating system. This was a bit of a drag to set up due to the huge file sizes of the virtual machine files from Modern.IE and my not-so-great Internet speed but once everything is set up it's pretty painless to test in IE, plus it's kind of cool to see Windows actually running inside of OS X.

Portability

Not only is this my first Mac work machine, it's also my first portable work machine, I've only ever worked on fixed desktop PCs. Most of the time I work with my MacBook connected to a 24-inch monitor but sometimes it's nice to have a change the surroundings where I work from, I've found it makes me a lot more productive compared to staying in the same place for hours on end.

Downsides

Though the transition from Windows to OS X has been mostly effortless I have come across a few things that I'm not a huge fan of.

Archives

With Windows, the native way to handle .zip archive files is quite seamless; it just opens like a native directory. With OS X, when you open one it automatically extracts all the file contents into its own directory in the same directory as the .zip file. This really bugs me; it causes unnecessary clutter and doesn't feel graceful at all. I've tried a few custom OS X archive GUI apps but none seem to function as seamless as I prefer, this isn't a huge deal and I'm sure I'll get used to it.

.DS_Store

This thing drives me crazy, basically OS X comes with a built in app called "Finder", and it's for navigating around files on the machine's hard drive. Every time you open a directory Finder automatically generates a hidden .DS_Store file which holds meta data about the directory, if you delete it, it comes straight back. You might not think this is a big deal but when you have it so hidden files are visible it get's hugely annoying. It means I have to exclude that file from all directories when working with Git (using .gitignore), it also means that if I upload an entire directory via FTP (which is sometimes needed), all those annoying .DS_Store files come with it.

Other little things

Other things that I've noticed I don't like about OS X are quirks I've grown accustomed to while working on Windows machines all of my life. One thing is that you can't quickly permanently delete files / directories, in Windows it's a simple keyboard shortcut shift + del, but in OS X you have to move the file to Trash then empty the Trash which gets old fast. Another thing I grew fond of in Windows was right clicking in a directory and being able to create a new file there and then, mostly I'd use this when creating new .html / .css files, you can't do this in OS X either, I know it's a very small thing but when you're so used to doing it you grow to miss it.

Conclusion

In the end though I'm smitten for this MacBook and OS X, it's significantly faster than my old Windows machine and a lot more fun to work with. I've always been a lover of Apple, I've had this machine for a few weeks now and I still get blown away with even it's external appearance, the attention to detail Apple put into their products is phenomenal.

This upgrade has made my job easier and a lot more enjoyable, if you're reading this (people read this right?) and are wanting to get a Mac but are worried about switching from Windows to OS X, don't be... do it, do it now!

"How is this done again?", those five words I'm noticing I'm asking myself more and more. A lot of the time when I'm working on a project I'll have to accomplish a specific task (which I have done before) which I know how to do, but always forget the best way to go about it, I'm pretty sure I'm not the only one who's guilty of this (I hope!) Most of the time this ends up with me either going back to an older projects code and pasting it from there or having to completely rewrite it which sometimes doesn't even end up as efficient as the original code, both of these solutions aren't really ideal. I suppose I could just whack these easy forgettable tasks into a GitHub Gist but instead I decided to start this tutorial themed post series so I can hopefully help out a few fellow developers who are in a similar position to me.

This post is focussed around the WordPress loop and manipulating it to display posts within rows and columns in a specific way. To clarify, I was working on a clients site and they wanted their posts to be displayed in a grid system where every two posts were contained in their own wrappers which acted as grid rows (<div class="row"></div>), so the HTML outputted by the loop had to be like so:

<div class="row">
  <article>
    <a href="http://post-link">Post title</a>
  </article>
  <article>
    <a href="http://post-link">Post title</a>
  </article>
</div>

<div class="row">
  <article>
    <a href="http://post-link">Post title</a>
  </article>
  <article>
    <a href="http://post-link">Post title</a>
  </article>
</div>

Cool, now where's the code!?

To accomplish the loop outputting the posts in this fashion I had to make use of the PHP modulus and post-increment operators, the loop I used is shown below (commented to clarify what each snippet is for):

<?php if (have_posts()) : ?>

  <?php
    /**
     * Start post counter at 0.
     */
    $i = 0;
    while (have_posts()) : the_post();
    /**
     * Define the number of posts displayed per row.
     */
    $posts_per_row = 2;
    /**
     * HTML of the row opening & closing tags.
     */
    $open = '<div class="row">';
    $close = '</div>';
    /**
     * Output HTML of the row opening & closing tags when and where they should be
     * outputted.
     */
    echo !($i % $posts_per_row) && $i ? $close : '',
         !($i % $posts_per_row) ? $open : '';

    /**
     * Regular post loop stuff below.
     */
  ?>

    <article>
      <a href="<?php the_permalink(); ?>"><?php the_title(); ?></a>
    </article>

  <?php
    /**
     * Update post counter throughout each post iterated over.
     */
    $i++;
    endwhile;
    /**
     * Output HTML of the row closing tag again (this is needed in case there aren't
     * the same number of posts in each row).
     */
    echo ($i) ? $close : '';
  ?>

<?php endif; ?>

Sorted, now the posts are perfectly contained in their own rows and columns and there's never any unclosed HTML elements etc. (some other tutorials on how to accomplish this fall victim to this.) All HTML outputted is always valid and one of the best things about this is that it works perfectly with pagination, I thought it would throw a spanner in the works but nope, it just works.

This has other uses to!

I've found this method can also be useful when you need to display posts in a carousel / slideshow, I did this when I developed a re-design of a clients site, one of the features were that the posts were displayed by their thumbnail inside an image carousel using the jQuery plugin Cycle2, you can see that in action on the live site http://goo.gl/5Gglb2. The HTML the loop outputted the posts in had to be structured like so:

<ul>
  <li>
    <img src="http://post-thumbnail" alt="">
  </li>
  <li>
    <img src="http://post-thumbnail" alt="">
  </li>
  <li>
    <img src="http://post-thumbnail" alt="">
  </li>
</ul>

<ul>
  <li>
    <img src="http://post-thumbnail" alt="">
  </li>
  <li>
    <img src="http://post-thumbnail" alt="">
  </li>
  <li>
    <img src="http://post-thumbnail" alt="">
  </li>
</ul>

All I needed to do to accomplish this was to change a few loop variables; $posts_per_row to 3, $open to <ul>, $close to </ul> and voila, done!

I'll no doubt be back extending the "How is this done again?" post series soon, I seem to be way too good at forgetting code not to.

If you haven't heard of Grunt (if so, where have you been hiding?), it's a task runner powered by JavaScript and Node.js, don't worry, you don't have to be a JavaScript / Node.js developer to use Grunt (just like you don't have to be a Ruby developer to use Sass). You can use it for a lot of things thanks to the community for publishing so many plugins, a couple of examples being Cssmin (CSS compression) and Uglify (JavaScript minification).

This post assumes you're at least a little bit familiar with Grunt so I'm not going to write up a tutorial on how to install Grunt and its dependencies, in a nutshell you set up your Gruntfile.js file and configure tasks and plugins to do what you want, when you want. When you've got all your tasks set up, you just run the grunt command (which runs the default task) and you're all set, or if you have multiple tasks you'd run grunt task-name.

Also, if you were wondering about the title of this post, it's reffering to the fact that ever since I had my Grunt "aha" moment I haven't been able to stop from myself sharing its power with people. Yep it's that awesome it even caused me to come up with that awfully lame form of wordplay!

What I use Grunt for

On this site I use Grunt for a lot of things (short of dressing and feeding me), a lot of what I use it for on this site is very specific to this site as a whole and there will be a lot of things in there most projects won't need, I've heavily commented my Gruntfile.js file so it makes as much sense as possible and which snippets do which task and why I want them in place. I have also noted down which plugins I have used with links to them.

Below is my Gruntfile.js setup:

module.exports = function(grunt) {

  /**
   * Instead of loading each task one by one using `grunt.loadNpmTasks`,
   * automatically load all dependencies from the `package.json` file.
   *
   * Plugin: http://github.com/sindresorhus/load-grunt-tasks
   */
  require('load-grunt-tasks')(grunt);

  grunt.initConfig({

    pkg: grunt.file.readJSON('package.json'),




    /**
     * Start a local server using the compiled Jekyll site directory as the base.
     *
     * Plugin: http://github.com/gruntjs/grunt-contrib-connect
     */
    connect: {
      server: {
        options: {
          hostname: '*',
          port: 12000,
          base: '_site'
        }
      }
    },


    /**
     * Compile Sass files to CSS files.
     *
     * Plugin: http://github.com/gruntjs/grunt-contrib-sass
     */
    sass: {
      dist: {
        options: {
          style: 'compressed'
        },
        files: [{
          expand: true,
          cwd: 'lib/css',
          src: ['**/*.scss'],
          dest: 'lib/css',
          ext: '.min.css'
        }]
      }
    },


    /**
     * Uglify (minify) `main.js` file.
     *
     * Plugin: http://github.com/gruntjs/grunt-contrib-uglify
     */
    uglify: {
      dist: {
        files: {
          'lib/js/main.min.js': 'lib/js/main.js'
        }
      }
    },


    /**
     * Build Jekyll site.
     *
     * Plugin: http://github.com/dannygarcia/grunt-jekyll
     */
    jekyll: {
      dist: {
        options: {
          bundleExec: true
        }
      }
    },


    /**
     * Minify all HTML / PHP files that Jekyll builds.
     *
     * Plugin: http://github.com/gruntjs/grunt-contrib-htmlmin
     */
    htmlmin: {
      dist: {
        options: {
          removeComments: true,
          collapseWhitespace: true
        },
        files: [{
          expand: true,
          cwd: '_site',
          src: ['**/*.{html,php}'],
          dest: '_site'
        }]
      }
    },


    /**
     * Instead of getting Jekyll to rebuild every time a file in `lib` is changed
     * (slow), copy and replace the old `lib` with the new one in the compiled Jekyll
     * site directory. This only gets ran during the `watch` task because Jekyll
     * does it on the initial build.

     * Plugin: https://github.com/gruntjs/grunt-contrib-copy
     */
    copy: {
      lib : {
        files: [{
          expand: true,
          src: ['lib/**/*'],
          dest: '_site'
        }]
      }
    },


    /**
     * Runs tasks against changed watched files.
     *
     * Plugin: http://github.com/gruntjs/grunt-contrib-watch
     */
    watch: {
      /**
       * Watch any Sass files, if any are modified, recompile them to CSS.
       */
      sass: {
        files: 'lib/css/**/*.scss',
        tasks: ['sass'],
        options: {
          spawn: true
        }
      },

      /**
       * Watch any JavaScript files, if any are modified, reuglify them.
       */
      uglify: {
        files: 'lib/js/main.js',
        tasks: ['uglify'],
        options: {
          spawn: false
        }
      },

      /**
       * Watch any Jekyll related files, if any are modified, rebuild and minify the Jekyll site,
       */
      jekyll: {
        files: ['_includes/**/*', '_layouts/**/*', '_plugins/**/*', '_posts/**/*', '*.html', '_config.yml', '_site/**/*.{html,php}'],
        tasks: ['jekyll', 'htmlmin'],
        options: {
          spawn: false
        }
      },

      /**
       * Watch any files in the `lib` directory, if any are modified, copy and replace
       * that directory to the compiled Jekyll site directory (instead of getting Jekyll
       * to rebuild the entire site every time a file in `lib` is modified which is a lot
       * slower).
       */
      copy: {
        files: ['lib/**/*'],
        tasks: ['copy'],
        options: {
          spawn: false
        }
      }
    },


    /**
     * Upload (and replace the old files) the compiled Jekyll site directory to the
     * server.
     *
     * 1. For some reason when Jekyll builds the site files, it builds random `pageN`
     *    directories in the compiled site root directory, this isn't a major problem,
     *    just an annoyance. This stops these directories getting uploaded to the server.
     * 2. Certain files which should be kept on the server even when they are not
     *    presented locally.
     *
     * Plugin: http://github.com/inossidabile/grunt-ftpush
     */
    ftpush: {
      dist: {
        auth: {
          host: 'tomblanchard.co.uk',
          port: 21,
          authKey: 'tomblanchard.co.uk'
        },
        src: '_site',
        dest: '/public_html/root',
        exclusions: ['page*', '!**/*/page*'], /* [1] */
        keep: ['googlea67e882a592198c5.html', 'favicon.ico'] /* [2] */
      }
    },


    /**
     * Run command line tools.
     *
     * Plugin: http://github.com/sindresorhus/grunt-shell
     */
    shell: {
      /**
       * Push the uncompiled Jekyll source code to GitHub.
       *
       * 1. Updates the Git index (including deleted files).
       * 2. Commits any changes, with the commit message as the current date and time.
       * 3. Pushes changes to the remote repository.
       */
      git: {
        command: [
          'git add -A', /* [1] */
          'git commit -m "<%= grunt.template.today("isoDateTime") %>"', /* [2] */
          'git push' /* [3] */
        ].join('&&')
      }
    }




  });

  /**
   * The `default` task, it builds / compiles the site, then watches for changes,
   * then rebuilds / recompiles.
   *
   * Usage: `grunt` or `grunt default`
   */
  grunt.registerTask('default', [
    'connect',
    'sass',
    'uglify',
    'jekyll',
    'htmlmin',
    'watch'
  ]);


  /**
   * The `push` task, it uploads the compiled site to the server then pushes
   * uncompiled Jekyll source code to GitHub.
   *
   * Usage: `grunt push`
   */
  grunt.registerTask('push', [
    'ftpush',
    'shell'
  ]);

};

So there you have it, go fourth and learn!