Author Archives: SmartScripter

A Smart Form Script

Posted on by
Reply

From this page you can download a smart form script, that almost needs no configuring, but still handles posted forms very securely. This form is an ideal solution if you don’t have an extended programming knowledge and yet want to have a highly configurable form. The form configuration is done by special attributes in the html of the form. The visitor of you site will not get to see these attributes.

The comments in the script will help you to understand and configure the script. All files visible below are available in an archive: smart-php-form.

For your convenience the three files in this archive are listed below, with added syntax coloring. A working example of this form can be seen here. This example will not send any mails however, to prevent the sending of spam mails.

An example page

This is an example of an contact page that contains the dynamically generated form.

smart-php-form/contact.php

Smart Form class

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

smart-php-form/formchecker.php

Stylesheet

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

A Basic Script to Switch Between Mobile and Desktop Layout

Posted on by
Reply

On this page a basic PHP script will be presented to switch between a mobile and desktop version of a webpage. The main target for creating this script was to present a working model that can be used for educational purposes. This way it may become clear how such an approach can be realized and students can experience the main functions that we like to emphasize as important, which are:

  • it automatically detects what kind of browser a visitor uses;
  • it presents the appropriate version of the webpage for desktop and mobile;
  • the automated presented desktop and mobile versions of the webpage will use the same filename (One Web);
  • the script allows the visitor to overrule this automatically determined choice;
  • the visitor’s preference will be stored in a cookie so that at a next visit with the same browser he does not need to use the switch again;
  • since this last function cannot be done without redirection there is a canonical link to the main version of the webpage present (One Web).

A working example of this script can be found here

The code

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

.htaccess

The .htaccess file needs the following code to set the cache-control for the stylesheets. Since cache-control for PHP needs to be set with PHP you will not find the cache-control settings for the webpages in the .htacces file below.

In case you don’t have access to put a .htacces file on your server, you will find special stylesheets below that contain the cache-control with PHP.

desktop-mobile-layout-switcher/htaccess

page.php

This webpage is a template for all the pages in the site. There is no need to bother about the canonical link, the script will automatically take care of it, same as for any duplicate page. The cookie will be automatically placed by the script as well, for all versions of the web page, desktop and mobile and duplicates.

The PHP code is kept out of the HTML as much as possible without losing the aim to make clear what needs to be done and how this can be done. This means there is some PHP in the webpages that can’t be left out:

  • See the comments inside the code of the webpage, don’t leave out to read them. The comments at line 9 are especially important and are about the PHP variable at line 10.
  • You can edit the value of the lifetime of the cookie in the PHP code at line 11. The companion comments explain how.
  • The switch for mobile/desktop looks like this:

    <?php echoSwitch('Desktop Page', 'Mobile Page'); ?>
    The content for either desktop or mobile can be placed between the single quotation marks. Here the content on desktop will be ‘Desktop Page’ and on mobile it will be ‘Mobile Page’. You can place this PHP code where ever you like in the content of the webpage, just make sure you paste it from the first &lt up to the close >. Any content outside of this code will be shown on both desktop and mobile.
  • At line 12 you will find the $maxage variable so that you can set the cache-control for each page as you like
  • At line 34 another PHP code begins that switches desktop/mobile content. If you look closely you will see that the single quotation marks as you can see them in the sample just mentioned, are missing inside the PHP code at line 34 and are replaced with HEREDOC notation. Read the comments that start at line 54 to learn more about this.

desktop-mobile-layout-switcher/page.php

page2.php

This page is created by duplicating the page above. Just make sure that any new webpage that you create will be a duplicate of that page as well and you will be fine. Don’t forget to fill in the page title for desktop and mobile. There is no need to bother about the canonical link, the script will take care of it. Also the cookie will be placed by the script.

desktop-mobile-layout-switcher/page2.php

screen_styles.css

Write your CSS for the desktop version of your webpages in this stylesheet. If you want to change the name of the file, you can change the link in the webpage in the PHP code at line 28. If your server does not allow you to put an .htaccess file, you need to use the stylesheet below, screen_styles.php, instead. Read more about this at ‘Download the files’.

desktop-mobile-layout-switcher/screen_styles.css

screen_styles.php

This stylesheet is meant for those who cannot put an .htaccess file on their server. Write your CSS for the desktop version of your webpages in this stylesheet below the PHP code. Leave this PHP code in top of the stylesheet untouched, it contains the Cache-Control header instead of writing it in .htaccess. If you want to change the name of the file, you can change the link in the webpage in the PHP code at line 28. See below at ‘Download the files’ for additional instructions.

desktop-mobile-layout-switcher/screen_styles.php

mobile_styles.css

Write your CSS for the mobile version of your webpages in this stylesheet. If you want to change the name of the file, you can change the link in the webpage in the PHP code at line 28. If your server does not allow you to put an .htaccess file, you need to use the stylesheet below, mobile_styles.php, instead. Read more about this at ‘Download the files’.

desktop-mobile-layout-switcher/mobile_styles.css

mobile_styles.php

This stylesheet is meant for those who cannot put an .htaccess file on their server. Write your CSS for the mobile version of your webpages in this stylesheet below the PHP code. Leave this PHP code in top of the stylesheet untouched, it contains the Cache-Control header instead of writing it in .htaccess. If you want to change the name of the file, you can change the link in the webpage in the PHP code at line 28. See below at ‘Download the files’ for additional instructions.

desktop-mobile-layout-switcher/mobile_styles.php

inc/switcher.php

This script is developed in teamwork with and for the Mobile Web and Apps Best Practices Training of W3C Online Training.
desktop-mobile-layout-switcher/inc/switcher.php

inc/mobile_detection_class.php

The lightweight class for detection of mobile browsers device detection script below can also be found at http://www.opensource.org

desktop-mobile-layout-switcher/inc/mobile_detection_class.php

Download the files

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.

Force update of AppCache with PHP

Posted on by
Reply

AppCache can be hard to deal with. Browsers seem unpredictable in updating the AppCache. This example of a PHP-script (for PHP 5) makes sure the AppCache gets updated when pages have been changed.

Important

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 Process: two modi

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.

The Files

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.

The Manifest

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

.htaccess

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

folders.txt

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

manifest-loader.php

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

Sample files

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

Know your AppCache

Posted on by
Reply

AppCache can significantly speed up the loading of the pages of your site and lets visitors surf your site even when they are offline and haven’t downloaded all pages yet.

In this post I’ll present a solution to get AppCache functioning correctly (which can be quite problematic). I’ll conclude with some interesting facts about AppCache and how different browsers cope with it.

How does AppCache work?

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 problem: AppCache conflicts with normal cache-control headers

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.

Problems with AppCache and HTML forms

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.

The solution to the problem

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.

AppCache in various browsers

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:
    Example of metadata Firefox stores about the AppCache of a site
  • 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.

Using AppCache for mobile browsers

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.

403/forbidden-oddities

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.

Links