It’s high time I wrote a rundown on the arduous process of putting this website together. Perhaps someone will find it useful – if not, hopefully at least amusing.

Without further ado I present:

How to make a website if you are not really a website person (but can write code)

or

Why Delia Is Not A Web Developer

Step 1: Probably choose a CMS

I mean, unless you want to write the content directly into the html forever. Maybe you are that person, who am I to judge? But I am not that person, because I, dear reader, am lazy.

I knew I wanted to have a blog, and a few custom pages that I could add content for (like the Games Room – I wanted to be able to add new items with a fixed format to the portfolio with a minimum of fuss). I had heard good things about WordPress. I knew it was user-friendly, I was familiar with the interface, and I knew there was scope to tweak the code per theme to a certain extent. I thought to myself, ‘this will be handy, I can get a better handle on HTML, CSS and PHP while I work’. (Hah!)

Now, WordPress is a great tool for people with no interest in programming. There is a lot of free stuff you can add with minimum fuss! Loads of free themes that don’t require any coding at all! But I have enough coding nouse that I probably could just as easily dived right into a more complex and flexible CMS.

Reader, if you are me in this situation, I have a nugget of advice for you:

Don’t Use WordPress
Don’t Use WordPress
~ Don’t Use WordPress ~

The eagle-eyed amongst you will have noticed that this site is indeed built in WordPress. I was too far down the rabbit hole when I realised my mistake. WordPress seems to be hobbled mostly by its own purported user-friendliness. Narrow (and occasionally rather dated) assumptions in the core code combined with a mostly uncurated mass of free plugins creates occasional hair-tearing inflexibility and over-simplification in what is otherwise an infuriatingly complex system.

There are a lot of things that could just be a check box in the interface but have never been integrated, despite myriad threads in the support forums asking “how do I do [thing]?”. You also will spend a lot of time asking ‘why doesn’t it just do [thing]?’ and either cutting custom code for [thing], or throwing your hands in the air and finding a plugin that doesn’t exactly do [thing], but is close enough. The joys of open source!

Step 2: Dick around for a while until you realise you have literally no idea what you are doing

Start with a child theme of a layout you like the look of. Rapidly discard it because it is full of voodoo CSS magic (negative margins. just. ???). Look for a basic boilerplate instead – I eventually found the _s theme, because I like a) starting from a comparatively blank slate, and apparently b) re-inventing the wheel. Spend a week poking things. Tentatively put together some test pages. Admire your website. Maybe Times on a white background is appropriately ‘retro’ now and you can just publish it? Are you supposed to be editing index.php, home.php or front-page.php? How do you put a menu in the sidebar? Who knows, it is a mystery.

Step 3: RTFM

Find the documentation for your chosen CMS and read it. Google shit until something clicks. In my case this translated to: stare in bewilderment at pages and pages of WordPress documentation until you finally give up and just start reading the source code because at least that way you can work out what it does.

WordPress has something called a ‘codex’, which is not to be confused with the WordPress code reference, despite frequently including code examples. The codex is not, in point of fact, a codex, no matter how one stretches the meaning of the word. It is a wiki; just call it a wiki, you pretentious fuckers. Jesus.

Did you know WordPress has a function called maybe_unserialize() ? Listen, I just feel like if that is a function you think you need, maybe your system has bigger problems than the serialisation state of that piece of data.

Step 4: Maybe having a design would help?

You think to yourself that every web designer you’ve ever worked with mostly made nice things in Photoshop, at least before they got handed to developers for evisceration and general mangling (er, the designs, that is, not the designers). So at this stage I went back to the literal drawing board and spent some time poking away at a layout, armed with Adobe Colour, my Bamboo tablet, and mediocre design skills. I knew I wanted the site to echo the layout and style of Renaissance-era printed material, and accordingly spent more time than necessary looking at pretty things on my bookshelf and BibliOddysey.

Once you’ve got an idea of layout, hazard a wild guess as to the appropriate screen size to design for. This will quickly go out the window once you start viewing it on different devices so it doesn’t really matter, you can probably pick a number at random? Don’t design explicitly for smaller screens or different aspect ratios, just assure yourself that you’ll be able to work out that whole responsive thing as you go. Everything will probably be fine.

Step 5: YOU NEED A LOGO

Spend several days drawing dumb shit in Photoshop because you feel like you need some sort of icon in the top left corner. That’s a thing, right? Painstakingly clean it up so that you can use Live Trace in Illustrator to make a vector version. Spend way too long painstakingly cleaning up the live traced version, and assure yourself that it was still faster than drawing it with the pen tool.

