TUTORIAL: Using Sass and Compass for managing CSS in WordPress

I don’t often write tutorials but since the rebuild of the WP Engine website some months ago, I have been turned on to the use of a brilliant combination of tools made for development in a Ruby on Rails environment. That doesn’t mean we can’t make it work for WordPress too.

The tools are Compass combined with Sass (which means Sytactically Awesome Stylesheets or some random crap like that).

Sass is cool because it lets you do a whole bunch of stuff with CSS that you couldn’t normally. It’s a kind of abstraction layer above CSS which means you can write normal CSS if you want, but then why wouldn’t you just write normal CSS instead of using Sass?

I’m getting slightly ahead of myself, but With Sass you can do awesome things like variable/placeholders which is awesome for things like defining core elements of a stylesheet such as a palette of colors.

1
2
3
4
$cloud-blue: #d9e7f3;
$light-blue: #f0f7fc;
$dark-blue: #036;
$green: #7ca60a;

Then using those variables, you can just use these placeholders in your SCSS (Sassy CSS) file:

1
2
a { color: $dark-blue; }
a:hover { color: $light-blue; }

You can also write Mixins. Mixins are essentially reusable blocks of CSS that look a lot like functions you would see in languages like JavaScript, PHP or Ruby:

1
2
3
4
5
6
7
8
$radius:5px;

@mixin border-radius($radius)
{
border-radius:$radius;
-moz-border-radius: $radius;
-webkit-border-radius: $radius;
}

You can use that in your SCSS file as such:

1
form input { @include border-radius(5px); }

But again, I’m getting ahead of myself.

When I talked about using Sass and Compass on Twitter, other WordPress devs made comments that made me want to write this tutorial. One person said that they were tired of Rails developers having all the toys – and it’s true. There are so many awesome things out there for Rails developers that we as PHP and WordPress developers don’t benefit from. This tutorial is non-exhaustive. There are tons of things that you can do with this that I won’t cover. But this should get you going with Mac OS X Lion, developing WordPress locally on your own machine and uploading to a theme file called “test” on a remote server.

Prerequisites

First of all, you need to have a local version of WordPress running. There are a variety of ways to do this, but I use the approach of installing XAMPP. Here’s a tutorial on that. Follow the rabbit trail to configure Apache to look to your Sites directory, as I have, or make that translation in your head to what the default is. There’s plenty of instruction on how to do that on the internet.

For the specifics of this tutorial, it’s very important that you have the latest version of Ruby. The best way to do this is with a tool called rvm, or Ruby Version Manager. Install this with the following Terminal command:

1
bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

Once rvm is installed, use it to install 1.9.3-p0, the only current version compatible with OS X Lion, and refresh your Terminal profile settings. The last command sets 1.9.3-p0 (or whatever future version you choose to use) as your default.

1
2
3
4
rvm install 1.9.3-p0
rvm reload
source ~/.bash_profile
rvm --default use 1.9.3-p0

If you wish to verify that you’ve got the proper version of Ruby active, verify it with the ruby -v command.

My system reported:

1
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]

Now, there are some gems that need to be installed. For developers unfamiliar with Ruby – or Rails – gems, are essentially additional libraries that are installed into the Ruby framework, much like PHP PEAR or PECL modules.

The first is Builder, which is used for building XML structures. The second one is Compass which will give us the ability to leverage Sass for CSS authoring.

1
2
gem install builder
gem install compass

Creating a Sass Project

Once we have everything installed properly, we can start a new project. I keep this out of my web directory (i.e. WordPress structure). Personally, I’ve created a sass directory under my user profile (/Users/aaron/sass) and run my projects out of it with a separate directory for each project.

Now we have to create our compass project. We do that with compass create from our ~/sass directory and then moving into the newly created directory.

1
2
compass create test
cd test

Doing a directory listing should show something along these lines:

1
2
3
4
5
6
7
8
NCC-1701:test aaron$ ls -la
total 8
drwxr-xr-x 6 aaron staff 204 Nov 2 11:36 .
drwxr-xr-x 4 aaron staff 136 Nov 2 11:36 ..
drwxr-xr-x 5 aaron staff 170 Nov 2 11:36 .sass-cache
-rw-r--r-- 1 aaron staff 861 Nov 2 11:36 config.rb
drwxr-xr-x 5 aaron staff 170 Nov 2 11:36 sass
drwxr-xr-x 5 aaron staff 170 Nov 2 11:36 stylesheets

Good. Our project is created but we need to make some changes to make this work with WordPress. To do this, we need to edit the config.rb file which is the project configuration file. You can edit this file in Textmate, vi, or whatever you choose as your preferred text editor.

The default configuration is:

1
2
3
4
5
http_path = "/"
css_dir = "stylesheets"
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "javascripts"

