When building a WordPress site, the goal is to use as much of the WordPress support network as is humanly possible. Don't re-invent the wheel when an existing theme or plugin can get you 99% of the way there.


We will be using Bitnami to install a fully-configured EC2 instance to an already-existing AWS account. This will differ from most Vokal web projects in that there won't be dev or staging instances, you'll be building on "production" and assigning the domain name at the end. So use a client-owned AWS account. Before installing anything, create a key pair on EC2 (if there isn't one on the account already) and make sure to save the private key to your machine--you'll need it to SFTP into the server later.

You'll want to use Bitnami's WordPress installation via the AWS Marketplace (while already logged in with the client's AWS account). Click through the various installation prompts, selecting the default for most things unless you think need a larger instance. You'll also be able to select the key pair you created earlier here.

Bitnami and AWS will do a little dance for a bit, and eventually you'll be able to see the instance in the AWS console. Select the checkbox next to the instance, click the Actions button at the top of the console, select Instance Settings > Get System Log and scroll until you see where WordPress's admin password has been created. This is going to be your only chance to grab it, so... grab it.

Your WordPress site should be available at a URL like ec2-12-34-567-890.compute-1.amazonaws.com, you should be able to find the URL in the AWS console listed as Public DNS.


You can access the WordPress admin panel at <your-domain>/wp-admin/. The default admin username is user, and the password is what you just grabbed from the system log. When you're logged in, any pages that are marked as private will be visible.

To configure your theme files, you'll be using SFTP. Using an FTP client, connect to the site URL using the username bitnami and the private key you saved to your machine before first spinning up the instance. In Filezilla you can go to Settings > Connection > SFTP and add your key file, which will be automatically used when connecting. If you're using another SFTP client, Google it. You'll be doing most of your work in /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/<your-theme-here>.


In rare instances you'll be able to use an existing WordPress theme with small tweaks to complete the project. But odds are you'll have to match a custom design produced by Vokal's visual designers. In this case, start with HTML5 Blank. Go ahead and upload it in the WordPress admin via Appearance > Themes > Add New > Upload Theme. Once uploaded, SFTP into the server, find the theme, and rename the html5blank theme folder to something new, something appropriate for the client/project you're working for/on. The goal is for WordPress to recognize the theme as its own thing, so no html5blank updates ever come down and blow away your changes.

Once you've got the theme renamed, download the whole folder to your machine to start working with. The first thing you'll want to do is a bunch of find-replace to change instances of html5blank, html5_blank, and HTML5 to something similar to the new theme name. As you make changes, go ahead and upload either just your changed files or the whole theme directory to overwrite the server-side files. It's like it's 2001 all over again!

Go into /<theme-name>/style.css and update the comment block at the top, it's what defines how the theme will appear in the admin theme-chooser. Add the project name, Vokal as the author, etc. Then go ahead and blow away the rest of the file. While you're at it, go into /<theme-name>/css/ and blow away most of what's in there. Since you're building a theme from scratch here to match a Vokal design, most of the existing CSS cruft will just get in the way. If you go into /<theme-name>/functions.js you'll find a function called html5blank_styles, or at least one that used to be named that before you find-replaced it into something else. In there you'll be able to change/remove some of the default CSS. I recommend including Vokal's CSS reset instead of the default one. And while you're in there, look for functions like html5blank_header_scripts to edit all the various default things that are being included to suit your needs.


Most of the pages on your site, or at least the blog pages, should use the default templates. These are selected based upon which kind of page you're creating. Static pages will use page.php, blog posts will use single.php, various blog indexes will use pages like index.php, archive.php, or category.php that rely on loop.php to spin through content. All of these start and end with header.php and footer.php.

html5blank comes with an example of a custom template, template-demo.php. All you need to do to make a custom template is have the comment at the top of the file match that example, it'll then be included in the WordPress admin as a choice when working on pages. A custom template is useful when you want custom headers or footers on certain pages, or if you want a pure-HTML page for more complicated designs that doesn't load any content-managed content.

Pages & Posts

While some pages in WordPress are auto-generated (like the blog archive), you'll want to create other ones via the Pages section. These are good for static or semi-static parts of the site, like the home page, the blog index, an about page, terms and conditions, etc. You can set these pages to use custom templates on a per-page basis if needed.

If you want your home page to not be the blog index, you'll need to create two pages, one for the home page and one for the blog, and then go to Settings > Reading and set them to your "Front" and "Posts" pages respectively.

"Posts" are what make up the content of your blog. You can add tags, categories, manage comments, the whole shebang. The "Featured Image" for a post is what will appear in the blog index next to a post excerpt, but be aware that your template may also insert the featured image full-size at the top of your post, so edit single.php as necessary if you don't want that to happen.


When you can use a plugin for something, use a plugin for it. It'll usually save time, and it'll provide an easier managing interface for a client in the future. One example is for custom-HTML pages. Rather than making a template with the HTML hard-coded, install a plugin like XYZScripts that lets you content-manage a list of HTML snippets in the admin, and add them to pages via custom WordPress short-codes. There are also plugins like Yoast that let you easily manage your meta and open-graph tags site-wide and per-page (highly recommended), and AddThis for social network share buttons.

Odds are, if you want to include some service on the site, there's a plugin for it. Don't download and upload them manually if you find them, just use the built-in search in the admin panel, it can install them itself. Be aware that many plugins rely on certain content areas existing in your templates, so you may have to make some tweaks to how your pages are assembled in order for a plugin to insert content where it wants to.


You can point a domain name to your site via Route 53, create an A record that points to the IP address of your running instance. Be sure to mark certain pages or posts as private as appropriate once the site is live, so you can continue development if necessary.