We recently launched our new website, there’s a good chance you’re using it right now to read this article. One of the discussions we had when we started talking about the architecture and technology for the new site, was what to do with the blog. We knew that we wanted the site to be as fast as possible, which was one of the driving factors in making most of the site static pages. However, we also have three years of blog content in Expression Engine (which is what the entire old site sat on top of). This is our story of making the Expression Engine blog live happily inside a static site.
It’s no big secret that we use GruntJS and Assemble for our build system. So, using the same process that we use for generating static templates for all our projects, we built out the static pages for seesparkbox.com. We then had to remove all the non-blog content from Expression Engine—stripping it down to just what we needed moving forward.
One of our first efforts was to use a git sub-module to include the foundry inside the static site GitHub repo. This was a painful experience, so we threw it out the window. Instead, we took the following approach with our folder structure:
- all the EE files
- dist <- this is the generated static site
- src files…
When Grunt runs, it compiles everything that it needs from inside the static folder and generates the static site inside the dist folder. This is the folder that our server points to in order to serve the site.
I was also concerned about keeping the header and footer templates in sync between the static pages and the Foundry. So, when Grunt compiles the static pages, it also generates header and footer templates with the appropriate Expression Engine tags for the Foundry pages and saves them into the foundry folder.
The secret sauce to getting at EE lies in a symlink. So, if you were to peek inside the dist folder, you would find:
foundry -> ../../foundry
This just means that if you try to access
/static/dist/foundry, what you would actually be getting is
/foundry. This allows us to have EE feel like an integrated part of our site, at the URL that we want, yet it still exists separately for development purposes.
This was our quick solution. It’s not completely refined, but it allowed us to get our new site up without a huge effort of converting the foundry articles. It gave us a site that is fast (that was a requirement for us) by eliminating all the database calls for pages that are mostly static.
There are certainly other possible solutions. It’s possible that someday the Foundry will exist as a set of generated blog posts (we’re working on a plan for that). But for today, this gave us the ability to get the new site up quickly with the existing content in place.
Just keep iterating.