1. Upgrade to Drupal 7

Even though Drupal 6 is still supported, upgrading to Drupal 7 is recommended for the many security enhancements as well as usability enhancements.

Because of core coding changes in Drupal 7, existing modules have to be re-written to support Drupal 7. This has unfortunately caused a delay in adoption of Drupal 7 as many sites rely on various contributed modules which in some cases have no Drupal 7 counterpart or only experimental versions still testing in Drupal 7.

Drupal 7 finally includes the ability to update modules from the web interface. Drupal 6 security has been perceived as poor in large part because of many sites not updating Drupal core or any associated modules. With Drupal 6, applying updates for general maintenance was somewhat problematic and inconvenient. This is perhaps what led to many sites putting off updates leading to many Drupal installations being compromised. Updating is improved in Drupal 7, and is somewhat similar to the web-based updates that WordPress users have been enjoying.

Other Drupal 7 security benefits include:

Stronger security for stored user passwords
Passwords in Drupal 7 are hashed with phpass, combining multiple rounds and salted hashes. Drupal 6 and prior stored user passwords in MD5 in the database which is now considered weak and easily crackable.

Update notifications
Drupal 7 incorporates automated email notifications of any pending module or core security updates. This is also available in Drupal 6 via a module, but is now built in as functionality in Drupal 7.

Login Rate-Limiting
Drupal 7 now incorporates brute force login protection. Defaults are rate limiting for five failed attempts in a six hour window as well as rate limiting 50 failed attempts from one IP address per hour. This is configurable in modules/user/user.module.

2. Keep Drupal up-to-date

Keeping Drupal up-to-date is the fundamentally most important security consideration.
Drupal security consists of three areas to maintain security updates:
- Drupal Core updates
- Contributed Module security updates
- Theme security updates
Drupal Core update announcements are available from http://drupal.org/security.
As of Drupal 7, every window in the Administration interface notifies of a pending Drupal Core update.

Modules
Drupal module update announcements are available from http://drupal.org/security/contrib. Drupal 7 has built-in email notification for any outstanding module security updates as well to notify admins of pending updates. Resist the temptation to develop or write custom email forms or other elements for Drupal, but rather look for existing well-established modules that are written to serve various purposes. Existing modules have been tested for the most part in a wide install base and have had more eyeballs on the code to check for security flaws.
Completely remove any disabled modules from the server so as not to have any older vulnerable code live and present in web directories.

Check your sources
In choosing a Drupal theme, consider building upon or using a tested well used theme that has continued updates from the developer. Often users will pick a theme that is ‘pretty’ or meets other cosmetic requirements. However it is critical to inspect if the theme is currently being maintained for security updates. Do not install themes found randomly on the internet; only choose themes from Drupal’s Download & Extend which have been recently maintained. Even then, closely inspect the source to be vetted before launching the code live in a Drupal installation.

Drupal XSS exploits through themes are not uncommon. For example the following theme is susceptible to XSS as one illustration: http://drupal.org/node/1608780

If creating a custom theme, thoroughly test the theme in an installation with various web application scanners, either open source or commercial, that test for XSS or SQLi prior to deployment.

Drush
Drush is the ultimate command line utility to manage Drupal. With drush, it is possible to do such tasks as clearing all Drupal caches, upgrade Drupal core and modules, apply database upgrades (similar to running update.php), enable/disable modules, and much more.
If not already using drush, this is a valuable tool to be on top of and easily patch any outstanding Drupal security updates. More information is at the following URL http://drupal.org/project/drush/.

3. Enable SSH for Update Manager

The built-in Update Manager for updating through the web interface or installing modules in Drupal 7 has the ability to use SSH to connect to the host. This is of course the preferred way to transfer files instead of FTP. If SSH does not show up as an option in Drupal 7′s Update Manager, install the following PHP library:
Debian / Ubuntu:

$ sudo apt-get install libssh2-php

