This is the class that does all the hard work of generating forms, processing posted data and securing them.

smart-php-form/formchecker.php

This is the stylesheet that gives the form it’s lay-out. You can adapt it to your heart’s content.

smart-php-form/form.css

Click on the filenames below to see the code of the corresponding file and the companion instructions.

All files mentioned above are available in an archive: desktop-mobile-layout-switcher.

About the PHP

According the PHP there are two things worth mentioning:

• For the use of the script your server needs to support PHP 5.
• To keep the script out of the HTML as much as possible for this basic method, you will find the main part of the script in the folder named ‘inc’, where it is split up in two parts: one is the device detection and the other one is responsible for the switch between presentation of the mobile or desktop version of the webpage.

Version with .htaccess

For those among you that have the rights to put a .htaccess on the server, you need to do the following:

• Write your CSS in the files named desktop_styles.css and mobile_styles.css.
• You can delete the files named desktop_styles.php and mobile_styles.php

Version without .htaccess

For those among you that are not allowed to work with .htaccess on the server, you need to do the following:

• Change the link in the web page(s) to the stylesheets from .css to .php
• Write your CSS in the files named desktop_styles.php and mobile_styles.php. Be careful to leave the PHP code in the beginning of the stylesheets untouched.
• You can delete the files named desktop_styles.css and mobile_styles.css
• You can delete the .htaccess file

To complete the download there is a readme file included.

This script relies heavily on http-headers sent dynamically by PHP. Headers that are defined in .htaccess can never be overruled by PHP, so don’t put these headers (especially Last-Modified and Expires) in .htaccess: the script won’t work then.

The script will be executed on the server in two modi: from the manifest and from a regular webpage on your site.

To clarify this let’s name the first mode “manifest-mode” and the second mode “page-mode”. Both modi use different parts of the PHP-script in manifest-loader.php.

• In manifest-mode the script will be activated directly by .htaccess. In this mode the script will echo the contents of manifest.appcache to the browser, but not before it has searched for pages that are more recent than the manifest, in all the folders that are listed in a special file named folders.txt. Since almost every page of your site may link to the manifest, every time one of these pages is visited, the script will start its search for modificated pages.
• In page-mode if the script is included in the page, it will only check if the current webpage is more recent than the manifest. In page-mode the script sends cache-control-headers (Cache-Control: max-age, Last-Modified, Expires) for the current webpage to the browser.

More about the manifest-mode

1. The script will investigate if the script itself or one of your regular webpages is more recent than the manifest.
2. If so, the manifest on the server will be updated with an new version-number and modification-time. Then it will be sent to the browser, along with some headers that tell the browser that the manifest has expired and will have to be refreshed from the browser during the next request of a webpage.
3. The update of the online manifest forces the visitor’s browser to update its local AppCache.
4. In case there are no webpages more recent than the manifest, the script checks if maybe your stylesheet is more recent than the manifest. In that case the manifest also will be updated.
5. There may be a delay before you see updates of the manifest. This delay is determined by:
   1. The number of files in the appcache that have to be checked for updates (and the time it takes to download modificated files).
   2. On the max-age send sent by the script for each file while in page-mode.

More about the page mode

1. If the requested webpage on the server is more recent than the manifest, the script will update the manifest on the server with a new version-number and modification-time.
2. The script also checks if the requested page is in a folder that is not yet listed in folders.txt. If so, this file will be updated with the new folder. This list of folders enables the script to check this new folder for modificated pages when it’s in manifest-mode.

You need four files, each of which you can find below:

1. The manifest that is called manifest.appcache.
2. The .htaccess file
3. The script that is called manifest-loader.php
4. A register for the folders on your site folders.txt

Also you need to include some extra PHP-code in your regular webpages, as you can see in the samples below.

All files mentioned above are available in an archive: manage-appcache-with-php.

Don’t forget to make manifest.appcache and folders.txt writable! Without this permission the script will not be able to write/change/add anything in these files.

This is an example of the manifest thats is needed to enable AppCache. Modify according to your requirements, but don’t change the first two occurrences of lines that start with “#”.

manage-appcache-with-php/appcache/manifest.appcache

Only the bare minimum of rules needed for this setup are demonstrated here. This file must reside in the root directory of your site.

manage-appcache-with-php/htaccess

In this file manifest-loader.php maintains a list of folders on your site. This list enables manifest-loader.php while in manifest-mode to crawl the folders of your site in search of files that are more recent than the manifest.

manage-appcache-with-php/appcache/folders.txt

This is the script that does all the hard work. It has to be included in the head of your pages (see the sample below).

