An article about "best practices" for designing your store could cover a lot of territory. For now, we're going to cover the where, the why, and a few why-nots.

File structure

First, let's get familiar with the file structure. 

Log in with FTP to view your store's files. If you don't yet have FTP access for your store, submit a ticket to request access and we'll send it over securely. If you don't host with us, contact your hosting provider.

You can use an FTP client like Filezilla to log in and view your files - if you're not sure how, read through this article: How to use FTP

When you log in to FTP, if you're using one of our business solution platforms (like preFIX) you'll see folders that look like the screenshot below. If you're not using preFIX or one of our other always-up-to-date business solutions, your folder structure will look a little different, but many of the guidelines in this article will still apply to you.

  • config (read/write)
    This folder will contain some of the configuration elements of your codebase - things you can't manage in your admin console. URL rewrite / redirect rules can be applied & edited here.  

  • download (read/write)
    If your store sells downloadable items, you'll upload your files here.

  • images (read/write)
    This folder contains sub-folders which store all of the images you upload through your admin console to associate with products, categories, manufacturers, etc. You can upload/download from this folder and overwrite files as needed.

  • orderdownloads (read/write)
    If your store sells downloadable items, and you've set your store to copy files for each order, those files will appear here. More info on downloadable products can be found here.

  • skins (read/write)
    This is the folder that contains your store's Skin(s). If you're using MoreStores, you can have and use more than one skin - each skin will be stored in its own skin folder. If you started out with preFIX via our Push Button portal, you might have two skin folders here - "Default" and "Skin_1".  Your store is most likely using Skin_1. You can add custom skins and learn how to identify which skin is used here.
    • Default
      Default is the skin that comes with AspDotNetStorefront 'out of the box'.
    • Skin_1
      Skin_1 is your customized responsive template.
      • Css
        This folder stores all of your .css files that are used to apply changes to things like layout, colors, fonts throughout your store.
      • Fonts
        AspDotNetStorefront uses third party fonts (Font Awesome & Glyphicons) out of the box - these fonts are used throughout the store & admin console for icons. If you've got your own third party fonts you'd like to use, you can use Google Fonts (recommended) or you can upload and implement your font to this folder.
      • Images
        Skin-related images are stored here. Things like your store's logo, or banners on your homepage.
      • less
        less is more! "less" is a way to build and maintain consistent styles across different areas and elements of your site. Instead of copying one hexadecimal across 8 css files throughout one-billion-or-so lines of code (okay, okay, maybe a few dozen...), you can copy your hexadecimal in ONE place, and use a variable to propagate the change everywhere else. Do this with colors, fonts, styles, padding, anything you can think of to style.
      • Scripts
        JavaScript files live here.
      • SkinInfo
        This folder stores information about the specific skin in an Xml file that's used by your admin console. You'll find an image here, which can be used to store a screenshot of the custom skin that's later shown in the admin console on the Skin Selector page.
      • Topics
        Topics can be standalone pages - you can create them in your admin console under Content > Manage Topics, or you can store topic pages in this folder as .htm files. More info here:
      • Views
        Layouts for things like Checkout, Account, Minicart, Search...
      • XmlPackages
        Layouts for products, categories, manufacturers, departments, search results, email notifications...

  • Views (read only)
  • XMLPackages (read only)
    Views & XmlPackages are used to manage specific layouts for things like your checkout page, account page, or product & category pages. These folders are read-only - you can download files from here, but you can't upload files back to here! The files within these folders are updated automatically when we release our software updates each month, so we don't want you to customize these files, as they'll be overwritten and you'll lose your changes when we roll out our updates. You'll find copies of each of these folders within your Skins sub-folders, so you can use these read-only folders to download the 'base' versions of these layouts, then apply some changes, and upload them back up to the Skins/YourSkinFolder/Views or Skins/YourSkinFolder/XmlPackages directories. As long as you keep the filenames and the paths the same, any file that's stored in the Skin level Views or XmlPackages folders will take precedence over the same file that's in the 'root' Views & XmlPackage folders. If a layout exists in your Skin folder then that will always be used, and the root level file will be ignored. Keeping the filename and the paths are important - the store won't know to use your customized Skin level View unless it exists in the same location with the same name. If you want to copy and customize /Views/Checkout/Index.cshtml, you'd need to copy that to your skin at this path:  /Skins/YourSkinFolder/Views/Checkout/Index.cshtml.

