This is a quick “heads-up” for all our Spiffy Stores web designers and developers out there who are customizing and building fantastic themes for their customers.

As you already know, Spiffy Stores has always supported the use of Sass (Syntactically Awesome Style Sheets) to ease the development of stylesheets in your themes. It’s a great productivity tool and makes the whole job of building and managing your CSS styles a whole lot easier. In fact, at Spiffy Stores, we’ve been using Sass almost from day one, well over ten years ago.

Since it’s such a great productivity tool, we were a bit concerned to learn that our current implementation was being deprecated in favour of a newly developed version called Dart Sass, and that this version would be the basis of all future development going forward.

We’re happy to announce that we’ve just built a bridge to the new Dart Sass that can be used by all existing themes and any new themes without any change, ensuring our long-term commitment to the Sass language and environment.

We’re aware that another ecommerce platform has decided that supporting Sass is too difficult, and has chosen to withdraw support for Sass from their theme platform, requiring instead that all stylesheets be coded using native CSS. Booooo! As web developers ourselves, we’d be pretty unhappy about something like this, so if you know anyone who has been affected by this change, then please let them know that Spiffy Stores is fully behind Sass and it’s continued importance in the web development stack.

If you have any questions about the use of Sass, or developing themes for Spiffy Stores, please let us know at support@spiffystores.com.au.

From time to time we post some notes about technical issues that we’ve encountered during our development work on Spiffy Stores. There are a lot of moving parts to manage, and sometimes we come across some tips or techniques that can help others to build their projects.

In this case, we’ve been looking at how to configure Webpacker 6 (currently Beta 7) under Rails 6.1, which acts as a wrapper to the latest version of Webpack 5. Now, as anyone who’s used Webpack since it was introduced as an option in Rails 5 will attest to, it’s not an easy package to get working properly.

The new versions of Webpacker and Webpack bring around some changes to the way things are configured, and unfortunately, some of the documentation is lacking, or indeed, wrong.

For our environment, we need jQuery as a starter. The trick with Webpack is to get the code loaded and assigned to the global variables, $ and jQuery. The trick with jQuery is to realize that the node modules version provides both a distributed module and also the source code which can be used to build the module with Webpack. If you just

require("jquery")

then you’ll get the pre-built module. It turns out that it’s better to build it from source instead.

If you’ve followed the migration documentation, you should have a custom.js under your webpack directory.

module.exports = {
   resolve: {
     alias: {
       jquery: 'jquery/src/jquery'
     }
   }
 }

Requiring jquery now, pulls in the source files instead, and this will build jQuery with the appropriate global references.

Another important “gotcha” with Webpacker 6 is that when you include the javascript_pack_tag in your layout, you MUST include it only once.

<%= javascript_pack_tag('application', 'common', 'customer', data: { turbolinks_track: :reload }) %>

Webpack builds a number of different file chunks for each entry point, and this means that the javascript_pack_tag will generate a number of <script> tags, one for each chunk. If you have multiple entry point files, then you must include them all on a single javascript_pack_tag and not create a separate tag for each entry point.

Unfortunately, coming from a Sprockets background, most Rails programmers will be used to creating multiple javascript_include_tags, but this is not the case for Webpacker.

If you happen to use multiple javascript_pack_tags, you’ll likely find that scripts may be loaded multiple times. In many cases, this may not be obvious, but if you see errors from @rails/ujs, then this is probably because it is being loaded multiple times by Webpack.

Australia’s new data retention laws start today, and this means that ISPs are obliged to collect and keep records about your digital activities for 2 years, and to make those records available to various government agencies on demand without the need for any warrants or legal oversight.

The good news is that the email services provided by Spiffy Stores and Domain Hosting Shop are not subject to these data retention laws. In basic terms, the law only applies to carriage service providers, which means anyone who provides the physical connection for your home or office to the Internet or telephone system.

We will keep your Spiffy Stores email safe and secure, and you can send and receive email secure in the knowledge that the messages will not be archived and retained in any way, and will not be available to any government agency.

Here’s a little ecommerce trick that everyone seems to forget about.

