In the last Dev Log Odyssey, we spoke about our thought process when it came to figuring out how we were going to approach moving away from WordPress, and building our own homegrown solution for our blog. That included adopting similar technologies to what WordPress uses on their backend, as well as inheriting the core concepts of page and post creation that we’ve become so familiar with over the years. We also mentioned that although WordPress’s “one-size-fits-all” approach was great for productivity and extensibility, we really needed to push it further and create something that caters to how we like to do things.
Now that we have a rough idea of what we’re trying to build, and a development environment to build it in, it’s time to get to work! And here’s what we were able to accomplish so far:
The great thing about working with WordPress was that it pretty much does everything for you right out of the box. It sets up your web server, your database, and everything in between! And although XAMPP will get you most of the way there with minimal configuration, there were still a few things I needed to tinker with to make development a bit easier. That and it was a great opportunity to familiarize myself with how the Apache web server works.
For example, in a vanilla install of XAMPP you would place your website files within the “htdocs” directory and access them using a “localhost” address in your browser. localhost being the default web address hosted on your local Windows installation. However, since I wanted the website to behave like a real website in order to help with unit testing during development, I needed to make some changes. The first of which was adding a virtual host to the web server. Which in turn allowed me to give my local website a more realistic “domain name”. Kind of like what you would find for a real website, like www.backlogodyssey.com. To do that, we needed to point the virtual host to the directory where we store our website files, add a few other configurations including directory access rights, and of course give it a name. In this case, I called our local development copy of the website "development.local" so it would be apparent that we’re working locally and not on the live site.
If we were to try and access the website using it’s new name at this point however, it wouldn’t work. That’s because there was one more step to perform in order to map our new virtual host to our website name, and to instruct Windows on how to serve those website files when we try to access it through a browser. To do that, we just have to list it in the “hosts” system file within Windows, and give it a local IP address. And after a restart, and of course starting up the Apache service, we were in business! We could access the website!
After coming off the high of our first small triumph, it was time to really dig our heels in and begin working on the core functionality of the website. And to start I really wanted page access and page rendering to happen in a few specific ways. The first being, I didn’t want readers to be able to access our pages directly, and have them render implicitly. Instead, I wanted to take a “one page” approach and based on the request (a.k.a. the URL) the target page would be rendered explicitly, dynamically, and through the use of templates. This would have a few benefits, including obfuscating our directory structure, which entails some security benefits, prettier URLs, and it would reinforce consistency since we wouldn’t have to rebuild all of the parts each page would have in common. Long story short, it would make our website more secure and make building future pages easier.
To help “hide” portions of our website and its file structure from prying eyes, we used another Apache configuration file called “htaccess”. This file enables us to redirect and rewrite any incoming requests to conform to our needs. In this case our htaccess file prevents direct access to any PHP files (pages) directly, minus our index page, and if the requested resource is a directory or doesn’t exist, the reader is redirected to the index page. Which is basically our driver for the whole website, and where our dynamic page rendering comes in!
If however, you were to look at our index page, there wouldn’t be much to see. In fact there’s only two lines of code! One to include the core page template file, and the other calls the very important RenderPageTemplate function. Which contains all of the logic and default layout elements to display a requested page. To do that we use some core functions like GetPage, that parses the request to find out what page the reader is trying to access, includes it if it exists, or redirects to Page Not Found page if it doesn’t. Or PageHead which builds a standardized HTML head section based on the page type (core or admin), and includes the appropriate stylesheets and/or script files. Finally, we use the PageBody function, which is where all of the magic happens. That’s because it’s used to render the actual contents of the requested page.
The reason we wanted to take this approach was it keeps each page self contained, easy to build, and simplifies the process of including all of the necessary elements to maintain consistency across the entire site. The only thing required for it all to work when creating a new page is to set the title and type using the PageTitle and PageType functions, as well as implementing the PageBody function. Do that it should render when you try to access it using its name (minus its extension)!
Phew! It may not look like much on the surface, but we think we have a pretty solid foundation to start working on more key elements to the website. Including things like user creation and authentication, implementing the website header, footer, and page navigation, as well as fleshing out some integral pages like our 404, Login, Admin Dashboard, and Edit Post pages!
With that said, it’s time to get back to work, and we’ll see you in the next edition of the Dev Log Odyssey!!
If you like what we do and want to read more of our musings, then be sure to check out our website The Backlog Odyssey!
Or you can follow us on Twitter at @BacklogOdyssey to stay up to date with all of our shenanigans!