My config file looks like this:

1
2
3
4
5
6
7
8
http_path = "../../Sites"
css_dir = "../../Sites/wp-content/themes/test/css"
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "js"
project_type = :stand_alone
output_style = :nested
line_comments = false

Important changes here:

  • The http_path is a relative path to my DOCROOT – for some reason, things got whacked when using an absolute path.
  • The css_dir is a relative path to the css directory in my WordPress theme directory. At this time, there is no configuration option to control the name of the CSS files being generated so we will have to use @import inside the required WordPress style.css template file to incorporate Compass generated CSS files.
  • You can change the images_dir and javascripts_dir as needed to reflect your taste. Personally, I prefer shorter names, so that is reflected in the config file.
  • The project_type flag is required because, if omitted, Compass assumes we are working in a Rails environment on a Rails project with Rails conventions… WordPress is none of that.
  • The output_style flag has been set to :nested but could be :expanded, :compact or :compressed depending on your tastes.
  • The line_comments flag has been set to false to remove debug information from the generated CSS

All configuration options can be referenced in the Compass docs.

Having modified the config file, we can take one of two approaches to generating the CSS in our WordPress theme. We can use the compass compile which will generate the files one time. Everytime modifications are made, however, this command would have to be re-run. I prefer, instead, to use compass watch which is a small process that remains running and watches your Sass project for changes and recompiles automatically when changes are made.

Simply run this command from inside the Sass project:

1
2
3
4
5
6
7
8
9
compass watch
>>> Change detected to: ie.scss
create ../../Sites/wp-content/themes/test/ie.css
create ../../Sites/wp-content/themes/test/print.css
create ../../Sites/wp-content/themes/test/screen.css
/Users/aaron/.rvm/gems/ruby-1.9.3-p0/gems/fssm-0.2.7/lib/fssm/support.rb:40: Use RbConfig instead of obsolete and deprecated Config.
FSSM -> An optimized backend is available for this platform!
FSSM -> gem install rb-fsevent
>>> Compass is polling for changes. Press Ctrl-C to Stop.

At this point, if you want to develop locally, all you have to do is have your WordPress style.css import these stylesheets.

1
2
3
4
5
6
7
8
9
10
11
/*
Theme Name: Test Theme
Author: Aaron Brazell
Author URI: http://emmense.com
Description: A test theme demonstrating Sass and Compass
Version: 1.0
*/


@import url('css/screen.css');
@import url('css/print.css');
@import url('css/ie.css');

Uploading to a Remote WordPress Install

Fortunately, with a little Ruby magic and some built in Compass hooks, we can also upload these newly created CSS files to our WordPress theme. In order to do this, you have to make sure the remote server has the theme directory created and if you are uploading to a subdirectory of that theme (e.g. theme_dir/css), that that directory is created as well.

In our case, the theme directory is test/ and I want to upload to a subdirectory test/css/.

Next we have to install two new gems – the Net::SSH and Net::SFTP gems. Installing these is as straightforward as the earlier gems:

1
2
gem install net-ssh
gem install net-sftp

Once this has done, include these in your config.rb file. I did this at the top which is best practice with Ruby.

1
2
require 'net/ssh'
require 'net/sftp'

Below all the previous configurations, add some configuration lines and replace values as needed for your own project:

1
2
3
4
5
6
7
8
# note that this is the directory that CSS files will be written. It can be the theme dir
# or a subdirectory (e.g. theme_dir/css). Whatever this path is MUST exist
remote_theme_dir_absolute = '/home/sites/emmense.com/httpdocs/wp-content/themes/test/css'

# SFTP Connection Details - Does not support alternate ports os SSHKeys, but could with mods
sftp_host = 'hostname.com' # Can be an IP
sftp_user = 'username' # SFTP Username
sftp_pass = 'password' # SFTP Password

Finally, we can leverage Compass’ built-in on_stylesheet_saved hook to upload to the remote server using your SFTP credentials:

1
2
3
4
5
6
7
8
9
# Callback to be used when a file change is written. This will upload to a remote WP install
on_stylesheet_saved do |filename|
  $local_path_to_css_file = css_dir + '/' + File.basename(filename)

  Net::SFTP.start( sftp_host, sftp_user, :password =&gt; sftp_pass ) do |sftp|
    puts sftp.upload! $local_path_to_css_file, remote_theme_dir_absolute + File.basename(filename)
    end
  puts ">>> Compass is polling for changes. Press Ctrl-C to Stop"
end

Restart Compass, save one of your Sass .scss files with a change of some sort (from where CSS will be compiled), and watch your files be saved locally and remotely.

At this point, my full config.rb file looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Require any additional compass plugins here.
require 'net/ssh'
require 'net/sftp'