Make sure that your customers can find the product they want, when they do a search using your store’s built-in search function!

At Spiffy Stores we try to strive for excellence in the way we design and build our software. This sometimes means going back to look at existing functions to see if we can improve them in some way.

This is part of our philosophy and it’s a way of setting us apart from the general way of the Internet where lots of colour and movement appear to be more important than providing something with real substance.

So, some months ago, when we had a few queries from customers wondering if there was a way to provide a better fuzzy search capability, we decided to have another look at how we provide our search function. It’s import that, no matter what the customer types in as a search query, we need to try to match the results as accurately as possible.

This makes a lot of sense. If a customer is searching for a product, and doesn’t find it easily, then they’ll move along to the next retailer. As a store owner, it’s in your best interests to try to find what the customer wants as accurately as possible.

It turns out that most of the off-the-shelf search software doesn’t really do a very good job when it comes to fuzzy searching. Writing code to produce a really good fuzzy search is actually quite difficult, so we ended up writing our own custom code to support fuzzy searching, and it looks like the results are pretty encouraging. We’re going to continue to monitor the performance of our search data, and hopefully this means that store owners will start seeing improved sales as customers start to get better search matches.

For everyone out there who’s not a Spiffy Store owner, why not spend a few moments trying out your current store’s search function and see how good it is at finding what you want. The chances are that it’s been developed using a stock-standard search package, and you may be losing sales because your customers aren’t easily finding exactly what they want.

We love adding new stuff to Spiffy Stores, and we’re pleased to announce that we’ve just finished putting the final polish on a brand new feature.

When you manage your online store, there’s obviously lots to think about in terms of products, inventory, prices and shipping. But until now, there’s been an important part missing from this equation – your customers!

As ever, we’re anxious to make sure we’re providing you with the very best tools and support to help you run your ecommerce venture successfully and to make lots of money, so we’ve done something about this. From today, you’ll see a new tab in your Spiffy Stores Toolbox, right next to your ‘orders’, called ‘customers’.

Click on this and you’ll be taken to an overview list of all your customers and you’ll see options to sort and filter your customer list, so that you can easily see who’s ordered what, how much they’ve spent and where they are located. Add to this our fantastic new custom search filters that let you create and save your own searches, and you’ll soon see these as an indispensable part of your marketing armoury.

There’s much more detail about this new feature in our Knowledge Base at https://www.spiffystores.com.au/kb/Information_about_your_customers  so we recommend you have a quick look at the documentation to see how this can help you better understand your customers.

But wait, there’s more! This is just phase 1 in our rollout of our new customer-related features. Be on the lookout for some exciting new additions to your Spiffy Store in the coming months.

From time to time we like to share technical tips when we’ve uncovered a solution to a problem that might help other Rails developers.

Spiffy Stores is written using the Ruby on Rails framework, and we encountered a glitch with the Rails3 layouts. Basically we couldn’t get the layout to display, even though all the syntax was correct. Others have experienced this sort of problem. See http://stackoverflow.com/questions/6605716/cant-render-layout-in-rails-3 for an example.

After lots of digging around and tracing, the answer became clear. The AbstractController::Layouts module has an initialize method, but this method was not being called when a new controller was created.

If you experience this problem, then check any modules that you have included in your controller, as one of them has an initialize method that doesn’t call ‘super’.

If an included module needs an initialize method, then it needs to follow this pattern:

def initialize(*)
  # Module initialization code here
  super
end

If the call to ‘super’ isn’t included, then the initialization chain stops, and your controller won’t be properly initialized. You can find out all the included modules for a controller by executing this code from the console:

MyController.ancestors

We’ve always believed in pushing the technical envelope to provide advanced technical solutions to make life easier for our store owners.  This is way more important to us than the hype and gloss that you may find in the rest of the industry.

Over the past year, we’ve been talking to loads of web designers who use Spiffy Stores to create online stores for their customers. Although they love creating new e-commerce shops using our software, the resounding feedback we’ve been getting is that whilst the current Theme Editor in the Toolbox is great for small changes, it get’s a bit more difficult when designing an entire theme for a store.

