When using the file manager, it's obvious that not all files are treated exactly the same way: for example, files of the image type will have their own thumbnails created, and the custom attributes width and height set. This happens automatically when the files are uploaded or rescanned. Additionally, files of the image type provide an "Edit" option in their menu, which launches the picnik image browser. Certain file types also have a view option, which allows them to be viewed within an overlay window.

This is all made possible by the FileTypeList object, which registers a large number of file types, along with whether those file types support inline viewing, editing, and/or should have a custom metadata inspector routine applied during import/rescan. These metadata routines are responsible for the generation of thumbnail images and setting of custom attributes. Here is a sample of the file types registered by concrete5, as found in concrete/config/file_types.php

$ft = FileTypeList::getInstance(); 	$ft->define('jpg,jpeg,jpe', t('JPEG'), FileType::T_IMAGE, 'image', 'image', 'image'); 	$ft->define('gif', t('GIF'), FileType::T_IMAGE, 'image', 'image', 'image'); 	$ft->define('asf,wmv', t('Windows Video'), FileType::T_VIDEO, false, 'video'); 	$ft->define('mov,qt', t('Quicktime'), FileType::T_VIDEO, false, 'video'); 	$ft->define('js', t('JavaScript'), FileType::T_TEXT); 	$ft->define('pdf', t('PDF'), FileType::T_DOCUMENT, 'pdf'); 

This code is responsible for defining how the system deals with files, based on extension. The first line sets up all files with the matching extensions (the first argument) as types of the JPEG variety. Their generic type ("Image") is set in the second argument, and the third fourth and fifth arguments set their custom metadata importer, inline file viewer, and editor, respectively. All may be left blank if they are unavailable or not applicable. An additional parameter that you don't see here is $pkg, which lets application developers bundle these are part of a package. More on this later.

Inspectors

In the example above, all our image files reference "image" as fourth argument. This is the "image" file inspector, which can be found at concrete/libraries/file/types/image.php. This file is automatically loaded and run when it is needed.

Inspector Setup

All inspectors must contain one class, which extends the FileTypeInspector core class. It must be named xxFileTypeInspector, where xx = the camel-cased name of the filename. e.g. "ImageFileTypeInspector", "FlvFileTypeInspector". Here are the contents of the built-in file inspector.

	public function inspect($fv) { 		 		$path = $fv->getPath(); 		$size = getimagesize($path); 		 		 		// sets an attribute - these file attribute keys should be added  		// by the system and "reserved" 		$at1 = FileAttributeKey::getByHandle('width'); 		$at2 = FileAttributeKey::getByHandle('height'); 		$fv->setAttribute($at1, $size[0]); 		$fv->setAttribute($at2, $size[1]); 		 		// create a level one and a level two thumbnail 		// load up image helper 		$hi = Loader::helper('image'); 		 		// Use image helper to create thumbnail at the right size 		$fv->createThumbnailDirectories(); 		$hi->create($fv->getPath(), $fv->getThumbnailPath(1), AL_THUMBNAIL_WIDTH, AL_THUMBNAIL_HEIGHT, true); 		$hi->create($fv->getPath(), $fv->getThumbnailPath(2), AL_THUMBNAIL_WIDTH_LEVEL2, AL_THUMBNAIL_HEIGHT_LEVEL2, true); 		 	}

This is pretty easy to read: the inspect function runs, and is passed the current FileVersion object being inspected. It uses this object to get the files image and height, set the attributes for width and height, and uses the internal image helper to create thumbnails based on internal concrete5 constants.

Viewers

The fifth argument of the FileTypeList::define() method specifies whether a file has an inline viewer available. This file will be found at elements/files/view/name.php, where name = the passed parameter. This element will automatically be loaded into the overlay that is presented when a user clicks "View" on files of this type. The element should contain logic necessary for viewing the item within the context of a web page. For example, these are the entire contents of the image viewer element:

	$path = $fv->getRelativePath(); 	print '<img src="' . $path . '" alt="" />';;

$fv will be in the element's current scope. Viewing a video would be as simple as:

<? 	$path = $fv->getRelativePath(); 	?>  	<OBJECT ID="MediaPlayer" WIDTH="80%" HEIGHT="80%"> 	<PARAM NAME="FileName" VALUE="<?=$path?>"> 	<EMBED src="<?=$path?>" NAME="MediaPlayer" WIDTH="80%" HEIGHT="80%"  ></EMBED> 	</OBJECT>  

Editors

The sixth argument of the FileTypeList::define() method specifies a custom editor element for a file type. A text file might specify a simple text area or rich text editor. Our image type specifies Picnik. Editors work exactly the same as viewers.

Defining your own import routines, viewers and editors for your site or package.

If you want to employ custom behavior for files of a certain type within your site, you don't need to hack the concrete/config/file_types.php file. Instead, just copy the line you wish to change into a file named config/site_file_types.php in your local web root, and change it there. These definitions will be loaded after the core definitions, and matching ones will override the core.

Similarly, you can run the FileTypeList::define() function from within a package's on_start() function. When doing this while specifying a $pkg object as the define() function's final parameter, you can create packages which alter the default behavior of file types (for example, adding certain additional functionality to PDF or Word files.)