Many of us who started out on the Web early are likely to have a hardcoded custom website.
That’s so 1999! On EasyWP we started quick and clean with a plain HTML landing page as well. Once you decide to create content more often this becomes a problem. Updating or adding pages to a static site is a nuisance at best.
In the worst case, it prevents you from publishing at all. Also, as a brand that specializes in WordPress, we wanted to have a proof of concept WP site that shows a better way of doing things.
Do you already use WordPress? Then you know how simple self-controlled online publishing becomes with it. Sure, there may be third-party services that are even easier to use, but in exchange they own your content.
For those who do not yet use WordPress as a content management system for their site… You’re probably thinking: “Why bother? The static site works fine. Why fix something that’s not broken?”
Here are some of the advantages in comparison to static sites:
In essence, a static site is very limited in scope and hard to update or change. Even as a web developer you need a significant amount of time to implement basic changes or to add new content.
WordPress simplifies all the common content and website creation, as well as optimization tasks. You can solve problems quickly and for free, and not need the budget to cover a whole team of experts.
Long story short—it was about time to create a proper website with a WordPress backend, and a custom theme on the way too. John, our lead front-end developer approached the task enthusiastically. Here’s how it went. (Spoiler Alert: it worked!)
We wanted to keep our existing design and the look and feel instead of creating a new one. We also didn’t want to code the site again from scratch.
Ideally, we would be able to copy and paste the site into WordPress. Of course, in reality that’s a much more complex process. So, let’s take a look at the nitty-gritty.
First of all, the goal was to reuse the current HTML/LESS code written for Laravel—one of the most popular PHP frameworks. The current frontend module used to display the homepage was to stay intact. In other words, rewriting things was an option.
Building an HTML page is pretty easy once you know how the basic markup language works. Creating a site in WordPress requires more than just plain HTML and some styles, though. You need to make a template or theme in WordPress lingo.
The first step was to create the skeleton for a blank theme. In order not to start from scratch, the web dev decided to use the underscore theme boilerplate. It’s a blank theme and pretty similar to Twenty Nineteen – the standard WordPress theme shipped by default with WordPress 5+.
In order to reuse our styles and scripts, it seemed that we’d need some extra components to be able to compile the LESS and the ReactJS files. After several tests, we were able to take the same packages used for the current homepage version. Hooray!
The next question was how to make the current content of the Homepage editable. Understandably, the developer wanted to reuse the same template that was already working in Laravel.
This answer is… it depends. For this project, we wanted to use the new Gutenberg block feature to make it compatible with the new WordPress editor. Thus, the goals were:
After investigating the new Gutenberg editor: how it works when it comes to editing a page, the block concepts etc., it became apparent that writing a custom Gutenberg block is pretty tedious.
Instead, you can use a plugin called Block Lab, which provides a way to create one or more custom blocks connected to a PHP template.
That was pretty cool because we were able to make the page editable (ok, partially editable actually) and John managed to reuse his previous HTML template.
As you may imagine, we’re not simply looking for a static homepage. We also had to consider:
Would we be able to translate all that into WordPress? It’s not a simple task, but even if we weren’t able to modify everything from the backend, we could still edit the content. Crucial page elements such as headlines and paragraphs among others are already editable. John was optimistic that we would able to improve the editing in a second step.
The next challenge was how to get the dynamic data related to the product list. Fortunately, we were able to get text from the JSON list directly from the old version by using a Request API.
In effect, this enabled us to get the product list from the EasyWP Dashboard. Thus John successfully recreated the whole Homepage inside WordPress.
Moving from a static one-page site (or rather a landing page) to a fully-fledged custom WordPress theme—one that was based on our own branding guidelines—definitely presented some challenges.
Overall, however, it showed that you can change the WordPress behavior and the theme structure with ease. Once you know how it’s done, the actual work is less complicated than you might first expect.
We always try to get new experiences when we develop something. More specifically, we always seek to create something reusable. Ideally, other people will be able to use our tools for their websites too. This way we can give back to the WordPress community and the open source community in general.
In this case, John has created an open source project—a framework which can be used to create a WordPress theme from scratch. It’s still a rough sketch but it’s the same one we actually used successfully in the current EasyWP theme.
The theme framework is called WP Spock and is licensed under the GPL 3. You can use it and modify or contribute in other ways. So join in the fun! You can also simply download WP Scotty. It’s a ready-made boilerplate theme.
Thus this project has been a twofold success. Not only for us—achieving our objective of moving a site from static HTML to WordPress. But we were also able to make the process and tools available for the broader public. It seems we can be satisfied with the end result!
Check out the result of our—mainly John’s—work: the actual WordPress-based EasyWP site. Do you notice the difference? Probably yes: it’s faster obviously!