For larger theme updates it’s really necessary to download the theme files to your computer, edit them and then upload the new files to the server. Using the Theme Editor to do this is a bit cumbersome, and makes the design process more difficult than it should be.

We’ve listened to these concerns, and have spent considerable time and effort working on a solution… so today we’re very proud to announce a major new capability which allows all your theme files and assets to be edited directly from your computer using WebDAV enabled editors such as Adobe’s Dreamweaver, and Panic’s Coda.  If you’re on a Mac, you’re even luckier, as WebDAV is built right into OSX, and can be used in conjunction with TextMate and Taco.

To use this new feature in Windows, all you need is a WebDAV enabled editor or a utility such as NetDrive which allows WebDAV files to be mounted on your computer as a local folder. This means that you can use your favourite editor to edit your store’s theme files directly from your computer.

If you’re using a WebDAV enabled editor such as Dreamweaver, you also have access to some advanced features such a file checkout and locking so that you can work in a team without having to worry about whether someone else overwrites your changes.

If you’re a web designer and your current e-commerce software doesn’t support WebDAV, then you should seriously consider Spiffy Stores for this feature alone, as you’ll find your theme development time slashed significantly.

For more info about using WebDAV to edit your store, head over to the WebDAV section of our knowledge base.

Related articles

• Syntax highlighting – now in our Liquid template editor
• Easy image editing with the Feather Editor from Aviary.com
• Syntactically Awesome Style Sheets

A URL redirect can help your customers find your products on your new Spiffy Store site when you migrate from another software platform and your old links are still cached by the search engines. This makes the whole migration process easy and painless as you don’t run the risk of losing sales because your customers can’t find the right products.

In simple terms, a URL redirect lets you map from one web page address to another, and this is the kind of feature that you’ll find supported by most modern ecommerce and online shop builder software.

However, here at Spiffy Stores we like to provide our store owners with the best possible tools for running their online stores, so we decided to go just that little bit further to help you solve your problems without actually creating more work for you.

If you look at the URL Redirection solutions offered by other hosted e-commerce providers, you’ll quickly see that in most cases they don’t offer any form of pattern matching or wildcard support for the redirections. This means that for a large store, you may be forced to enter many thousands of redirection mappings to support the full range of possibilities. Even worse, some don’t even offer a bulk import/export feature, so you have to type in all your redirects by hand.

The Spiffy Stores URL Redirection feature not only offers you the capability of creating simple redirects, but also offers the full power of regular expressions to allow you to create complex patterns which can be used to match almost any incoming URL. Using regular expressions in your redirections can reduce thousands of redirection cases down to just a handful.

Furthermore, there’s also a bulk import/export feature that allows you to manage your redirects using a standard CSV file.

There’s more information about our new URL Redirection feature in our Knowledge Base URL Redirects article.

Until now the Theme Editor has displayed your theme’s Liquid template files in a very boring, black text field.

We think this makes it harder to edit and change your theme files than it needs to be, so we’ve added a bit of colour to the whole process.

Now, when you go to edit a theme’s Liquid file, you’ll see the text highlighted and colour-coded according to the syntax of the language. You’ll see HTML, CSS and Javascript as well as all the Liquid tags highlighted using different colours so that it makes it a lot easier to navigate your way around the file. In addition, strings, numbers and various other bits of punctuation are highlighted as well.

To round off this update, we’ve added line numbers on the left to make it easier to locate and refer to the code.

In technical terms, this is known as a syntax-directed editor, but we just call it easy to use.

Actually, it’s really “Syntactically Awesome Stylesheets”.

For all the theme designers out there, we’ve just made your life a little bit easier. We all know that sometimes CSS stylesheets can get complicated, so anything that can help you manage that complexity is a welcome bonus.

As you may already know, when you enable the Theme Editor by creating a ‘theme.settings‘ file, you can parse your CSS files by making sure they have a suffix of ‘.css.liquid‘.

Now, as part of the CSS processing that gets initiated to deal with the Liquid tags, we’ve added a pass through the SCSS processor, which is part of the SASS CSS extensions. You can read more about these CSS extensions at http://sass-lang.com

