Dev Series: Kick-Ass Magento 1 Frontend Workflow

In my time as a frontend developer, I have used a great many different tools for the job, starting off with simple text editors like Notepad or vim, to larger commercial tools such as Dreamweaver. They provided me with what I needed at the time, but now the web is getting bigger by the minute and demands for more efficient development are high. Only in the last 12 months though have I really focused on how I can make my job easier. By easier, I mean quicker to start a site off on the ground and push on with developing using Magento 1.

There are several tools that I use on a daily basis both actively and in the background of my development routine.

Editors

PHPStorm
This is my daily driver. JetBrain’s IDE is everything a PHP dev could ask for and more, plus if you plug in Magicento then you have a very capable Magento development environment. There are also plugins to help with frontend stuff that will watch files for changes and perform actions. Although they’re there, I don’t actually use them – favouring a separate task runner to sit in the background and work it’s magic. That being said, if you favour the cleaner desktop with minimal applications running (unlike me!) there is a built in terminal so you play the command line game from inside your IDE.

Brackets
This editor from Adobe is really lightweight. This means it’s perfect for single file editing (files that aren’t part of larger projects) or small projects (such as small landing sites).

Version Control

Our version control system of choice is Git. We use Github for the main repositories to manage the hefty code base for Magento, but you can host Git yourself via GitLab or similar tools.

For those who don’t know, Git allows developers to write code and manage it in a sane way. If you have multiple developers working on the same site, there is a good chance that someone is going to step on another’s toes. Git takes this aspect out and allows people to use branches for different features or amendments. These are basically snapshots of the codebase at certain points which can be merged back into the master branch when they’ve been finished and tested. It can also be completely removed.

One of the biggest hurdles I found with Git is remembering all the command line tools, so thankfully I have Tower to provide a nice GUI for Git.

Preprocessors

Sass has been around for a while now. It is a way of writing CSS in, in my opinion, a much more structured manner. According to http://sass-lang.com, it is CSS with superpowers. Sass makes it fun to write manageable style code, including such features as nesting, mixins, variables and even control directives (@ifAi??, @forAi??, @eachAi?? and @whileAi??) to allow for a more flexible way of writing styles.
I write in to scss (closer to proper css) rather than sass format, but that doesn’t stop the output being the same – it just feels more comfortable to write that way as it’s where I’ve come from.

You can even use coding methodologies such as BEM as discussed in a previous article.

I write style code as blocks, then @importAi?? them in to a main styles.scss file which gets compiled in to one styles.css file via my task runner. I even have it compiling and minifying as part of the background task!

Recently I’ve employed PostCSS for autoprefixing, handling CSS minification and a few other tasks – but that’s an article for another day.

Task Runners

My task runner is the centrepiece of my workflow, with all my directories and files being watched for save triggers that will automatically run different tasks. I have tried Grunt as a task runner, but settled on Gulp. I find it quicker to setup and slightly fast in executing tasks. I have actually semi-released my gulpfile.js in to a publicly visible Github repo.

I have several tasks setup to watch and perform various actions on:
Styles (compiling my scss to css in new directory, including minification, optimisation of code and removal of comments),
Images (optimisation and moving images to a new directory),
SVGs (stripping different attributes from the SVG markup depending on the filename and compiling them in to a single spritesheet),
Scripts (minification, uglification and moving to a new directory)

Why move them to a new directory?

Because this:

Is MUCH nicer to have a production server than:

Moving the processed files to another directory means there are fewer files that need to be deployed to the server. There is no need to have raw scss files or node_modules/Ai?? on staging servers. As a matter of fact, /node_modules and /bower_components do not go in to the repository at all because it takes no time at all to bring them down via two commands.

One of the issues I had to get around using the other directory is Magento’s default way of handling themes. The way Magento wants to do things is to have a styles.css in the /skin/frontend/package/themeAi?? directory.

I needed to have Magento look in /skin/frontend/package/theme/dist/css/Ai?? for the styles.css.

I got around this with a small piece of XML in local.xml:

<?xml version="1.0" encoding="UTF-8"?>
<layout>
  <default>
    <reference name="head">
      <action method="removeItem">
        <type>skin_css</type>
        <name>css/styles.css</name>
      </action>
      <action method="addCss">
        <stylesheet>dist/css/styles.css</stylesheet>
      </action>
    </reference>
  </default>
</layout>

The above removes the default styles.css file from the head region, and adds in my shiny compiled one.

Package Management

Bower
Bower is a tool for managing frontend dependencies such as libraries and frameworks. With Bower, I can keep a list of the assets I use commonly whilst making a Magento theme. Currently, common assets I have logged in my bower.json file are:

• Susy
• Breakpoint
• Normalize.css

You can include libraries such as jQuery, however I haven’t had a need to provision these because a backend dev has so far had the project before I get hold of it, but that would be easy to do in Bower and you could use your task runner to copy the minified production files (such as jquery.1.12.0.min.js) from bower_components/jquery/Ai?? to vendor/js/jquery/Ai??.

Javascript Libraries

jQuery
There are a number of libraries I use, but the main one for manipulating the DOM (Document Object Model) that I use on a daily basis is jQuery. Mainly because it’s – in my opinion – much nicer to work with than Prototype that Magento 1.x ships with. Another reason is that most other of my commonly used vendor javascript scripts are usually jQuery based.

Resources

JetBrains PHPStorm – https://www.jetbrains.com/phpstorm/
Adobe Brackets – http://brackets.io/
Git – http://rogerdudler.github.io/git-guide/
Sass – http://sass-lang.com/
Gulp – http://gulpjs.com/
Bower – http://bower.io/
Susy – http://susy.oddbird.net/
Breakpoint – http://breakpoint-sass.com/
Normalize.css – https://necolas.github.io/normalize.css/
jQuery – https://jquery.com/
Magento – https://magento.com/
Npm – Modules for Gulp – https://www.npmjs.com/
Using SVGs – https://css-tricks.com/using-svg/
Our Gulp Boilerplate – https://github.com/PinpointDesigns/GulpBoilerplate