Waste a day looking at pretty Renaissance architectural drawings and motifs. Draw an arch. Excellent. What a good arch you have drawn. Export your icon to .png and realise it is going to be minuscule on the site. NEVER MIND you can always put it on business cards later.

Step 6: Create your custom content templates and agonise endlessly over them

Stare at PHP scripts. Stare at Chrome Developer Tools and Firebug. Did you know that if you have a syntax error in your PHP and you forget to put WordPress in debug mode, it fails to render entirely? I did not find the debug setting until a day or so before I was finished. It’s in wp-config.php, which is obvious in hindsight. Move divs around until you work out which ones are which. Decide that you want the sidebar function to be called in the header file. Use grep and sed to comment out the footer completely. What could possibly go wrong?

Real talk: This is where most of the work and most of the frustration happened. I happen to be a person who is especially fixated on ‘neat’ solutions to a problem – solutions done with a minimum of code and effort, that satisfy some inner aesthetic demon. WordPress happens to be a neat person’s nightmare in many ways.

I have three main areas in the site apart from the front page. Two of these are intended to show bog-standard blog posts, and The Games Room is a page of custom post types. What I wanted seemed simple – on each page a title, a subtitle, and then a pre-defined number of the appropriate posts listed.

At first I tried to do this using pages, with the subtitle in the page content, and custom query loops to get the appropriate posts, but it ultimately felt like a clumsy solution, and one that required far too much bespoke code. Besides which, I couldn’t get the permalinks to work without risking errors – I had a page with the slug games-room, but I also wanted my custom post permalinks to be /games-room/post-name. Protip: WordPress breaks horribly if you try to force it to share permalink slugs across different types of posts/pages in ways it doesn’t expect.

What I eventually struck on was using WordPress’ built-in capacity for categories and category pages to my advantage. The Study, The Salle and The Games Room are nothing more than post categories. Categories have a title and a description, which handily took care of the ‘title and subtitle editable in CMS’ issue. WordPress allows you to define custom php files for categories, which gave me my custom thumbnail layout for the games room.

Combining this with a plugin to remove the extraneous word ‘category’ from the urls gave me my nice, neat permalinks: root/room-name/post-name. A satisfactory solution, and one that uses only the main WordPress loop on the page for each post type, which gives me more flexibility for future changes and additions (infinite scrolling, for example, won’t work with custom secondary queries).

Other plugins I used included: the Metabox plugin, which allowed me to specify a bunch of custom fields like year, studio, site link etc for my Games Room posts; a plugin for category sticky posts, which lets me keep the ‘welcome’ post at the top of the Salle. There were also a couple for messing around with the database which I used sparingly (that is to say, activated, used once, and then deactivated).

Treat plugins cautiously. They are the most likely points of a) failure in the code, and b) entry for attackers.

Step 7: Style that motherfucker

Wail. Gnash teeth. Read StackOverflow until your eyes bleed. Wonder why it WON’T DO THE THING. Explain in great detail to your partner what is wrong with the CSS box model. NEGATIVE MARGINS. Why is it so hard to make something just fill the remaining space? negative marginssss. Decide it looks ok Chrome, Safari and Firefox. Internet Explorer can fuck right off. Realise it looks terrible on mobiles. Realise that there is a better than 50% chance most people will look at it some kind of mobile device, especially if you link from Twitter. Disappear into the woods to be a hermit for your remaining days.

Step 7: OH SHIT VERSION CONTROL

Throw it into git (or your preferred source control) at the last minute. I followed, approximately, this guide, although I didn’t version the database because bugger that for a game of soldiers.

Step 8: GO LIVE ALREADY because if you don’t do it now you will nitpick it endlessly forever

It might explode a bit. I had to do a find-and-replace on my database file to change out utf8mb4 encoding for plain old utf8, because my Dreamhost server is running rather an older version of MySQL than my MAMP install. (I suspect this will continue to bite me in the arse in future).

I had some errors due to the WordPress-generated .htaccess files behaving differently on localhost than on the server. The trick to this generally seemed to be to flush the rewrite rules, which is the WordPress equivalent of turning all your links off then on again. It is supposedly done by simply visiting the Settings > Permalinks page in the WordPress dashboard, but older documentation suggests you have to select a different permalink structure, save, and then reset it to the one you want.

Step 9: Fix the mobile version

Stare, befuddled, at your site on an Android Nexus 7, wondering why there is a such a giant margin above the site header. (The culprit: default browser margins, which caused most of my styling problems). Rage against the very small machine. Juggle magic number pixel breakpoints until it looks acceptable on all of the devices you can find in the house. Call it good enough.

Step 10: Share your newly-minted website!

Some friends will like the link on Facebook. Your mum will send you an email telling you how marvellous it looks. Success!