By using the CSS extensions, you can simplify your stylesheets by using variables, conditional logic, mixins and templates, nested attributes and a whole lot more. Even better, at the end of the processing you get a compressed CSS file so you can ensure that your site loads as fast as possible. Even if you don’t use any of the CSS extensions, you still get a compressed stylesheet, so that’s got to be something to smile about!

You can read more about the Spiffy Stores Theme Customizations in our Knowledge Base.

Here’s something to help you customize your Spiffy Store’s Liquid Theme for your overseas customers.

We have added some new Liquid Theme variables that will give you access to the geolocation data for your customer. This will give you access to the Country, Country Code, City and Timezone information for the customer, based on the IP address being used.

Four new methods have been added to the request variable.

[ruby title=”Sample Geolocation methods”]
{{ request.country_code}}
{{ request.country }}
{{ request.city }}
{{ request.timezone }}
[/ruby]

You can use these methods to help you display information in your theme that is customized for your customer’s location. For example, you could provide additional shipping information or information about tax free prices. The timezone information could could be used to let your customers know what your business hours are by taking into account the time differences.

You may wish to restrict certain products or pages to local customers if you’re running a promotion, so you can use the country information to display different information to overseas customers. For example, you may be offering free shipping to local customers only.

Further information can be found at

https://www.spiffystores.com.au/kb/Liquid_Template_Variables_-_request

With more and more people on the move and accessing their Spiffy Stores Toolbox from mobile devices, we’ve added a quick and simple way for you to get timely updates when your online store gets new orders.

Browse to your “Overview of your orders” page in your Spiffy Store Toolbox and you’ll now see an additional entry in the sidebar which includes a data feed link to all your most recent orders.

The new data feed link is encrypted and password protected so you can be sure that your online stores’ customers’ data is safe and secure.

There is more information available on this new feature in our Knowledge Base at https://www.spiffystores.com.au/kb/Recent_Orders_Data_Feed.

You can use this link on your mobile device to find out when new orders have been placed in your online store rather than having to monitor your email for the email notifications you normally receive.

We recently enabled a small security enhancement to the Spiffy Stores software to prevent a security attack called Cross Site Request Forgery (CSRF).

Basically, now an encrypted token is generated and inserted into every form on the store web pages. This prevents a hacker from copying a form from the site and tricking you into executing the form from a fake site, thus giving the hacker access to your account.

Whilst it was extremely unlikely that this sort of attack would work because of the way in which the Spiffy Stores software is designed, it never hurts to improve security wherever possible.

However, it turns out to have an unintended bonus effect!

Spiffy Stores is one of the few ecommerce solutions that has a “Contact Us” form built into your store. This form is generated for you automatically and you don’t need to use a third-party online form service to get something as essential as a contact form.

Now that we have added the Cross Site Request Forgery code, we are seeing instances of spammers who have “copied” the contact forms from various sites and have built them into scripts to try to spam our store owners with fake contact form submissions. All of these attempts are now failing because they are all detected as forgeries, and this means that your inbox will contain less of the spam generated by these pests.

Here’s a quick update.

We’ve added a small improvement to our Theme support by defining a new header variable which can be used in the Theme.liquid file as part of the section.

Rather than hand-coding author, copyright, description and keywords meta tags, you can just code

[ruby]
{{ header.author }}
{{ header.copyright }}
{{ header.description }}
{{ header.keywords }}
[/ruby]

These variables will automatically generate the appropriate meta tags for your page’s content.

The advantage of these automatically generated tags is that they structure the description information in a way that makes it easy for the search engines to extract the relevant information about your product or page and this will appear as the snippet in the search results.

For details have a look at our Knowledge Base documentation

Liquid Template Variables – header

I’ve been looking around for an implementation of a Multiset/Bag in Ruby to ease the pain of recording some of our statistics.

Some of the statistics we gather are most usefully stored as some form of “super” Set in which each unique element is stored together with a count of the number of times that element has occurred. These statistics are likely to have a large number of repeated elements, so this makes sense as it saves on space and processing.