Using less

Why would you use 'less'? You certainly don't have to. You can apply styles to your .css files directly as often and wherever you like! However...once you figure out less, you'll never, ever go back. You will have saved so many Ctrl+C + Ctrl+V keystrokes, you won't know what to do with yourself. To use less, you'll need to have Visual Studio, and a Web compiler extension (links at the bottom of this article).

How it works, in a nutshell: 
Rather than editing CSS files directly, you'll edit .less files instead. Your .less file will have variables that you'll edit and/or references to other .less files, so you'll make changes in one place rather than one-million places, then to propagate your changes you'll just compile the .less file(s) and your css files will be built by magic, basically.

There are some great tutorials on using less to get you started (links at the end of this article), and, I'm a fan of the break-it-until-it-works method of trying new things. If you started with one of our responsive templates from our Push Button portal, you'll find a 'less' folder in your skin - go have a look at it, download the files, set up a local development environment and start changing things. Don't do this on your live site - if you change up your less files on your live site via FTP directly, it simply won't work. The less magic all happens with Visual Studio + Web compiler.


Some things to look out for when you're customizing your design that have potential to cause you some grief:

  • Avoid over-customizing views
    Don't go changing root views, please stick to the views and xml in your skin folder...

    Here's the deal: Just because you can do something, doesn't mean it's always a good idea. I could eat a pint of ice cream for dinner every night this week, but future-me will live to regret it. I could take a copy of every view in the root, move it into my skin folder, and customize my layout beyond recognition, but next month when my store is auto-updated to the latest release, I won't get any of the new features or fixes - I might also find that some of the changes disable some of my older or customized code, and my store's functionality might be impaired.

    For best results, stick to applying changes to the files in your Views/XmlPackages folders that are already there. Those are the safest places to apply layout changes to your store. If you're using one of our always-up-to-date business solutions, as we update our software each month, we might include changes to Views & XmlPackages. If a software release includes changes to Views, we won't migrate those changes to your Skin folder(s), it will be up to you to merge those in. In some cases, we'll make an exception to merge a critical change in to your skin, but it will be carefully merged around your customizations if/when that's the case. For most changes to Views & XmlPackages that we roll out in our releases, we will update the files in the root Views & XmlPackage folders, and since you have access, you'll be able to read the release notes and work out which of those changes you might want (or need) to bring in to your Skin level Views / XmlPackages.

  • Avoid changing CSS files associated with 'base'
    Within your skin, you'll find a Css folder that will have a half dozen or so .css files in it. If you're not using less, you'll probably be tempted to go adding/changing styles in files like base.css. Base.css will contain styles associated with the default storefront functionality - things like the width of forms, the overall page layouts, font sizes - all the 'defaults' are in here. You can change the styles in this file, but you shouldn't. In the world of monthly software updates, you'll want an easy way to merge in our new software changes with your own. If you go editing the 'base' css files, you'll give future-you a difficult time keeping up to date. Instead, copy the name of the selector you want to change in to 'custom.css', and make your changes there. Bundle your custom.css file last in the list (css bundling happens in Skins/YourSkinFolder/Views/Shared/_Head.cshtml).

  • Backup & Version
    Backup frequently - never overwrite a file on your live site until you've first taken a backup - just in case. Err on the side of caution - your code is probably flawless and will probably work exactly the way you expect it to, but it pays to keep a backup just in case you need to roll back.

    I'm also a big fan of versioning - we use tools like SVN and Git for source control. For skinning, it's helpful to use something like SVN because it gives you a way to track your changes over time. You can apply some style changes to make your whole site blue, and commit it to SVN. Then later, someone will say 'make it pink now, pink is the new blue', so you'll change everything, and commit again. But one day, blue will come back in to style, and you don't want to have to rework all the work you've already done, you can just pull out your historical changes and now you're back in fashion. I'm oversimplifying the benefits of versioning but you get the idea.


The list below contains some of my favorite tools & reference sites for skinning.