However, certain filetypes, thanks to modern web browsers, are rendered as an in-browser page, such as images, PDFs, and MP3s. While this may be a convenience, at times we may wish to force the user to download the files, not just view them in their browser.

In this article I will show two easy ways to do this. The first is using .htaccess, and the second is using PHP.

.htaccess

In your .htaccess file, add the following line for each extension you wish to force download:

AddType application/octet-stream extension

For example, if I wanted to force PDFs and MP3s to download, I would do this:

AddType application/octet-stream .pdf
AddType application/octet-stream .mp3

It’s really quite simple, and can be done quickly.

PHP

The PHP version is a bit more complicated, but can be useful if you want to have a bit more control. For example, you can use download IDs instead of the filename to prevent direct hotlinking. For example, you can assign the ID “3148″ to “BusinessPlan.pdf” and do a forced download.

The basic code looks like this:

<?php
header('Content-Disposition:inline;filename="'.$file.'"');
header('Content-Transfer-Encoding:Binary');
header('Content-length:'.filesize($file));
header('Content-Type:application/octet-stream');
header('Content-Disposition: attachment; filename="'.$file.'"');
readfile("$file");
?>

Of course, this is a huge security hole if you use the structure download.php?file=BusinessPlan.pdf, as anyone can access any file on your webserver. Thus, steps should be taken to secure the user input, or use a database of IDs.

Of course, if you’re just forcing download and don’t need extra control over the download process, you should use the .htaccess version, as it is much simpler and easier to use.

Time for some incentive

This will be a multi-part tutorial in which we explain how to completely transform your site into an organized beast. Today’s section will focus on a few lines of .htaccess that you will soon come to love. But, before we begin, let’s go over a few advantages and some incentive for creating a template-focused site.

1. Maintained through a simple template that regulates code and prevents reuse. This enables you to focus on content rather than code.
2. Easily editable by changing any part of the template. Doing so will immediately change all pages of a site. There is no need to go into multiple files.
3. Can simply be hooked up with a MySQL database for even further organization.
4. Adding pages that jive with your site is as simple as making a file with some text (not HTML/PHP–just content)
5. Can easily be created to have pretty URLs without having to delve deep into .htaccess.

The above list just constitutes a small number of reasons to switch to a template-focused site. A quick note for all you CMS users (WordPress/Joomla/Drupal/etc.): your site is already optimized with a template! This tutorial is mostly referring to those who are creating or have a site that is not running on a CMS.

Bring on the htaccess!

Do you need to be a htaccess genius to create a template-focused site? Of course not! Take a look at the following code. This is all you’ll need:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?cur=$1 [L,QSA]

It may look a bit complicated at first, but it is actually quite simple. This all starts with a request to your site (such as "http://your-site.com/something.html"). If the given request is not a file nor a directory, it will redirect the request to index.php.

As an example, if the user requested "http://your-site.com/asdf", which is neither a file nor a directory, it will redirect to "http://your-site.com/index.php?cur=asdf". The great part about this is that the URL will stay the same. The user will still see "http://your-site.com/asdf" in their URL bar, but index.php will actually be handling the request. Not only does this give you great flexibility, but it makes the management of failed requests (such as not found, forbidden, etc.) extremely simple.

How about that PHP?

Consider the following index.php:

<?php
	$request = isset( $_GET[ 'cur' ] ) ? $_GET[ 'cur' ] : 'home';

	$pathToFile = dirname( __FILE__ ) . '/pages/';
	$fullPath = $pathToFile . $request . '.php';

	if( file_exists( $fullPath ) )
		require_once $fullPath;
	else
		require_once $pathToFile . '404.php';
?>

This is used to parse the request from the user. It first finds the requested page by getting the cur parameter passed to index.php (which is a GET request). If this doesn’t exist, it defaults to the home page. Next, it finds the corresponding PHP page under the pages/ directory and then includes it. So, for example, let’s say you had the following setup:

pages/
.htaccess
index.php

And in the pages/ directory, you have:

404.php
home.php
page.php

If cur is not set, index.php will display home.php in the pages/ directory. Otherwise, it’ll display [cur].php in the pages/ directory, where [cur] is the value of cur.

Sample Occurrences

So, let’s trace a few requests for this site. If the user goes to "http://your-site.com", the htaccess will redirect the user to "http://your-site.com/index.php?cur=".

