New iCaspar Theme

A couple weeks ago at WordCamp NYC I heard that the Underscores ('_s') starter theme was going to start using SASS for it’s CSS.

Fantastic! That was just the kick in the butt I needed to do a WordPress theme using SASS.

It was also the kick I needed to redo the theme for iCaspar.

So here it is!

A few notes:

  1. The new iCaspar theme is extremely simple. “Ultra Minimalist,” you might say. There are no options to fiddle with. There are no fancy-pants images. There is just one column that focuses on written content. All the widgets are at the bottom. It’s for reading without distraction. It’s a Zen thing.
  2. With SASS in charge, all the theme CSS is compiled into a single compressed file. (If you actually bother to look, you’ll find a few other CSS files are loaded, but those are all from plugins.) It’s a Zen thing.
  3. Fonts are from Google fonts. Headers are Raleway. Content text is Lusitana. Just two fonts. It’s a Zen thing.

I’m calling it version 0.1 — clearly not a finished product yet, except for use on this site.

As soon as it’s a little more ready, I’ll share the code on Bitbucket.

Bloat Is Easy. Clean Is Harder (and maybe worth it).

For the last week or so, I’ve been checking out WordPress starter themes. By starter, I mean starter. As in, down to bare bones. The starters I’ve been working with are Toolbox and Underscores.

Both of these starter themes come from people at Automattic (the WordPress parent organization), so they both provide a solid foundation for theme build-outs. The major difference between them is that Toolbox assumes you’re going to build a child theme on top of it. Underscores, however, is right up front about saying, “Don’t build a child theme on this.”

Even Starter Themes Have Some Bloat

By far, the most surprising thing about both these starters is how much they give you to start with. They both come with quite a few functions already defined, and a surprising amount of CSS. You’d never suspect it, given the spartan look of them out of the box.

It’s an eye-opener to see what the Automattic theme folks consider essential to include. Theme support for post types and backgrounds, head links and body classes for various feed types, CSS for screen readers, right-to-left language support. It’s all there.

WordPress Has Even More Bloat

As I was working on these, though, what began to bother me was the amount of extra stuff WordPress itself inserts into each page. Stuff that might or might not be useful, depending on what the site is about. Once you start adding plug-ins, things really start to expand rapidly. It’s like the big bang happening in your browser.

I started finding myself slightly obsessed with figuring out where all this stuff was coming from and seeing if I could get rid of it. If you firebug this page, you’ll see a huge load of crap in the <head> section of the HTML. Take a look at all this:

    <meta charset="UTF-8"/>
    <link rel="pingback" href=""/>
    <meta name="author" content="Caspar"/>
    <meta name="description" content="Caspar Green. Thoughts on technology, theology, faith and church in the 21st century."/>
    <meta name="keywords" content="Caspar,Caspar Green,theology,technology,faith,church"/>
    <link rel="shortcut icon" href=""/>
    <link rel="alternate" type="application/rss+xml" title="iCaspar » Feed" href=""/>
    <link rel="alternate" type="application/rss+xml" title="iCaspar » Comments Feed" href=""/>
    <link rel="stylesheet" id="admin-bar-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="wordpress-popular-posts-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="jetpack-widgets-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="suffusion-theme-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="suffusion-theme-skin-1-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="suffusion-child-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="suffusion-rounded-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="suffusion-generated-css" href="" type="text/css" media="all"/>
    <link rel="stylesheet" id="suffusion-included-1-css" href="|Lusitana:400,700" type="text/css" media="all"/>
    <link rel="stylesheet" id="sharedaddy-css" href="" type="text/css" media="all"/>
    <script type="text/javascript" src=""/>
    <script type="text/javascript" src=""/>
    <script type="text/javascript">
    <script type="text/javascript" src=""/>
    <link rel="EditURI" type="application/rsd+xml" title="RSD" href=""/>
    <link rel="wlwmanifest" type="application/wlwmanifest+xml" href=""/>
    <link rel="shortlink" href=""/>
    <meta property="og:type" content="blog"/>
    <meta property="og:title" content="iCaspar"/>
    <meta property="og:description" content="To Code Is Divine"/>
    <meta property="og:url" content=""/>
    <meta property="og:site_name" content="iCaspar"/>
    <meta name="twitter:site" content="@jetpack"/>
    <style type="text/css" media="print">
    <style type="text/css" media="screen">
    <style type="text/css">
    <style type="text/css">
    <script type="text/javascript">
    <style type="text/css"/>
    <link rel="stylesheet" type="text/css" id="gravatar-card-css" href=""/>
    <link rel="stylesheet" type="text/css" id="gravatar-card-services-css" href=""/>

After a while tinkering around, starting from underscore and with the help of Darren Miller’s ThemeWrangler class, I got the installation on my development server down to just this:

    <meta charset="UTF-8">
    <meta content="width=device-width, initial-scale=1" name="viewport">
    <title>iCaspar Web Development | Custom Web Development</title>
    <link id="rule-them-all-css" media="all" type="text/css" href="" rel="stylesheet">
    <link id="right-sidebar-layout-css" media="all" type="text/css" href=" ver=3.7.1" rel="stylesheet">
    <style id="custom-background-css" type="text/css">

