Drupal and Front-End Web Developer

Going back to Drupal

Monday, June 25th, 2012

For a couple years I had a one-pager site that just had portfolio stuff on it. It was minimal, it did what I was after, it totally tanked my SEO rankings. Then about a year ago I decided that I wanted a space to be able to write some things (all techy junk, but stuff here and there) but I didn't want to deal with a full revamp of my site, so I found Toto and used that. That all worked fine for a while, and appealed to me in the "Small Pieces Loosely Joined" kind of sense, but I reached a point where I decided it was time to just merge it all back into a proper Drupal build. 

Why would I change my mind on something like that? Essentially in the process of trying to have a (that's "a" as in "one singular") presence on the web I was having to manage three separate sets of code in varying environments and with different tools. 

  • A static HTML site with a bunch of custom JavaScript for running an Ajax slideshow component.
  • A Drupal 6 instance that existed solely to provide and slice data for that slideshow. 
  • A Toto instance for managing my writing and nothing else. 

(Okay, and a Tumblr for doing Tumblr things, but that's sort of specific and self-contained anyway.)

So, in short, why go back to Drupal? Simplification (in the long run) through complication (in the short term). Moving back to Drupal got all the things I wanted to be publishing back into a single interface. I've seen plenty of projects in the past that wound up being pushed into a number of shared systems side-by-side and I'll never recommend it as a viable approach again. Doing this also gave me the basis for improving on some things I just hadn't been willing to put my free time into (a rare and precious commodity). 

I started my career in the front-end. I like front-end. I enjoy creative front-end problem solving tasks. With that said: Creating a new column layout is not a new and creative front-end problem to try to solve. It's been solved, many times over and by many people. Taking a prefab solution for that will just make your (front-end) life easier (as long as it's one that will do what you need it to). To that end: Omega. Part of me wants to be really precious about every line of markup that gets spit out by my site, another part wants ease of use and not to have to write a bunch of custom logic again for myself. Omega treads that line to my satisfaction. On one hand it's not MY markup, but when you get down to it, a lot of the patterns it uses are the same as what I would write. Heck, even a lot of the naming patterns are pretty close to what I would write. So it's a lot easier for me to say "I'll use this and accept that things like responsive layouts come with it for free" than to try to start from scratch. In this case, anyway. I know there are and will be lots of good arguments for doing so in the future, but for now and for here, this is just peachy. 

Going back to Drupal also meant I could do something more dynamic as a whole. I would have had to create a lot of code on my static site to be cross-wiring portfolio items and writing and all that sort of stuff. Here it's all just Views. (And don't we all love Views?)

So, what's under the hood?

The new site is all Drupal 7. There's really not that much of note in terms of modules or thigns of that nature. I used Admin and Admin Tools to make administration stuff a bit less intrusive. There's plenty of Beans, Boxes, Context and some little Context extenders here and there. And while it's not really of note in terms of overall site build-out, I will say: I love Module Filter.

Theme wise, I've just got an Omega subtheme. I added a couple files to customize bits here and there (a couple field templates, some extra stuff in the html.tpl.php), but short of the CSS that gets applied, it's pretty standard. 

Hosting-wise I'm running on Pantheon. Before (and actually, presently) I had an "all you can host" shared hosting account with Dreamhost which was good for static stuff but their shared hosting configurations are notoriously slow for Drupal. So yeah, getting the option for a single integrated Git repo, dev/test/live environments and tools for development workflows for about the same I was paying for shared hosting anyway? I'm in.

Anyway, look around and stuff. Or don't. 

Need a developer?

Good news, I'm available! You can try taking a look at my resume to get a feel for the kinds of things I know how to do.

I'm reading...

Listening to...

Individual Member of the Drupal Association