Creating a custom front page for a hosted WordPress site

Blog Posts ,Web Development
October 20, 2015

I wrote this up back in May and never got around to posting it. I was cleaning up some old files today and realized this might still be helpful, so here it is: Creating a custom front page for a hosted WordPress site!

I had been blogging for several years on WordPress.com, and up until fairly recently, it has been an awesome platform for my non-web-developer self to write blog posts and share them easily. I often found myself wishing for more theme customization, but that was really the only thing (and that’s something you can add on to with some paid packages – I’m just cheap). After moving to the Bay Area, though, I went through a phase where I decided I just *had to learn web development* and so I set off on a 60 days of web dev project where I was dedicated to building a new site every day to teach myself how to become a consultant-level web programmer. I had high expectations. I ended up changing gears at day 13, and instead decided to build out a portfolio-style landing page. In two months, I went through two different iterations, and ended up with a site that I didn’t hate, hosted on GitHub. It was one HTML page and a bunch of files from a Bootstrap template that I liked, and it suited me just fine.

When I decided to join the Microsoft Developer Evangelism team this past January, I figured it was time for a face lift on my website and time to take my skills up a level. I had three goals:

  • Upgrade my old, stale portfolio site / landing page to a fresh new one that showcased my love of virtual and augmented reality technologies
  • Go all-in with web dev by changing my WordPress.com site to a Ghost or Jekyll blog
  • Make a web server that actually linked both of those two things together, because up to this point, I had two different domain names pointing to each of them (and quite frankly, they were backwards – livierickson.com pointed to my blog, and virtualinfinity.io pointed to my personal site).

I very quickly decided to change goal #2 after several attempts to easily convert an exported WordPress site to one of the two other blog types. The verdict: Not necessarily worth it, especially since WordPress had never really given me a reason to switch. So I didn’t – but I did still want to move it from .com to a self-installed server in order to give me the customization I was looking for, and I decided to make that the plan instead.

The easiest part for me was updating the look and feel of my website. By the time I was rewriting it for the third time, I had spent some time building other little websites and tools, and my understanding of how websites and apps worked was much more clear. I was able to do the rewrite that is my current landing page in just under a week, and it probably would only take me a day to do something similar now (in fact, I can say for a fact that it now takes me about an hour to set up a static site because I’m doing a workshop with college students about that next week) and I proudly signed up for an Azure account and deployed my GitHub repository with the static site to my domain name. Getting the specifics of that worked out where a little trick at times, but I soon had a achieved part 1 of my goal. Static site, hosted on Azure – check!

The next thing that I decided to do was focus on exporting my WordPress.com site and hosting it myself. Luckily, Azure has WordPress as one of the available templates for web apps, so I spun up one of those in a new web app (Mistake #1) and used the Export tool on WordPress.com to create an XML file of all my old content and media. When I went to the new URL of my WordPress installation in Azure, I happily went to the /wp-admin page and installed the import tool, ready to have everything golden.

Success! It was really simple and straightforward to get this part done, and I again thought that I was golden. Self-hosted WordPress – check! (Or so I thought)

When I moved on to part 3, I thought that there would magically be a way (a button, perhaps?) that I could go into Azure, make a new web app, and say “use this one and this one together and you’re done!” I was naive.

Turns out, learning about the structure of a static site is considerably easier than what I was trying to accomplish, though I’m excited that I finally was able to get it done. I know that I got exceptionally frustrated with some parts, so in order to spare you, here’s what I ended up doing:

1. I deleted the original WordPress installation that I had set up under a different web app service. I went to WordPress.org and downloaded the zip files directly, and used FTP to upload those extracted files into a /blog/ subdirectory under my original landing page site.

2. I reinstalled WordPress by going to my url and using the /wp-admin/ directory, then redid the process of adding the import plugin and redid the uploading of all my older posts. I made customizations to the styles.css file of my theme, and then I had the basics down, with a few issues.

3. You have to make sure to specify that the virtual directory in Azure points to the location of your blog. The default one will load in your index.html pages, but you’ll also have to set up the virtual directory to link to whichever physical file directory you want it to have. I’ll be perfectly honest, I’m still not 100% on whether or not this was the correct or best way to handle this, but it ended up working out well for me so I’m going to throw it in here.

4. When you move a WordPress installation into a directory other than root, you have to make a few changes to the wp-config files to make sure that the parent folder of your blog is added to the posts. This overview was incredibly helpful in noticing the changes that I had to make in order for the .php files to load in blog posts properly. Note: there is a difference if you’re doing this on Azure in that you will have a web.config file instead of a .htaccess file – don’t spent time looking for a hidden one that isn’t there, as I did.

5. Links won’t transfer automatically. I had a mini panic attack when I thought back to four years of blog posts, and while it took me a while to figure out the specifics of the 301 redirects, I finally was able to get them working. Because I was moving from WordPress.com to WordPress.org, hosted on my own site, I was fortunate that the majority of the URLs for each post was the same. WordPress organizes posts by year, so moving it into a different subdirectory as opposed to the root meant modifying the web.config file (I’m on Azure, so it’s IIS) to do 301 redirects from root/[year] to root/blog/[year]. Because this is extraordinarily frustrating if this is your first time working with a web server and applying redirects, I’ve included what I wound up doing below:

Old URL: http://livierickson.com/{years}/{blogposts}

New URL: http://livierickson.com/blog/{years}/{blogposts}

For every directory I had in my old blog (for me, this was 2011 – 2015) I created the following rule in my web.config file:

 <location path="YEAR">
 <system.webServer>
 <rewrite>
 <rules>
 <rule name="redirect" stopProcessing="true">
 <action type="Redirect" url="YOURDOMAINHERE/NAMEOFWPDIRECTORY{REQUEST_URI}" appendQueryString="true"/>
 </rule>
 </rules>
 </rewrite>
 </system.webServer>
 </location>

Because that might be hard to interpret, here’s an example of mine for my 2014 blog posts:

 <location path="2014">
 <system.webServer>
 <rewrite>
 <rules>
 <rule name="redirect" stopProcessing="true">
 <action type="Redirect" url="http://livierickson.com/blog{REQUEST_URI}" appendQueryString="true"/>
 </rule>
 </rules>
 </rewrite>
 </system.webServer>
 </location>

After all of that, the only thing that was left to do was get the domain name set up, which I’ve written about before with Azure sites and NameCheap and I finally had things the way that I wanted them!

(If you’re reading this, you’ve already seen the work in action!)

Related Posts

Leave a Reply