# Set this to the root of your project when deployed:
http_path = "../../Sites"
css_dir = "../../Sites/wp-content/themes/test/css"
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "javascripts"

project_type = :stand_alone
output_style = :nested
line_comments = false

# note that this is the directory that CSS files will be written. It can be the theme dir
# or a subdirectory (e.g. theme_dir/css). Whatever this path is MUST exist
remote_theme_dir_absolute = '/home/sites/emmense.com/httpdocs/wp-content/themes/test/css'

# SFTP Connection Details - Does not support alternate ports os SSHKeys, but could with mods
sftp_host = 'hostname.com' # Can be an IP
sftp_user = 'username' # SFTP Username
sftp_pass = 'password' # SFTP Password

# Callback to be used when a file change is written. This will upload to a remote WP install
on_stylesheet_saved do |filename|
  $local_path_to_css_file = css_dir + '/' + File.basename(filename)

  Net::SFTP.start( sftp_host, sftp_user, :password =&gt; sftp_pass ) do |sftp|
    puts sftp.upload! $local_path_to_css_file, remote_theme_dir_absolute + File.basename(filename)
    end
  puts ">>>> Compass is polling for changes. Press Ctrl-C to Stop"
end

Conclusion

Rails developers have all the fun. It’s true. But with Compass, Sass and a little bit of Ruby, PHP developers (including WordPress theme developers) have a great tool that will make workflows more efficient, CSS more readable and structured and central management more coherent.

Obviously, I did not get too far into the details of using Compass and Sass. That’s a whole tutorial to itself. For information on that, I’d recommend checking out these fine articles written on the topic:

(Protip: I love being able to nest CSS… try it)

Disclaimer: I am a PHP developer, not a Ruby developer. My Ruby code could probably be improved upon by someone who is more in tune with the Ruby language.

Changing Roles at WP Engine

For some time, I’ve felt there was a change coming and today, I’m ready to announce that my role within WP Engine is changing. Starting today, I have transitioned into an advisory and consulting role with the company.

Effective immediately, I will be taking the portion of the business that focused on professional services and consulting to allow the company to focus on premiere WordPress hosting. It’s a good thing and I’m excited about the possibilities. Back in November, we decided to start taking on some professional services work to augment demands from many of our customers. It was awesome to have fast, secure, scaleable, managed hosting but they wanted more!

And we wanted more.

However, as the company has evolved, taken funding, hired more people, addressed growth challenges and built out our hosting option, it seemed clear that the professional services portion of the company was a separate kind of deal than what we wanted to focus on.

So today, I’ll be taking that portion of the company (and all related existing and current relationships, as agreed on), and working on that. Meanwhile, I’ll still be working with the company to guide direction and strategy. So it’s good for everyone.

Effective immediately, I am available for all WordPress consulting roles. However, I am also currently entertaining all possibilities involving full time employment as well, and welcome those conversations.

To contact me, please direct emails to aaron@technosailor.com. As transitions go, the immediate financial impact is something that I need to consider.

How is WordPress Subversion Organized


There’s some confusion about how WordPress organizes it’s Subversion (SVN) repository. Most SVN repositories are organized into three main directories, as is best practice — trunk, tags, branches.

The repository can be found at http://core.svn.wordpress.org/ and a primer on how to use SVN for WordPress development can be found on Mark’s blog and, for Windows, on Westi’s blog.

Though there are varying schools of thought as to how branches and tags work, WordPress follows the following system:

/trunk is where future release development occurs. Right now, WordPress development is focused on an upcoming 3.3 release. All development for this release is going into /trunk.