manage-appcache-with-php/appcache/manifest-loader.php

Below you find examples of three regular pages (two in the root folder of your site and one in a subfolder “subdir”) and of the stylesheet for these pages.

Notice how the manifest loader is being loaded in the start section of your pages. You only have to add some extra PHP-code above the doctype and in the HTML element of your pages. Of course your webpages must have the extension .php for this to work.

In the root folder: page.php (in the manifest)

manage-appcache-with-php/page.php

In the root folder: page2.php (not in the manifest)

manage-appcache-with-php/page2.php

In a subfolder: page3.php (not in the manifest)

manage-appcache-with-php/subdir/page3.php

The stylesheet: css/css.css (in the manifest)

The contents of this file are not very relevant. I’ve only added it here because this sheets also will be checked for modifications by manifest-loader.php.

manage-appcache-with-php/css/css.css

AppCache is a new feature of HTML5. In the html-tag of web pages must be a link present to the “manifest” of the AppCache (preferably with the extension .appcache):

<html manifest="/manifest.appcache">

Now this manifest is used by the browser as central point of reference: in this manifest the webmaster of a site can sum up all the pages, images and documents that have to be downloaded and cached in the background. Instead of checking online for each and every page if a new version thereof exists, the browser consults the manifest to check if that has been changed. If it has not and the requested page/file is present in the AppCache, the local copy will be loaded instead of the online one. Since the manifest is only one small file, checking this for updates instead of the numerous online pages and files is much, much faster.

For more detailed information and instructions how to write a manifest see the links at the end of this page.

The main subject of this post are the problems you can encounter when trying to use AppCache and how to solve them. As easy as the use of AppCache may seem in theory, in practice it soon will surprise you with its seemingly unreliable behavior. It can prove quite hard to force your browser to update it’s AppCache with modified online content.

The AppCache of any browser will only be renewed when the contents of the manifest have been changed. A simple way to make this change of content is to add a comment in the manifest in which you simply write down a version number. Whenever this version number changes, meaning the content of the manifest has changed, the browser will update the AppCache.However, any cache-control with Cache-Control and Expires headers set in a .htaccess-file in the root of a site, can and most probably will conflict with the cache-management by the AppCache. I noticed that whenever I used this standard method of cache-control, AppCache wouldn’t function correctly anymore: it would never update its cache afterwards with newer versions of the same pages. This meant that the visitor would only and forever get to see the out-of-date version of any page once it has been stored in the AppCache. That is, until the visitor deletes the AppCache of his browser.

AppCache can also be problematic on pages that contain a form. When a visitor posts the form, you have make adaptations to ensure that the post will indeed get through. I’ll write about this subject in another post.

I have found a solution to this problem. The central point of it is that the Cache-Control headers are never to be set in .htaccess, but always to be sent dynamically by a scripting language. An example how to accomplish this with PHP can be found elsewhere in this blog. I have tested this solution thoroughly after including it in Site Optimizer, a system I wrote to optimize sites.

In the example script I’ve set the refresh time for the AppCache to 2 minutes. I found that if changed pages were present, the AppCache would indeed be updated after this interval (or a little longer). So the visitor will see changed content after a relatively short delay. When visiting the same page some hours later, the visitor will surely see the changed content of the AppCache, since the max-age of two minutes has by then expired long since. And as long as, in between visits, the manifest hasn’t changed, the pages will be shown from the browser’s AppCache.

The result is very interesting:

1. Despite the low max-age you still have avoided unnecessary downloading of pages that were already downloaded before and that haven’t been changed in the meantime.
2. What’s more: your visitor can see the contents of pages listed in the manifest even when he is offline and hadn’t visited this pages while online.
3. Only the files that actually have changed will be re-downloaded to the AppCache.

You may get penalty points in PageSpeed for the missing expires-headers. If so then PageSpeed obviously is not (yet) smart enough to detect that they are compensated with the advantages of AppCache. The most recent test in YSlow though does indeed compensate for this.

Note: I’ve only tested AppCache on a Windows computer with the browsers available to me on that platform

Chrome

• Chrome has good support for AppCache.
• Very handy feature: when the user deletes the conventional cache of his browser, the AppCache will be cleared also.
• If you want, you can get a list of all the AppCaches managed by Chrome by visiting chrome://appcache-internals/ in this browser. In this list you can delete AppCaches on a per site basis.
• On the visitor’s harddisk the AppCache is being stored in the directoryC:\Users\[User Name]\AppData\Local\Google\Chrome\User Data\Default\Application Cache, but in a non readable format.
• Luckily you can download the extension Service Pages for Google Chrome. One of the utilities in this suite is “View HTTP Cache”. In this utility you can also see which pages Chrome has stored in it’s AppCache. If you click on a page, you see the contents thereof and the headers that were issued by the server when the page was downloaded. This led me to believe that the AppCache not only delivers the contents of pages to the browser, but also reconstructs and sends the original headers.

