How to Use Drupal as a Static Site
Static websites, with no database, used to be enormously popular in the 1990’s. They are slowly becoming more popular again in the 2010’s.
Some developers are also modifying platforms like Drupal so that they no longer require a database.
In the Drupal world, Phase2 have done a lot of work when it comes to exporting Drupal to static sites. This introduction to a Phase 2 article nicely sums up why static websites are becoming more popular again:
“Think back with me to the days of static websites. Those were easy! You just threw some html up on a server and that was it. No performance issues, no security issues, no worries about redundant failover if something goes wrong. No getting woken up in the middle of the night because something did happen. It was simple, fast and hard to break.”
Let’s take an overview of the pros and cons of static sites and see what options are available for Drupal.
Why use Drupal as a static site?
Let’s start with the key questions – what the advantages of using Drupal without a database?
The main business case for using a static site is speed and stability. Without expert help, a static site is likely to be faster and less prone to crashing than a dynamic site.
The creators of the Static module also have three excellent use-cases:
- Static websites: Built in Drupal but is rarely if ever updated. There are no “community” bits to it like comments and webforms.
- Archive websites: An archival site such as the various DrupalCon and DrupalCamp websites. While they no longer need to be live Drupal sites or be updated, they should still be accessible to see the content that was there.
- Hybrid Static/Dynamic websites: Drupal can be installed behind a firewall and a static site periodically generated and copied over to a public web server. This would allow content writers to create, update and delete content within Drupal. These changes are tracked and within a short period of time it would be generated and transferred to the public facing site. Essentially it would have the power of content editing in Drupal but be hosted to the public as static HTML.
Disadvantages of static sites
In general, static sites are ideal sites that receive mostly anonymous traffic. You’re unlikely to be running community or e-commerce sites on a static site.
There are also feature limitations to static sites. The Static module developers have a rundown of several key limitations:
- No Drupal comments
- No Drupal search
- No Drupal forms
- No Views filters
- No Ajax callbacks (except pre-generated GET requests)
- Any pagers need to be recoded to use hook_preprocess_pager
- No context (not the module), meaning you can’t change the page contents based on the user unless you do it in Javascript.
Anther major disadvantage is that these modules are still in the early stages of development and don’t yet have many active users and testers.
Option #1. The Static Module
Phase2 have created a module called Static, that will generate a complete copy of your website, in HTML form, including all Javascript, CSS, images and other assets.
The Static module generates a whole new site that can be run independently of Drupal.
This static version of the site does not have a database, user accounts or any other form of user interaction (except 3rd party integrations).
Option #2. The Boost module
Also available for Drupal is the Boost module. Boost is a more lightweight alternative to Static.
Whereas the Static module produces stand-alone sites, the Boost module is just a caching system. Boost generates HTML files that are served instead of Drupal processing the page again, but it does still require Drupal to run.
Boost will cache and compress your HTML, XML, Ajax, CSS and Javascript. Here’s a graphic overview of how the module works:
Option #3. Zariz
There’s also the Zariz project available for Drupal.
Zariz seems to be much more than just a module. Yes, Zariz does generate static sites. However, Zariz puts itself forward as a whole suite of Drupal modules, plus a methodology.
The developers of Zariz aim to bring “the worlds of version control and continuous deployment into the world of content.” Their goal to set up content creation and editing so that it’s “similar to Git’s branches, and allows generating static sites from the Drupal backend.” Fittingly, Zariz is hosted on Github, rather than Drupal.org.
Zariz sets up Drupal content so that it is similar to Git branches. Users can create content in branches, and then merge them and resolve conflicts.
This enables sites to test-publish stories and see how they reflect over all the site’s various pages (e.g. homepage, story page, section page, top stories etc) and then release them to the live site with a single click, similarly to continuous deployment development methodologies.
The developer of Zariz is Amitai Burstein who is also the maintainer of key Drupal modules such as Organic Groups, Message and Entity Reference.
If you’re interested it’s well worth testing Zariz via the Simplytest.me site:
- Launch a sandbox in http://simplytest.me/project/zariz/7.x-1.x
- Navigate to /live/user and login (user: admin pass: admin)
- Navigate to admin/content/migrate and migrate the content
- Go back to the homepage. You can now branch, create and edit content, and merge
You can also get a great overview of how Zariz works via this article, Zariz in Pics.
This interview with Amitai provides a lot more information about the thought process and practicalities behind Zariz:
How about option #4 (and probably the easist option) – “wget –mirror”
LOL, yes, that’s an option too.
or httrack
Or SiteSucker (or similar): [url=http://www.sitesucker.us]http://www.sitesucker.us[/url].
That doesn’t diminish your blog post, which is very helpful. Thanks!
> and probably the easist option
The real problem is how to make it *scalable*. For example, imagine a site with 100K nodes, and one node it edited (a node that appears in the home page, taxonomy pages, etc’). How would you re-create the static site, without regenerating all of it (jekyll for example takes about 5-7 hours for 100K pages)?
Zariz comes with a solution – it remembers the last entity IDs that were changed, so you can just regenerate a small portion of the site. And yes, under the hood all the mentioned solutions use a wget/ curl 🙂
The single most important question I find is needed in Drupal; in fact the very first question that needs asking; I have never found in any tutorial ever!
How do you change the damn Drupal icon and header information? It’s driving me crazy!