Forty eight hours, twenty seven minutes, thirty seven seconds later and jackpot! My custom WordPress theme and Typekit account remained accessible even when offline. A truly awesome feature from the hyped up HTML5 spec. Lets get this party started with a direct quote pulled from Mozilla’s developer documentation so we can understand exactly what a cache manifest can do for our web apps and websites.
How the cache manifest works: explanation courtesy of MDN
The application cache modifies the normal process of loading a document; if an application cache already exists, resources are then loaded directly from that cache, without accessing the network, ultimately speeding up the page load. The web application then checks if the manifest has been updated on the server and if it has, a new version of the cache is downloaded. This is done in the background and doesn’t affect performance in a significant manner.
Application caches can also become obsolete. If the manifest is removed from the server, the browser removes all application caches that use that manifest, then sends an “obsoleted” event to the application cache object. Then the application cache’s status is set to OBSOLETE.
The cache manifest file shown in example 1a allows our users to cache important and necessary files in order for a WordPress theme to function(.php files need a server to interpret) plus access to Typekit fonts online and off –pretty cool. There are a few caveats we must point out before achieving this offline functionality. Note: Although this case is specific to our context using Typekit with WordPress, the manifest code can still be applied to your WordPress theme even without the Typekit inclusion.
The caveats of offline caching
- Set expires headers on your web server for your
cache.manifestfile to expire immediately. This avoids the risk of caching the manifest files. In Apache (i.e. the
.htaccessfile) you can configure this like so:
ExpiresByType text/cache-manifest "access plus 0 seconds"
Entries must have the same scheme, host, and port as the manifest
- Any page that contains the manifest attribute within the
<HMTL>tag is cached by default. Authors are encouraged to include the direct page resource desired, but once again not required
- The first line of the cache manifest must consist of the string
CACHE MANIFESTdirectly at the top
- Comments may only be used on their own lines, and cannot be appended to other lines. Comments are represented by the # character
- The section header line (i.e. CACHE, NETWORK, FALLBACK ) may include whitespaces, but must include the colon (:) in the section name.
- NO wildcard character(*) is allowed in the CACHE section of the manifest
- In the network section, each line is a a valid URL or URI reference to a resource to fetch from the network (the wildcard * is also allowed in this section).
- Note: Relative URI’s are relative to the cache manifest’s URI, NOT to the URI of the document referencing the manifest.
Now that we have those nasty scary monsters out of the way we can breathe a sigh of relief and get down to business.
- Start by opening up your favorite text editor
- Add the
manifestattribute to you HTML tag
- Copy and paste example 1a into your black cache manifest document
- Save your file as cache.manifest and place the manifest into your site’s root directory
That’s it! Feel free to customize the manifest I have provided further as it is strongly encouraged. If you need help along the way you can always check out this great tutorial by HTML5 Rocks or read the direct documentation and external links given below.
The Web Ahead by Jen Simmons
HTML5 expert Peter Lubbers joins Jen Simmons on the inaugural episode of The Web Ahead to talk about what the heck HTML5, web apps, local storage, offline caching, and web databases are.
App Cache Facts
using html5 application cache to create offline web applications
Gist Example 1a.
very helpful, well explained!
psyched to try this out
(use should move your comments over to diqus just saying)
Wow! Thanks … just, what I was looking for.
What about contact forms and offline-caching? Is there any workaround, so that (for example) “Contact Form 7” can be used offline, too?
Since PHP is a server side language anything written for server side interaction (like validation in this context) will not be available offline. If you really desire
I just started learning the cache manifest yesterday and would like to ask a few questions. Hope you could help me.
I have a site with lots of other pages which consists of say a hundred images(an e-commerce site so there’d be a lot of images for the products).
And I want this site to be accessible offline, just browsing through the products that is.
Should I put the manifest attribute in all the pages or just the home page?
And do I really need to put all the hundred images’ filenames in the cache manifest file? Wouldn’t it be heavy if the site is to viewed through a mobile device? I don’t really know how it works, but that’s what I was thinking. Any advice for something like this? Thank you so much.
If you want the site to be accessible offline you’ll need each page to contain a reference to the cache manifest file. However, I would try referencing it on one page first and test your results. You might find you may only need to reference it once, but then again you can never tell what page a user will land on first. I would suggest keeping the reference to your manifest on every page to ensure your entire site will be available offline.
As far as your images you can glob them together like so
Here’s another great explanation from HTML5Doctor http://html5doctor.com/go-offline-with-application-cache
wow! thank you so much for answering back quickly, really really appreciate it 🙂
so if I put the manifest on every page then I need not declare the pages in the manifest? is that right sir?
No, you still need to include either a directory or the specific files you’re trying to make available offline in your manifest.
images/* is not working sir it gives me the 404 error 🙁 how come?
I have something like this in my cache-manifest file:
The stack overflow issue was misleading to me. Apparently I was incorrect. Here’s the quote from HTML5 Doctor…