To be fair, in a real-life installation, you’re probably going to need a few more things going on. And I’m also not showing you a few scripts that I moved into the footer on the development site (which is where most of the scripts really should go).

I’m not saying that all this stuff isn’t useful. If you want social media connections and you believe in OpenGraph as a SEO essential, you’ll need to bring some of them back in. If you want easy access to feeds of various sorts, you probably need to tell browsers where to find them. It’s just that a lot of it is there whether it’s actually being used for anything or not, and it gets loaded with every page. And, if you’re not careful which plug-ins you’ve installed, it can get plenty worse. I’ve seen sites that have jQuery getting loaded 4 or 5 times, all different versions.

For most people, it probably doesn’t make a bit of difference. Very few people see it, and even fewer care. Shoot, it doesn’t even make enough difference for me to clean it up on this site.

The point is if you’re going to bother starting from scratch, less is more, and it’s better to add judiciously than to just toss everything in willy-nilly. And, for the average person, if you’re still reading this, the moral of the story is: be careful what you plug in.

Goodbye MAMP: How I Built My Own AMP Stack

MAMP PRO LogoI’ll admit to being a little lazy. For a long time now I’ve been using MAMP as my local development stack. The advantage of MAMP is that it’s easy. Just download it, install it, and run it. A while back I bought the Pro Version, which has a couple extra bells and whistles, (the added convenience of having everything in one place and easy-peasy set-up of multiple virtual hosts for several projects simultaneously) but for the most part is exactly the same as the free version.

Password Required

The downside of MAMP, even MAMP Pro, is that you always have to enter your user password to start, stop, or restart Apache. It’s been an issue with MAMP for a while. Lots of people have written about it. Many have raised the issue with the MAMP developers but there’s still no resolution, and the MAMP people are notoriously bad at responding to any support issues, not even for their paying MAMP Pro customers. Last year Larry Ullman wrote about why he’s leaving MAMP behind. Nothing’s changed since then. I’ve tried various suggestions for fixing (notably the Josh Frasier’s AppleScript solution, and the corresponding app based on Josh’s solution by Damien Goweda). But, for whatever reason, the AppleScript solution just didn’t work for me.

Ampps LogoThe Ampps Alternative

The first alternative I tried was Ampps. Larry Ullman’s article had mentioned it and I thought, if it was worth his time to mention, it would be worth my time to look at. I downloaded and installed it, but it wasn’t working. As it happened, I had just upgraded OS to Mavericks (OS X 10.9). Maybe that had something to do with it, I thought. The Ampps documentation said, “If it doesn’t work, send us a support ticket.” So I did. Within 24 hours I had a response. Pretty amazing, considering Ampps is totally free. Way better than MAMP support. As it turned out a change in the new OS X 10.9 was causing my troubles. Within another 28 hours, they had released a patch. I was up and running. But the GUI launcher for Ampps also requires you to enter your password every time you want to start, stop or restart Apache. A little looking around on the Ampps support forums provided another AppleScript method of getting around that, and a promise that they’re working on fixing this in the next release. But, having been down the AppleScript path before, I didn’t want to mess with it. Maybe I’ll try it again after the next version is released.

If You Want Something Done Right…

So, all for the sake of being a lazy slob, I resolved that I’d just do what I’ve been putting off doing for years: I decided to just install my own stack.

On OS X, the Apache part is already there. But with the latest versions, it’s not accessible without a bit of tinkering. For the clearest instructions on activating Apache and getting your stack built, you can’t beat Neil Gee’s step-by-step guides. They worked well. Everything worked! The native apache doesn’t require a password: it just starts itself when you log in.

When You Can’t Leave Well Enough Alone

At that point I decided, since I was going all the way with this, I may as well upgrade php to 5.5.5 (OS X Mavericks ships with 5.4.17). I kept getting errors during the compile phase. (If you have a suggestion about what causes utf8_mime2text() has new signature, but U8T_CANONICAL is missing I’d love to know!)

Homebrew (which is otherwise awesome) kept on running into problems with previously existing perl installations. It’s a known issue, and I could have tracked it down and fixed it, but like I said, I’m a little lazy.

PHP Install’s Magic Bullet

So, I ended up using the one-line installation from the folks at LIIP. This truly is php on OS X’s magic bullet installer. Copy the one line command for whichever php version you’re looking for, paste it into your terminal, and voila! Perfect install in under 30 seconds. (The only thing you might want to do is to edit the /usr/local/php5/php.d/99-liip-developer.ini file to set date.timezone setting to your own timezone afterwards, so you’re not running on Swiss time. But then again, the Swiss have a reputation for accurate watches!)

(Note: After I got done with the LIIP install, I found Neil Gee’s one-line php upgrade. I’d bet that works, too, but I can’t say since I didn’t try it. Comment, anyone? Update: Turns out, Neil’s php update is the same as the LIIP update! Duh!)

Good Luck!

So now I have my own, homemade AMP stack. It wasn’t really the lazy person’s alternative, but it feels damn good to have done it. And, hey! I don’t have to enter my password to start Apache any more, and I can go back to being lazy.

May your adventures installing your own AMP stack be smooth sailing!