Firefox

• Firefox has the laudable but also annoying tendency to pop up a dialog that alerts the visitor that “this site is trying to store content for offline use”. In my mind this leaves the visitor with the impression that a site is engaged in shady activities.
• Edit: in my current version of Firefox 6.0.2 I can disable this dialog by unticking a checkbox: Options > Options > “Tell me when a website asks to store data for offline use”. If I remember correctly this checkbox wasn’t available in previous versions of Firefox.
• Firefox’s AppCache will not be deleted when you empty this browser’s conventional cache manually. Instead you have to follow another pathway in the menu: Options > Options > Advanced > Network. In the lower part of this dialog you’ll notice the AppCaches that Firefox manages; these can be erased manually in this dialog. Rather a pity that Firefox didn’t follow the same approach as Chrome i.e.: deleting the AppCaches simultaneously with the conventional cache.
• Edit: in more recent versions of FireFox (6.0.2 and newer) the AppCache will also be deleted when the visitor empties the local cache of Firefox. Huzza!
• Firefox stores it’s meta information about the AppCache in a SQLite database: C:\Users\[Username]\AppData\Local\Mozilla\Firefox\Profiles\[ProfileOfCurrentUser]\OfflineCache\index.sqlite. So this information can be accessed in a SQLite-viewer, for example in the Firefox-extension SQLite Manager. See here an example of the information FireFox stores:
  
• When the browser is in the process of downloading the resources that are being listed in the manifest and the users goes off-line during this process, the browser crashes.

Internet Explorer, all versions

• All versions of Internet Explorer up to version 9 don’t seem to support AppCache: none of the AppCache pages were shown to me when I went off-line. In Internet Explorer 9 only the pages I explicitly downloaded by actually visiting them where available to me when offline.

Opera

• Although the latest version of Opera claims that it supports AppCache, in fact I noticed that it did not work. None of the pages in my manifest were shown to me when I went off-line and tried to surf the site.
• Rather strange, because I did notice that Opera stores AppCache information. You can see what Opera has stored in it’s AppCache when you visit View > Developer Tools > Temporal Storage (maybe the exact wording differs, because it’s my translation of the menu-items in Dutch).
• In C:\Users\[UserName]\AppData\Local\Opera\Opera\application_cache resides a file cache_groups.xml. In this file you can see which AppCaches the browser has stored.
• The contents of the stored pages can be found in dcache4.url in the same folder as cache_groups.xml.

Safari for Windows

In first instance AppCache didn’t seem to work in this browser, because the pages in the manifest weren’t show to me when I went off-line. However, after adding the header “Pragma: cache” Safari handled the AppCache exactly like it should.

Since HTML5 is needed to leverage the advantages of AppCache, you have to determine if the browser supports HTML5 at all. For a mobile browser this can be done by checking in the database of TeraWurfl if it has support for the HTML5 canvas element. To have your website work properly in both desktop and mobile browsers with AppCache, you will need to automate this and more:

1. Have the correct http-headers send for using AppCache as mentioned above: the Cache-Control and Last-Modified headers
2. Adjustment of the version number inside the manifest
3. Detection of the desktop or mobile browser
4. Check if this browser support HTML5
5. Converting the pages to HTML5 (or back to XHTML, depending on your approach)

You can test for yourself the advantages of AppCache in mobile browsers by visiting www.smartscripts.nl in your mobile browser. The system I mentioned above, Site Optimizer, has automated the functions mentioned above, and more, like dynamically changing the content and the layout of pages for the mobile version of site.

Sometimes when a visitor has been denied access to a page (403 error), the offline page defined in the manifest gets displayed instead of the “access denied” message. So I’m inclined to conclude that if a offline page has been defined in the manifest and a visitor tries to load a non existing page, this offline page wil be displayed. This is good to know, so you can adapt the text of the offline page, alerting the visitor to the fact that he either is offline or that he tried to load a private page.

• Get off(line) Good introduction into AppCache.
• Go offline with application cache Just as good an introduction as the previous one into the use of AppCache.
• Appcache Facts Very interesting and valuable AppCache information. With this information I finally tamed the AppCache and got it working just the way I expected it to.
• Using Application Cache Good information about AppCache in Firefox.