While all of this was taking place (August through January) I was also starting to bone up on some of the front-end coding languages. My HTML and CSS were passable so I tackled PHP first.

It became readily apparent that if the project goals, resolves, honourings and so forth were to all be realized then something terrible and frightening had to happen.

I was going to have to code

The new plan

So, out of all the options, plugins and themes I had tried so far I needed to establish the working set going forward. What I decided was this:

Theme

The absolute best visual experience and behaviour on this project so far came from using the Anders Noren Baskerville that Santi had initially selected. However, as I was going to be doing some custom template code I created what is called a child theme in the WordPressosphere.

A child theme basically sits on top of the original parent theme and carries your customizations. This allows for retaining the customizations when the parent theme is updated, and also keeps the parent theme and customizations separate, so that if things go sideways you know what the starting point was.

Plugins

There was still value in having a layout plugin of some sort, I decided to return to the Site Origins Page Builder as all involved with the project were comfortable with it. I also stuck with just the Types plugin from Toolset to provide the custom post type.

Development Approach

By referencing existing templates, blog posts, the WordPress Codex and other reference sites I crafted a plan of attack. There were a few elements that were helpful in pulling it off as follows.

SASS

SASS stands for syntactically awesome style sheets. It is basically a way of taking advantage of single-sourcing information and settings in the CSS stylesheets. For example, let’s say I have headings, borders and some backgrounds that are all the same colour. Instead of defining that colour in several places I define it in one using a variable and then use the variable.

Template Parts

Early on in this segment of development I discovered something called a template part. So, rather than having to define all of the code for each and every template file, if I had some code that was used in more than one template file then I could use a template part, code it once and then reference that template part in each template that needed it. This would come in useful for the code that retrieves the custom post type and its fields.

A Solid IDE

Nothing incites bitter zealotry quite like a discussion about what tools are best for writing code. VIM and EMACS proponents will fight to the death with each other, but will band together for attack if a Sublime Text user enters the room. And then all three groups will band together like hungry wolves if someone mentions an IDE, which is precisely what I’m going to do next.

All of these tools require significant time in learning their conventions and use, and in establishing their configurations. However, all of them pay back that sunk time a thousand fold in very short order. I dabbled about with each of them for a while (except for EMACS because VIM spoke to me, it sang, it danced, and it bought a round) and came to the following conclusion.

PHPStorm (which does a great job of all 4 front-end languages and sql) with a plugin that makes the editor respond to VIM commands. I won’t say I use these tools well, or even poorly for that matter, I’m very much a novice. But I’m learning and they have already saved me weeks of time.

I won’t talk tools here any more, there isn’t time, catch me later or by email or something if you want to talk more. However, if you are an emacs user and can’t resist the urge to set me straight, do it sometime when I’m not around.

Release the hounds

So, with my newly hatched plan I dug in.