Red Hat / CentOS:
Red Hat and CentOS do not include ssh libraries for PHP. The required package php-pecl-ssh2 can however be installed from the EPEL repository (http://fedoraproject.org/wiki/EPEL).

4. HTTPS and Drupal

Drupal by default operates only over HTTP, including sending any login credentials in plain text. One solution is to have the entire site operate over HTTPS. But while perhaps having an entire site over HTTPS is not ideal as of date, steps can be taken to at least have credentials and other form submissions in Drupal to occur over HTTPS.
Drupal 7 by default uses the secure flag for HTTPS cookies to prevent session hijacking. The module Secure Login (http://drupal.org/project/securelogin) is a required module to help further take advantage of this feature. The Secure Login module allows not only logins but also form submissions in Drupal to occur over HTTPS and have a unique HTTPS session cookie that cannot be hijacked.

Along with the secure cookie flag, the httponly cookie flag can be set in php.ini on the server for another layer of security. In Debian or Ubuntu, edit the following file:

/etc/php5/apache2/php.ini

Red Hat or CentOS, edit the following file:

/etc/php.ini

Use the following values to enforce the httponly flag for PHP session cookies:

session.cookie_httponly = 1
session.use_only_cookies = 1

Without these above changes, one could potentially intercept and steal the authenticated cookie to then gain authenticated access to the Drupal installation.

5. Web server permissions

Permissions of the directories and files in Drupal are critical for security. Files or directories should never be 777, nor are 777 permissions required for Drupal to operate. Directories should be 750 or 755 and files should be 644 or 640.

The Drupal directory and files should be owned by a regular user, and the group of the apache user. This can cause problems for automated updates. Temporarily changing permissions to have the apache user own the Drupal directory so to install updates may be required. Once updates are complete, change the Drupal directory back to be owned by a regular user.

This example command changes the owner to jsmith (example username) and group of the Apache user on Debian and Ubuntu for all files in the Drupal installation:

$ sudochown -R jsmith:www-data /var/www/drupal

To temporarily switch permissions to allow updates, change the owner to the apache user:

$ sudochown -R www-data:www-data /var/www/drupal

Next perform updates, then set permissions back:

$ sudochown -R jsmith:www-data /var/www/drupal

6. Recommended Modules

In the security area, two recommended modules should be part of a Drupal installation.

The Security Review module (http://drupal.org/project/security_review) inspects various aspects of a Drupal installation including file system permissions, user auditing, database and other errors, as well as things such as input formats allowed. This module is also useful in that the interactive results detail how to fix or remedy various issues that apply to the Drupal installation.

Secure Login (http://drupal.org/project/securelogin) as mentioned above is a critical plugin to keep the security of authenticated sessions and form submissions free from session hijacking.

If still on Drupal 6, making use of a phpass module addon (http://drupal.org/project/phpass) will strengthen password hashes for users that are stored in the database.

7. Backups

Regular backups are a part of any system administration and that includes running and administering a Drupal web application. Two backups are required for Drupal: regular full database dumps and also regular snapshot backups of the entire Drupal directory. Should compromise occur, having the ability to roll back to a previous snapshot or compare files to a previous snapshot is invaluable. Creating either automated cron jobs to make backups or using a module such as Backup and Migrate (http://drupal.org/project/backup_migrate) is critical and should be part of the security administration for a Drupal installation.

8. Scanning and Auditing

Regular scanning of the Drupal site with web application scanners or vulnerability scanners is required today to be on top of security. At least monthly scanning at a minimum is a good interval if not more frequently. Many open source as well as commercial web application scanners are able to test sites for XSS and SQL injection which is very relevant to web applications such as Drupal.

9. Operating System Updates and Logs

Drupal security extends to operating system security, which is the host running the web server Apache as well as PHP. If Drupal is installed in a self-managed VPS or other similar installation, staying on top of OS security updates and patches are critical to ensure that the entire host is secure and free from compromise. Subscribe to various Linux distribution security update mailing lists or Twitter feeds to keep on top of any pending updates or security issues for the operating system that is hosting the Drupal installation.

Reviewing Apache or other operating system server logs daily is part of general security no matter what application or software is in use. Make use of logwatch or other automated log alert software to be on top of any trending patterns in logs from would-be attackers.

Conclusions

Drupal security is achievable by keeping on top of security updates for Drupal core and contributed modules as well as taking advantage of SSH and HTTPS options that are available. Most default Drupal installs provided by scripts in hosting companies do not have many of the above mentioned security notes installed or available, which leaves most Drupal users unknowingly connecting and managing their site via insecure protocols. Upgrading to Drupal 7 as soon as possible is strongly encouraged by this author for the many security benefits outlined. The problematic maintenance and upgrading of Drupal 6 is much improved in Drupal 7 which will help users to keep sites and code more up-to-date against today’s seemingly growing threat of attack against web applications. For a deeper look into Drupal and other web application security, check out the web application penetration testing course offered by the InfoSec Institute.

This guest post is written by Scott Miller, a security researcher for the InfoSec Institute with experience in web application hacking, Linux security, and also network security.

ZURB Foundation

Definitely one of my favorite responsive frameworks. Now in version 4, Foundation has now adopted a mobile first strategy. This means that now you can build for small devices first, and then as devices get larger and larger, layer in more complexity. The framework included predefined UI elements and over a dozen single page templates to kick-start your responsive design.

Twitter Bootstrap

Another widely used frontend framework for creating websites and web applications. Contains HTML and CSS-based design templates for typography, forms, buttons, charts, navigation and other interface components, as well as optional JavaScript extensions. Since version 2.0 it also supports responsive design. Both Foundation and Bootstrap allow you to customize the framework download depending on the components you require.

GroundworkCSS

Built from the ground up with the incredibly powerful CSS preprocessor Sass, GroundworkCSS offers some advanced responsive layout techniques. The framework features an incredibly flexible, nestable, fluid grid system and supports any columns in any fractional amount from halves to twelfths. The result is a framework that works for virtually any imaginable modern layout. GroundworkCSS comes with a large number of UI elements which makes the creation of web pages a breeze.

xyCSS

xy.css is a lightweight CSS template for creating semantic HTML5 designs on a responsive liquid matrix. At its heart, xy.css neutralizes rogue browser styles, combines horizontal and vertical grids, and provides a flexible template for responsive design. xy.css brings together the best CSS techniques from around the Web and integrates them into a single, powerful stylesheet template. The site itself ( xyCSS.com ) is built with WordPress, HTML5, CSS3 and of course xy.css. To help visualize the responsive, grid-based design, the site includes numerous on-page browser hints: current browser width, buttons for showing/hiding the grid, current @media rules.

Centurion

Built using SASS and CSS3 media queries, Centurion is a responsive web framework that scales with your device. No longer do you need to worry about the screen size of an iPhone or an Android tablet since Centurion does the work for you. The framework comes integrated with several JavaScript libraries, such as, jQuery, Coffeescript, Craydent and more. It includes a 960px grid (that scales down to 320px), can handle image scaling and has a navigation with desktop and mobile versions. There are also styles for CSS-only buttons and tables. The framework is easy to learn and customizable (thanks to SASS).

Jetstrap for Bootstrap

A web-based interface building tool for Twitter Bootstrap. Built for developers and designers, Jetstrap helps you get awesome websites up and running fast, with less work and digging through docs. Features a drag-and-drop GUI tools and components to create your responsive Bootstrap design. This is a subscription based service with a free account available if you need to try out the features before you buy.

Layoutit

Like Jetstrap Layoutit helps you create your frontend code quickly with Bootstrap using a Drag & Drop Web Interface Builder. It takes every element and component of Bootstrap to make your frontend coding easier without you needing to be an expert in javascript, html5 or css3. All the designs are Responsive and Fluid. Note that Layoutit is not a site-builder but a kind of a scaffolding to kick-start your front-end design.

Pears

Not directly related to responsive design, Pear enables you to collect, test, and experiment with interface pattern pairings of CSS & HTML. Pears is an open source WordPress theme, enabling people like you to get your own pattern library up and running quickly. The WordPress theme allows you as a team to share common HTML/CSS design patterns.

enquire.js

A lightweight, pure JavaScript library for responding to CSS media queries. In responsive design, CSS media queries can only take you so far. enquire.js allows you to harness media queries in JavaScript, giving you the tools to create more advanced responsive sites. More important, it does not have any dependencies, not even jQuery.

Reverie

A extremely versatile HTML5 WordPress framework based on ZURB’s Foundation. Reverie Framework inherits all the cool features from Foundation, and packs with several other interesting features to optimize the experience for WordPress and HTML5. Including customized output for WordPress menus and caption. Reverie utilizes Foundation’s grid to implement layouts. With the power of Foundation, Reverie uses media query to adjust for all kinds of devices, including phones, tablets and computers. Reverie is also optimized for iPhone and iPad

$('.image-container').live('mouseover', function(){
     $(this).children('div').attr('class', 'image-info-active');
});

Obviously this will not work exactly on an iPad like it would on a desktop browser. The overlay will be displayed on a single tap, but will not disappear till we tap another clickable element. One different interaction pattern for the above example is to trigger the overlay on a touchstart event and remove the overlay after some delay. The first step however is to detect if the site is being viewed on an iPad using the browser user-agent string.

var isiPad = navigator.userAgent.match(/iPad/i) != null;

Later we can run the appropriate code depending the viewing device.

if(isiPad) 
{
    $('.image-container').live('touchstart', function(){
        $(this).children('div').delay(100).fadeIn();
        $(this).children('div').attr('class', 'image-info-active');
        $(this).children('div').delay(2000).fadeOut();
    });
}
else
{
    $('.image-container').live('mouseover', function(){
        $(this).children('div').attr('class', 'image-info-active');
    });
}

Now on an iPad the above code will ‘fadeIn’ the preview overlay once the image is touched and then ‘fadeOut’ after a delay. Of course you could try some different interaction pattern to make better use of the touch capabilities of a tablet.

<div class="image-container">

$('.image-container').live('mouseover', function(){
     //...
});

On an iPad mouse events are delivered in the same order you’d expect in other web browsers. As illustrated below, if the user taps a nonclickable element, no events are generated. If the user taps a clickable element, events arrive in the following order: mouseover, mousemove, mousedown, mouseup, and click. The mouseout event occurs only if the user taps on another clickable item.

To make the div clickable one just needs to add a dummy onclick handler, so that Safari on iOS recognizes the div element as a clickable element. Now the mouseover event is fired on an iPad whenever the user taps the image-container div.

<div class="image-container" onclick = "void(0)">

• Response times for accessing your local database are significantly faster than connecting to a remote RETS server for each request.
• RETS servers requires that you query using certain combination of fields and also limits the number of fields you can search on. Using a local database would allow you to search on any field with any combination.
• RETS servers also limit the time of day you’re allowed to access the RETS server and also restricts how much queries you can run per hour. You may also be limited to the number of records you can retrieve per query from a RETS server while a local database wouldn’t have that limit.

Replicating RETS data rather than using the live version is slightly complex, however. In order to replicate the RETS data into your own local database, a series of processes are needed in order to make sure the data you have is both updated and in sync with the server. Those processes typically include the following two major steps: Grabbing the entire database once, and running incremental updates to find changes or new records.

For this project I used the excellent PHRETS PHP library. PHRETS is a versatile library and allows you to communicate with a RETS server in an easy manner.

Grabbing the complete database once.

To kick start the replication we need to get the complete initial database from the RETS server. Once of the important field we will require is the LastModifiedDateTime field. This field instructs the RETS server to only return records that have been modified since the given time. For our purpose here this will require that we pass a very old LastModifiedDateTime for each query. The following for example is a query to get all the records for the city of ‘Anaheim’ since 1 January 1980. Note the ‘LastModifiedDateTime’ value.

(City=|Anaheim), (Status=|A,C,E,H,I,O,P,S,W,X),
(LastModifiedDateTime=1980-01-01T00:00:00+)";

RETS database contains a set of six major metadata tables which we need to replicate on our server: History, Agent, Association, Office, Open House, and Property. Many of these also have corresponding images to go with. Downloading these images requires a separate query and can return multiple images for any single resource.

Your local database schema should always have an index on some main field, for example on ‘ListingRid’ in case of ‘Property’ table. This will ensure that no duplicate records are entered in our database.

Keeping the data in sync

Once we are through downloading the initial database, the next task is to run a regular update to keep the RETS server data in sync with our local server. For this a CRON job that runs on the hour is usually a standard option. The LastModifiedDateTime is again helpful here. Now we can run the same above query but with a ‘LastModifiedDateTime’ that is adjusted with our CRON job. So if you run a CRON job every hour to query the RETS server, we can set the ‘LastModifiedDateTime’ to a value that increments every hour. So for example the following will only fetch the records that have been modified since 3/5/2013 09:00:00am GMT.

(City=|Anaheim), (Status=|A,C,E,H,I,O,P,S,W,X),
(LastModifiedDateTime=2013-03-05T09:00:00+)";

The next query that will run with the next CRON execution will be the following.

(City=|Anaheim), (Status=|A,C,E,H,I,O,P,S,W,X),
(LastModifiedDateTime=2013-03-05T10:00:00+)";

It may happen that a duplicate record is found for some reason, most probably due to incorrect ‘LastModifiedDateTime’ value. We need to take that into account while inserting records into our database as a duplicate record will through an error. I usually check to see if MySQL has encountered a ’1062′ error (Duplicate entry) and then update or skip that particular record, depending on the context.

if(mysql_errno() == 1062)
{
   /* If duplicate record was found */
   $sql = "UPDATE property_table " . $subquery . " \ 
   WHERE ListingRid = '{$record['ListingRid']}'";
}

Ensuring CRON job is executed on regular intervals

Your RETS data will quickly be out of sync if your CRON script fails to run on a regular basis. One of the ways to avoid that is to create a new table in our local database that will have a update timestamp field; let us call it ‘lastupdate’. So every time a CRON script is run on the hour it will add a timestamp to the ‘lastupdate’ field. So now all we have to do to make sure that the CRON script is executed on time is to check for the ‘lastupdate’ field and ensure that the timestamp stored is no more than an hour old.

Backbone.js

Currently the numero uno JavaScript MVC framework. Designed for developing single-page web applications, and is based on the model–view–presenter (MVP) application design paradigm. Backbone was created by Jeremy Ashkenas, who is also known for CoffeeScript. One of the main feature of Backbone that sets it apart from other similar frameworks is its lightweight nature. Backbone.js enforces that all communication to the server should be done entirely through a RESTful API. The frameworks only hard dependency is underscore.js, a library of useful javascript utilities and functions.

Ember.js

Ember.js is an application framework for building sophisticated browser applications. Ember.js (formerly Amber.js SproutCore 2.0) is one of the newest contenders. It is an attempt to extricate the core features from SproutCore 2.0 into a more compact modular framework suited for the web. If you want to build something that tries to tackle desktop-level application development for the web then EmberJS is for you.

The framework supports persistence, computed properties and has auto-updating (live) templates. It also should supports state management rather than the manual routing solution many other frameworks advocate. It also comes with extensive documentation ,templating and has scaffolding tools.

Knockout js

Knockout is a standalone JavaScript implementation of the Model-View-View Model (MVVM) pattern with templates. Knockout includes the following features:

- Declarative bindings
- Automatic UI refresh (when the data model’s state changes, the UI updates automatically)
- Dependency tracking
- Templating (using a native template engine)

AngularJs

AngularJS is built around the belief that declarative programming (HTML) should be used for building UIs and wiring software components, while imperative programming (JavaScript, PHP etc.) is excellent for expressing business logic. AngularJS lets you extend HTML vocabulary for your application to better serve dynamic content through two-way data-binding that allows for the automatic synchronization of models and views. As a result, AngularJS deemphasizes DOM manipulation. It is easy to build complex dynamic UIs with a clean underlying data model and declarative bindings using AngulsrJS

Meteor

Meteor is a new full-stack JavaScript framework, powered by Node.js. Meteor allows you to write your entire application in nothing but JavaScript; not just the client-side, but the server persistence layer as well, with every single API offered in one language. While the framework is yet to reach version 1.0, as long as development remains active you should absolutely investigate this new approach to writing applications.

Express

Express is a light-weight web application framework for node.js to help create a MVC web app architecture on the server side. You can then use a database like mongodb with mongoose (for modeling) to provide a backend for your node.js app. Express basically helps you manage everything, from routes, to handling requests and views. Express was specifically inspired by sinatra

Out of the box, Express provides features such as routing, templating/view rendering , dynamic CSS support, middleware (via Connect), session management, logging, application settings, and a command line interface.

Selecting the appropriate framework

As with every other thing in life that offers multiple choices, selecting a good framework for your next project is not an easy thing. It depends on your particular web app requirement and the features the framework provides. Also, some frameworks require a steep learning curve and you would have to invest a sizable amount of your time. I would suggest you take a cursory look through the documentation of all the above frameworks to see which one suits your need. Also take a look at this article – Journey Through The JavaScript MVC Jungle by Addy Osmani.

<?php
 
require_once('RankChecker.php');
 
$rank = new SEO_RankChecker('www.wired.com');
 
echo "Google PageRank : " . $rank->getPageRank() . PHP_EOL;
echo "Alexa PageRank : " . $rank->getAlexaRank() . PHP_EOL;
echo "Dmoz Entries: " . $rank->getDmoz() . PHP_EOL;
echo "Google Indexed Pages : " . $rank->getIndexedPagesGoogle() . PHP_EOL;
echo "Bing Indexed Pages : " . $rank->getIndexedPagesBing() . PHP_EOL;
 
?>

This will return the following.

Google PageRank : 8
Alexa PageRank : 806
Dmoz Entries: 480
Google Indexed Pages : 367000
Bing Indexed Pages : 427000

The code files can be downloaded from below.

sample-image-0.jpg
sample-image-1.jpg
sample-image-2.jpg

<?php
 
require_once('./class.imagesplitter.php');
 
$splitter = new ImageSplitter;
/* IMAGETYPE_GIF for gif images
   IMAGETYPE_JPEG for jpg images
 */
$splitter->outputType = IMAGETYPE_JPEG;
$splitter->Load('sample-image.jpg');
$splitter->Split();
 
?>

The code supports 3 image types – gif, jpg and png. Use IMAGETYPE_JPEG for jpg images, IMAGETYPE_GIF for gif images. The default format is png when no ‘outputType’ is set. To combine the images to display as a single image on a page you will need something like the following.

<div class="iparts">
  <img src="sample-image-0.jpg" />
  <img src="sample-image-1.jpg" />
  <img src="sample-image-2.jpg" />
</div>

The CSS for the above is given below. This is to ensure that no visible gap is displayed between the different image parts and is shown as a single whole.

.iparts img { 
    display: block; 
    font-size: 0; 
}

Cons of the above method

The obvious drawback is that it takes some extra effort. The other is that for each image split there are two additional resource requests by the browser. So if you have 3 images on your webpage using this method, the browser will have to make a total of 9 requests to the server instead of the original 3. In view of the above points, the method should only be considered if you are seriously interested in protecting your image assets. You could for example only use it while displaying larger versions of your images and not for smaller previews.

“You do not have sufficient permissions to access this page”

This innocuous message however is the source of many a wasted hours. Although there could be many reasons for the above message, the one I most often see cited is the inconsistency between WordPress prefix for the following values:

Table – Column – Value
wp_options – option_name – wp_user_roles
wp_usermeta – meta_key – wp_capabilities
wp_usermeta – meta_key – wp_user_level

So if you have a value like ‘wpress_capabilities’ and the other ‘wp_user_roles’ (notice the different prefixes), the error is thrown. In many cases the value itself is missing from the table after a database upgrade. In a recent case, after a WordPress database upgrade the wp_user_roles option name was missing from the ‘wp_options’ table, which disallowed admin login and displayed the above message. The solution was to add the option name manually to the table with the option value taken from a old database backup. If you do not have a database backup (God forbid) you can use the value from a fresh WordPress installation.

To quickly check if all the above values exist with also the same prefix, you can use the following simple query.

SELECT option_name AS A FROM wp_options WHERE option_name LIKE '%_user_roles'
UNION 
SELECT meta_key AS A FROM wp_usermeta WHERE meta_key LIKE '%_capabilities'
UNION
SELECT meta_key AS A FROM wp_usermeta WHERE meta_key LIKE '%_user_level'

Which will return:

A
wp_user_roles
wp_capabilities
wp_user_level

After much deliberation we settled on using the file system. The major factor in the decision was that we needed the database and images decoupled as we would be having multiple databases using the same set of images. Also in the future it was possible that we would require some processing done on the images (cropping, resizing), which would be tedious and taxing if the images where stored in the database. So in light of these factors we found using a filesystem a suitable solution.

So should you store images in to a database?

That will depend on the actual purpose of the application, so the question is purely subjective and will have different answers depending on the situation.

Deciding where to store images is a matter of trade-offs. There are advantages and disadvantages regardless of whether you store images in the database or in the filesystem. The ever-so-useful MySQL Cookbook has the following to say on the topic.

1. Storing images in a database table bloats the table. With a lot of images, you’re more likely to approach any limits your operating system places on table size. On the other hand, if you store images in the filesystem, directory lookups may become slow. To avoid this, you may be able to implement some kind of hierarchical storage or use a filesystem that has good lookup performance for large directories (such as the Reiser filesystem that is available on Linux).

2. Using a database centralizes storage for images that are used across multiple web servers on different hosts. Images stored in the filesystem must be stored locally on the web server host. In a multiple-host situation, that means you must replicate the set of images to the filesystem of each host. If you store the images in MySQL, only one copy of the images is required because each web server can get the images from the same database server.

3. When images are stored in the filesystem, they constitute in essence a foreign key. Image manipulation requires two operations: one in the database and one in the filesystem. This in turn means that if you require transactional behavior, it’s more difficult to implementnot only do you have two operations, but they take place in different domains. Storing images in the database is simpler because adding, updating, or removing an image requires only a single row operation. It becomes unnecessary to make sure the image table and the filesystem remain in synchrony.

4. It can be faster to serve images over the Web from the filesystem than from the database, because the web server itself opens the file, reads it, and writes it to the client. Images stored in the database must be read and written twice. First, the MySQL server reads the image from the database and writes it to your web script. Then the script reads the image and writes it to the client.

5. Images stored in the filesystem can be referred to directly in web pages by means of tag links that point to the image files. Images stored in MySQL must be served by a script that retrieves an image and sends it to the client. However, even if images are stored in the filesystem and accessible to the web server, you might still want to serve them through a script. This would be appropriate if you need to account for the number of times you serve each image (such as for banner ad displays where you charge customers by the number of ad impressions) or if you want to select an image at request time (such as when you pick an ad at random).

6. If you store images in the database, you need to use a data type such as a BLOB. This is a variable length type, so the table itself will have variable-length rows. For the MyISAM storage engine, operations on fixed-length rows are often quicker, so you may gain some table lookup speed by storing images in the filesystem and using fixed-length types for the columns in the image table.