Code things (or: how I migrated from Jekyll to WordPress and all you got was the exact same* site)
(* Hopefully.)
Yes, it’s true! I wrote some code. I talked to the computer and it (mostly) listened.
Though I’m not a total no0b when it comes to programming and web development – I was writing angsty teenage HTML back when Angelfire was the absolute new hotness and I spent a significant amount of time last summer making LEDs dance – I’m certainly no pro, either, and it turns out that CSS had moved on quite a bit in the decade since I last seriously undertook a project of this scope. Creating my own site from scratch was a huge and probably foolhardy challenge to take on alongside trying to develop my first products and everything else that needs to get done to start a business, but – as I’ve mentioned before – I really, really like to know how shit works and know that I can Do It Myself. Plus, it was actually quite refreshing to have a different project to focus on when my brain got too tired or distracted or frustrated to focus on sewing samples or grading patterns or illustrating instructions.
While I’m certainly no expert, and none of the following should be construed as a “tutorial” or “professional advice”, here’s a brief (ETA: LMAO, not brief at all) rundown of how it went, along with some of the resources I used:
STEP NAUGHT – HAPHAZARDLY LEARN A BUNCH OF JAVASCRIPT IN ORDER TO AUTOMATICALLY DRAW VECTOR UNDERPANTS, FALL DOWN INFINITE NERD RABBITHOLE
I will write more about this saga someday because it deserves its own post, but let’s just say there’s a reason this post is in a category called underpants-dot-js. But anyway, I earned myself a lot of Code School (now Pluralsight) badges. My partner sent me a book about SVG for Valentine’s Day and I genuinely thought it was super romantic.
STEP ONE – MOCK UP
I am not generally a sketch-first kinda garment designer — especially when sewing for myself, the out-of-my-head design process usually starts on the pattern itself, for better or worse; however, I’m less comfortable eyeballing hex codes than sleeve lengths, so I thought a rough mockup would help me get a handle on the overall look I wanted for the site and how all the information would be structured. I used Graphic’s iOS app on my iPad Mini so I could pick away at it on the bus. (I happened to already be using Graphic for a lot of my pattern drafting since it was inexpensive and available for both mobile and desktop, though I’ve subsequently moved on to Adobe Illustrator on desktop for most of my drafting and digital illustration; I haven’t used Inkscape but I’ve heard it’s a good open source alternative vector drawing app. BUT I DIGRESS.) I drew a bunch of pink rectangles and chose some stand-in fonts, and when I felt like I had a reasonable idea of what I was going for, I dove into the code.
STEP TWO – BUILD A BASIC STATIC SITE
A static web page is basically just a document that stays the same no matter who’s looking at it, from where, or for how long. The document may include complex styling and images and even animations that make it look dynamic (in the aesthetic sense), but its content doesn’t respond to the viewer. What you see is always the same thing that’s written in my text editor. It’s kind of like a TV show: philosophy aside, the act of watching doesn’t affect what’s being broadcast.
This style of website can be simple to put together because it only needs some HTML and a browser to work – you don’t need to set up a database or specialized development environment, and you don’t even need to learn any other languages if you don’t care what it looks like (but CSS is rad and you probably want to use it). Because it doesn’t do anything, it’s also less vulnerable to security flaws and unexpected behaviour.
This is the step where I got the site looking the way I wanted, without worrying about the site doing anything much fancy. This step and many of the ones after it should really be called “Watch a lot of YouTube code-along tutorials while caffeinating”. In particular, Kevin Powell’s material was indispensable for inspiring the CSS-heavy early stages, and Traversy Media was a great help here and much later during the Jekyll-to-Wordpress overhaul.
STEP THREE – COMPLAIN ABOUT BOOTSTRAP TO ANYONE WHO WILL LISTEN
This step is certainly optional and comes down to personal taste, but I developed some strong opinions about frameworks and obfuscation along my journey. Props to the Bootstrap developers (hi Mark!) for giving a ton of people a leg up, and providing me with a responsive grid and some handy under-the-hood animations… but if I were to do it all again I’d save myself the frustration of not being able to identify which one of the billionty-seven classes was making my nav items the wrong colour and opacity. I’m also not super keen on class names that describe how things look instead of what they are, and for now my markup is riddled with ’em.
STEP FOUR – MAKE THINGS AUTOMATIC (BUT NOT YET AUTOMATTIC) WITH JEKYLL
A static page is cool and all but what if your site has multiple pages? And you want them to look mostly the same-ish? Like, say, a blog? You could do it by hand by copy-pasting the code for headers and footers and other shared content into multiple files, but lemme tell you: it gets out of hand pretty quickly. Every time you need to make a change, you have to change it the same way in every file.
This is where a static site generator like Jekyll comes in. It still produces a bunch of static pages in the end, but it helps you pull together content from multiple sources into one document instead of copy-pasting by hand. You break up the basic layout into chunks that become a template, name the files according to certain rules, and then you specify where in your various pages those chunks should be crammed in. More or less. Jekyll then listens to all your “put header here and content there!” instructions and spits out a “site” folder with complete HTML for each individual page of your site, which can then be published.
Jekyll did require a little more than a text editor with a blinking cursor to get started, though. I had to* run it from the command line, and it’s got its own development server to preview your work locally before putting it before the eyes of the world (though I think you can configure it to deploy straight to a live site if you like to live dangerously). As a result, using Jekyll has a decidedly more “programmery” vibe to it despite not actually requiring a whole lot more programming; I don’t mind this at all but it’s not a for everyone. The official documentation is definitely aimed primarily at people who spend all day writing Ruby and I found it horribly frustrating at pretty much every stage. I only really got it up and running by the grace of more YouTube.
Pros: write posts in Markdown (though it turns out that you can also do this in WordPress so <raspberry>); all the usual advantages of a static site.
Cons: documentation so unfriendly I almost threw my laptop into the ocean and quit the internet forever; pagination just… didn’t… work? Listen, much like the Bootstrap thing, I know a lot of folks who dig it, it just wasn’t a good fit for me.
* I could have used Jekyll via GitHub Pages, which, despite working there for four years, I never successfully implemented, mostly because I was so dismayed by the Jekyll docs.
STEP FIVE – REFRAIN FROM THROWING LAPTOP INTO OCEAN, GOOGLE HOW TO TRANSITION FROM JEKYLL TO WORDPRESS
Tania Rascia wrote a series of awesome tutorials (which are a few years old but were still applicable to my situation, for the most part), which I supplemented with more Traversy Media and the official documentation, the WordPress Codex. Turns out it was less “transition from Jekyll to WordPress” and more “develop a WordPress theme based on a static site design”, much like I did in Step Four — which is still fine, because Jekyll helpfully generates a whole bunch of files each containing their own static page, so it’s not like I had to go back and reverse-engineer everything I had just changed. In fact, a lot of the changes I had to make to set up a basic WordPress theme echoed what I had previously done for Jekyll, except using PHP instead of Liquid tags. Which, oh right…
STEP SIX – LEARN SOME PHP
More CodeSchool badges!
As you might have gathered by now, WordPress creates dynamic pages: instead of building static pages, it pulls information from a database to generate a site, and this requires a scripting language like PHP. (To continue our TV metaphor from earlier, if a static site is like a TV broadcast, then a dynamic site is maybe more like a console video game.) It also requires a bunch of extra stuff* to be housed on the server in addition to the HTML/CSS files for the pages of your site. As a one-click install or blog hosted on wordpress.com, it can be as easy as choosing a pre-installed theme, selecting some colours, and off you go without ever needing to worry about the underlying code… but if you are a weirdo like me and want to develop your own custom theme, you’re going to need to confront the question: what even is mySQL? Get very comfortable with question marks, in fact, because PHP seems pretty unsure of itself and uptalks like a pre-teen.
ANYWAY. WordPress is a bit deceptive, because despite having a pretty admin panel with a WYSIWYG vibe that lulls you into into thinking it’s even less programmery than the basic HTML static site, let alone the bleak Terminalscape of Jekyll, IT IS ALL A RUSE. If you’re developing a theme, not only do you need to program the junk that the public will see, you also have to write code to make the admin panel do anything useful. Pretty comes through a lot of effort, and don’t you forget it.
* This is the part where you should definitely go consult an expert if you want to know more because, I mean, this blog is ostensibly about sewing, for one thing; also this post is already very long and I barely know how to describe the outlines of this. Rubber-ducking my woes at home has involved a lot of hand gestures and the thing is not doing the thing because I put the other thing in the wrong place.
STEP SEVEN – IT’S ALIIIIIIIIIIIVE
Which brings us to today, when I realized that I finally had no excuses left not to actually put all this crap on my live server. I exported the database! I SFTP’d the other stuff! I imported the database! I sent celebratory communiqués!
…I spent 20 minutes digging around in my code trying to figure out why none of the navigation links worked even though the pages definitely existed until I discovered my siteurl and home were each missing a trailing slash!
And so, after much ado, I write to you now from the post editor of my new WordPress-backed site, a change which I hope you would not ever have noticed if I hadn’t just written well over 1900 words about it.
Postscript: of course approximately ten seconds after I finished writing this, I realized that a bunch of stuff was borked, and continued to find borkèdness throughout the rest of the evening. It’s fiiiiiiiiiiine.