/branches is where 3.3 will go once it is released (or where future “branches” of the software will be housed down the road. The directory contains a series of directories that are branches from the current release development — for example, /branches/3.0, /branches/3.1, /branches/3.2, etc. What you won’t find in branches are security (or dot) releases.

For instance, when a security vulnerability is discovered, it will be patched in /trunk for the current development branch and may be backported to the previous release branch (currently, 3.2). But until the next security release of WordPress comes out for that branch, it is still considered “development” and not “stable”.

/tags is where stable releases are archived. No development goes into tagged releases. These are final releases. You will find every release here in the form of /tags/3.2.1, /tags/3.2, /tags/3.1.4, etc. If you’re looking for the latest current stable for production, this is the place to look.

When branches achieve the next milestone (i.e. a maintenance or security or “dot” release), this is the place where the code is kept.

Hopefully this makes the WordPress repository (and maybe other projects) clear as mud.

Rules for Entrepreneurs: Release Early and Often

Last week, I wrote two articles outlining some philosophical ideas around entrepreneurship. This series of articles is all about giving away lessons I’ve learned throughout my five years as an entrepreneur in four different ventures.

When you’re in the product business, you have to continually improve on your product. As soon as you hit version 1, you’re heading for version 2. You create a roadmap and set milestones, which are just intermediary goals to help you get from inception to some point in the future.

The reality of roadmaps, however, are that they are susceptible to change based on market demands – or, as it’s sometimes called, “pivots”. You can have a great product idea that has a wonderful two year roadmap, but if customers don’t like it or demand other features that have never been thought of, then it would be wise to modify timelines and roadmaps.

Many successful products have been the product of a “release early and release often” mentality where the entrepreneur or product team did not wait to have a fully developed product, and instead, hurried to get something to market for the sake of collecting feedback and input and improving on the product.

Eric Ries in Lean Startup talks about principles of testing market validation by creating an iterative cycle of development where a product is released, tested in the market, feedback aggregated, assumptions tested against that feedback, and new innovation created as a result of those tests.

There are a number of rapid-cycle development philosophies including Agile, Scrum and others. These philosophies put a greater emphasis on involving customer feedback and direction over pre-determined plans where feedback is not collected until the development cycle is completed.

What happens if your assumptions were all wrong? Now you’ve got a product that no one wants to use!

The best way to avoid this problem is simply to release early, even before your product is near complete, and collect feedback along the way. Based on the feedback, you may need to modify your development trajectory but at least you’re able to do that before it’s too late and keep your product relevant to the consumer.

Next time, I’ll continue this series and talk a bit about business visualization to help you track your business and make effective decisions. If you’re not already subscribed to this blog, do so now. Also, follow me on Twitter where I’ll be talking about entrepreneurship, WordPress and a healthy dose of sports on the weekend.

Rules for Entrepreneurs: Compete and Collaborate

Photo by Roger Barker on Flickr.

Google and Apple are not only competitors… they are collaborators. Indeed, Apple and Google both offer top level smartphones – The iPhone from Apple and the assortment of Android devices by Google (Google not only has its own phones but is the main proprietor of the Android open source project).

In the same world, Samsung and Apple are rivals (and becoming even more rival-ous) with competing smartphones (Samsung runs Android) sparking ferocious lawsuits back and forth, but Samsung is also a major supplier of parts to Apple.

This segment of my continuing series on Rules of Entrepreneurship is all about knowing when and how to compete and when collaboration is a better option. They are not mutually exclusive. This is a natural segue from my last post where I suggest that entrepreneurs focus on doing one thing well.

Principle: Don’t Reinvent the Wheel

It frustrates me to watch startups (usually not very good ones) try to reinvent the wheel. A classic example of this was from back in 2007 when I was sitting in a Starbucks in Columbia, MD. We had a group of entrepreneurs who gathered there on a daily basis and cowork together.

One of the guys I was working with introduced me to a pair of African-American entrepreneurs and he wanted me to hear about what they were building. I sat down and listened to their pitch. They were building the “YouTube for the African-American community”.

Full stop.

What? Why? Why not use YouTube?

They were well into the process of building an entire video platform from the ground up, complete with their own video encoding technology, instead of leveraging what YouTube (and subsequently Google) already created.

The entrepreneurs real mission was creating a video-sharing community for African-Americans, not creating video technology for African-Americans to use. I told them that day that they should abandon attempts to build their own video service, and instead leverage YouTube (which is built and maintained by really smart people at Google) to build the community they really wanted to build.

Why re-invent the wheel? You distract yourself from your core goals.

Sidenote: I have never heard of or from those entrepreneurs since.

Collaborate

As an entrepreneur, part of the process is identifying your competition. We certainly have done that at WP Engine. Sometimes, it is to your benefit to team up with your competition to achieve a common goal. Remember, business is business and it’s not personal. Don’t let your desire to “win” get in the way of your ability to get ahead.

Also, remember the age-old saying, “A rising tide lifts all ships”. What is good for your competition is often good for the entire industry you’re in. Everyone wins.

Certainly that’s not always the case, but it certainly isn’t not always the case.

Compete

In my opinion, competition is a bottom-line issue and there are lots of ways to positively affect your bottom line. Usually, competition does not equate to a zero-sum game, an assumption that rookie entrepreneurs tend to make. (I did this a lot in 2006, 2007 while at b5media and trying to take pot shots at competing blog networks – years later, I find it all kind of silly).

When you do choose to take on direct competition, keep it narrow, precise and for a specific purpose. Don’t allow personal feelings to affect your business strategies and, in the process, keep the door open to cooperation with your competition in other areas.

Next week, I’ll continue this series and talk a bit about release cycles – which is always a fun debate. If you’re not already subscribed to this blog, do so now. Also, follow me on Twitter where I’ll be talking about entrepreneurship, WordPress and a healthy dose of sports on the weekend.