Say your name is Awesome Developer and you’ve built a website for a client. This site runs on SilverStripe, because, let’s face it, you’re awesome and you want an easy-to-use CMS for your client, a CMS that is also packed-full with useful developer features.
Suddenly you are faced with a serious problem. Your client’s name is Popular Scrooge. He says to you one day, “Hey Awesome, you know that site you’re building for me... I want to create a section for pictures of kittens riding skateboards, and post links to all the social networks. You know I have about ten million Twitter followers, right? Will that get me lots of hits? Oh, and by the way, I don’t want to spend any more money.”
You respond, “Hey you Scrooge, both SilverStripe and I are awesome, but SilverStripe dynamically builds every page request. That many hits will totally crash a single web server. We need to buy more hardware and put in some kind of caching server in place.”
Scrooge says, “You are Awesome, I’m sure you can figure out a solution that won’t cost any extra money.”
You wonder what to do, then you (somewhat recursively) read this blog post and learn about the Static Publish Queue module. You enter the following command in your command line to install the module:
composer require silverstripe/staticpublishqueue
Next, you run the three scripts listed in the Quick Setup Instructions. Then, boom! Whenever anyone publishes a page, SilverStripe generates a static html file with the page content. The htaccess file now magically redirects requests so they access the static html file instead of hitting SilverStripe. You can tell that the content you are seeing is served from the static files, because when you look at the page source, each page has an html comment at the end telling you when the static html file was generated.
“Awesome work, Developer”, Mr Scrooge says, “I knew you could do it. It took you ten minutes and you increased the server performance by a factor of 100! Clicking around the site, pages now load virtually instantly. Fastest website I’ve ever seen! How did you do that?!”
You explain that the Static Publish Queue module creates a queue of items to be statically published. Each time you publish a page it gets added to the end of the queue. You can also place all the pages on the site into the queue by running the RebuildStaticCacheTask build task. The StaticPagesQueueReport shows you the status of the queue. The report even auto-updates as the RebuildStaticCacheTask task builds html pages from the queue, a task that runs continuously.
The htaccess rules are smart enough to direct any POST/GET requests with parameters to SilverStripe, the idea being that SilverStripe might want to generate a custom dynamic response to a page called “/search?query=kittens”, while pages without query parameters can safely be directed to the static version of the page.
The end result of all this is an html copy of the entire website structure in a “cache” directory in your web-root. If you are feeling adventurous, you might even upload this structure to Amazon S3 and use that as a static copy of your website in case your web-server goes down. Take a look at this announcement from Amazon to see the technology involved.
So, there you have it - the Static Publish Queue module makes it really easy to add static publishing to your site. The module can do a whole bunch more than described in this blog post: events, distributed cache rebuilding, custom stale pages, integration with proxy server, you name it, it’s got it! Check out the readme file and look into the source code to learn more.
Here is the module on github.