Next, index.php will receive the request. It will realize cur is not explicitly defined, so it will set it to “home”. After that, it will find the full path to home.php in the pages directory and make sure that the file exists. Because this file does exist, it will include it into the page and the contents will be displayed.

How about "http://your-site.com/page"? This will be redirected to "http://your-site.com/index.php?cur=page".

Since cur is set, index.php will find the corresponding file (which is page.php) inside the pages directory. Once again, because this file exists, it will be included into the page.

Let’s do one last example. Consider "http://your-site.com/test". This will redirect internally to "http://your-site.com/index.php?cur=test".

Cur is explicitly defined. Thus, index.php will look for test.php in the pages/ directory. Unfortunately, this file does not exist. Thus, index.php will serve up 404.php in the pages/ directory. This file displays information that tells the user a 404 (not found) error occurred.

To see this all in action, you may view a demo of the site setup by clicking the link below. Please note that there is no real content on the site – it is just an example that tells you what page is being delivered. Consider requesting “/”, “/page”, and “/test” to see the home.php, page.php, and 404.php in action, respectively.

View a Demo Download the Files

As you can see, with just a little amount of code, the effects of templating can be great. This, of course, is just the starting line of a template-focused site. There is still a lot more to cover. Join us in the next installment when we expand on this concept and teach you how to become even more organized.

If you liked this post, please leave an encouraging comment below! It really helps us keep Lateral Code up and running.

From “The Definitive Post on GZipping your CSS”

CSS files for larger sites can become pretty large themselves. Gzipping or compressing these files has shown to provide a reduction in the neighborhood of 70-80% of the original file size, a fairly significant ‘weight loss’.

So obviously, GZipping CSS is great. But what about JS? JavaScript files are becoming increasingly huge, so what should we do about that?

The article from Fiftyfoureleven that is linked to suggests using the following PHP snippet:

<?php
    ob_start ("ob_gzhandler");
    header("Content-type: text/css; charset: UTF-8");
    header("Cache-Control: must-revalidate");
    $offset = 60 * 60 ;
    $ExpStr = "Expires: " .
    gmdate("D, d M Y H:i:s",
    time() + $offset) . " GMT";
    header($ExpStr);
?>

and then the following .htaccess snippet:

AddHandler application/x-httpd-php .css
php_value auto_prepend_file gzip-css.php
php_flag zlib.output_compression On

So then the obvious solution for JS files would be to make a file called gzip-js.php, with the same PHP snippet with the content type modified to text/javascript, like the one seen at Perishable Press.

Then we run into a problem. For systems like WordPress or ExpressionEngine or Habari, where css or js files might be sent from many different folders, manually putting the .htaccess and gzip file may not be convenient, so I created this system.

gzip.php:

<?php
if(isset($_SERVER['HTTP_ACCEPT_ENCODING']) && substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip'))
ob_start('ob_gzhandler');
else
ob_start();
?>

.htaccess:

################ Expires Control ################
ExpiresActive On
ExpiresDefault A0
<FilesMatch "\.(gif|jpg|jpeg|png|swf)$">
# 2 weeks
ExpiresDefault A1209600
Header append Cache-Control "public"
</FilesMatch>
<FilesMatch "\.(xml|txt|html)$">
# 2 hours
ExpiresDefault A7200
Header append Cache-Control "proxy-revalidate"
</FilesMatch>
<FilesMatch "\.(js|css)$">
# 3 days
ExpiresDefault A259200
Header append Cache-Control "proxy-revalidate"
</FilesMatch>

################## GZip Files ###################
<FilesMatch "\.js$">
AddHandler application/x-httpd-php .js
php_value default_mimetype "text/javascript"
</FilesMatch>
<FilesMatch "\.css$">
AddHandler application/x-httpd-php .css
php_value default_mimetype "text/css"
</FilesMatch>
<FilesMatch "\.(htm|html|shtml)$">
AddHandler application/x-httpd-php .html
php_value default_mimetype "text/html"
</FilesMatch>
php_value auto_prepend_file /absolute/path/to/gzip.php

This snippet allows me to control the expires and content type using htaccess instead of PHP, like in the other examples. And because I use the absolute path to gzip.php, I can ensure that GZip gets applied to all php, js, css, html, shtml, and htm files.

Sources

• The Definitive Post on GZipping your CSS – Fiftyfoureleven
• Compressed CSS Compression – Perishable Press
• Compressed JavaScript Compression – Perishable Press