So, after an extensive search, I was surprised at the paucity of solutions for this problem.

Eventually I hit upon

http://maraigue.hhiro.net/multiset/index-en.php

It does exactly what I want, but I decided that I would add the following custom functions. These two functions return all the items in a Multiset with the highest/lowest counts.

class Multiset
  # Return all the items with the maximum count
  def max_values
    max_value = @items.values.max
    @items.select { |k, v| v == max_value }.map { |i| i[0] }
  end

  # Return all the items with the minimum count
  def min_values
    min_value = @items.values.min
    @items.select { |k, v| v == min_value }.map { |i| i[0] }
  end
end

Linux users of the world unite… today is 1234567890 day. At 3:30pm today, Unix time will equal exactly 1234567890. It’s the geek version of the year 2000!

For various reasons, we are still running on Apache 1.3 which is fine, except for the fact that there is no easy way of determining whether a request is via an SSL session or not.

Unfortunately, this process was broken by the upgrade to Rails 2.2.2.

No probs. We just rewrite the URL to add an “ssl” prefix before it gets passed to the Rails engine.

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ http://127.0.0.1:8000/ssl/$1 [P,L]
ProxyPassReverse / http://127.0.0.1:8000/ssl/

From there, a simple route will pass the request on to our SSL Proxy controller.

map.connect 'ssl/*suburi',
            :controller => 'ssl_proxy',
            :action => 'reprocess'

Now all our ‘reprocess’ method has to do is take the request, rewrite the URI to its original form, and set an environment variable to let us know it’s an SSL request.

class SslProxyController < ActionController::Base
  def reprocess
    request.env["REQUEST_URI"] = "/#{params[:suburi].join('/')}"
    request.env["HTTPS"] = "on"

    controller = ActionController::Routing::Routes.recognize(request)
    controller.process(request, response)
    @performed_render = true
  end
end

This all broke down with the upgrade to Rails 2.2.2.

One of the new features of 2.2.2 is the addition of memoization to various system classes, including the ‘request’ object. This means that ‘request_uri’ is now memoized, and that even if we update the environment variable ‘REQUEST_URI’, the memoized value doesn’t change. When the route is recognized, it resolves to ‘reprocess’ again, and we end up in an endless loop.

The answer turns to reasonably easy to implement. All we need to do is add the following line at the start of the ‘reprocess’ method.

request.unmemoize_all if request.respond_to? :unmemoize_all

This code simply clears all the memoized variables, so they can all be loaded again using our new, proper URI.

Our store software contains an extensive set of routines for processing uploaded images and resizing them into various image sizes. We’ve recently been adding some code to support a bulk import function and it’s become necessary to somehow fake uploading a file, given a specific URL for an image.

The basic plan is to use Net::HTTP to connect to the remote server and grab the image and save it in a temporary file. It turns out that Rails contains a UploadedTempfile class which is a subclass of Tempfile, and this is used by the CGI routines to handle any uploaded files.

So all we need to do is create our own instance of UploadedTempfile, set some attributes and then pass it along to our existing routines as if it were a real uploaded file.

uri = URI.parse(image_url)
image_file_name = File.basename(uri.path) # Extract the file name
image_file = nil
begin
  timeout(10) do
    Net::HTTP.start(uri.host, uri.port) do |http|
      resp = http.get(uri.path)
      image_file = ActionController::UploadedTempfile.new(image_file_name)
      image_file.binmode
      image_file.write(resp.body)
      image_file.original_path = image_file_name
      image_file.rewind
    end
  end
rescue TimeoutError
  raise "Timeout connecting to #{uri.host}"
end

There are a few things that need to be set up, so that the fake upload file works properly.

The file is set to binary mode with

image_file.binmode

The original file name is set with

image_file.original_path = image_file_name

A content type attribute can also be set with

image_file.content_type

but we don’t use this attribute, so it’s not set here.

Finally we rewind the file so that we can read it later on in the image processing routines. When we’re finished with the temporary file, we can delete it with a

image_file.close!