StaticSync is intended for the case where there is an operational reason why you still need your existing resources to remain in a standard folder structure.

It is not intended as a way to store resources externally in order to increase your storage capability. This should be done by mapping drive(s) to the filestore folder at an operating system level.

Files that are deleted from the filestore will be archived within ResourceSpace rather than deleted so that metadata is not lost. This process is not reversed when the file is replaced - instead a new resource is created.

Staticsync.php should be configured as a nightly cron job and is designed to run from the command line rather than via the web/apache (e.g. 'php staticsync.php').

Resource types are automatically selected based on the file's extension.

StaticSync can also be used as an import mechanism with the 'ingest' option which moves the file into ResourceSpace's own filestore, just as if the file had been uploaded directly to ResourceSpace. Furthermore, metadata can be extracted from the file's path via multiple path/metadata mappings to assist with metadata entry. In other words different parts of the tree structure can map to metadata fields so that project codes and similar metadata can be determined automatically without the uploading user needing to edit resources manually via ResourceSpace.

Configuration options

StaticSync is configured via config.php. Settings are described in config.default.php.

  • $syncdir - The synchronised folder.
  • $nogo - Folders that must be avoided when synchronising. Each folder name is enclosed in square brackets e.g. "[IgnoredFolderA][IgnoredFolderB]".
  • $staticsync_whitelist_folders (version >= 8.4) - Allow the system to specify the exact folder paths under the $syncdir that need to be synced/ ingested in ResourceSpace. When using $staticsync_whitelist_folders and $nogo configs together, ResourceSpace is going to first check the folder is in the $staticsync_whitelist_folders folders and then look in the $nogo folders. See an example of how the configuration for it would look like:
$syncdir = '/var/Projects';
$staticsync_whitelist_folders = array(
  • $staticsync_autotheme - Should themes automatically be created based on the folder structure? The first level will become the theme category and the second level will become the theme (collection) name.
  • $staticsync_folder_structure - If set to true, staticsync will create unlimited theme categories to mirror the folder structure. The script will output a new $theme_category_levels number which must then be manually updated in config.php
  • $staticsync_extension_mapping_default - The resource type will be determined from the file's extension. For file extensions that have no configured mapping, this value determines the resource type ID that will be used. The resource type ID can be found by clicking on the resource type in System Setup.
  • $staticsync_extension_mapping - configures a mapping between a resource type and a series of file extensions used to automatically determine the correct resource type. You will need one instance of this line for every resource type. The format is:
staticsync_extension_mapping[resource type ID]=array("extension 1","extension 2");
  • $staticsync_title_includes_path - The title automatically contains the filename. If this option is set to yes, the title will also contain the path to that file.
  • $staticsync_ingest - if set to 'yes' then the files discovered by StaticSync will be moved to ResourceSpace's own filestore folder. In other words StaticSync becomes another import method.
  • $staticsync_mapfolders - configures a mapping between part of the sync folder path and a metadata field. For example, if you added a mapping for '/projects/' and specified that the second level should be 'extracted' means that 'ABC' would be extracted as metadata into the specified field if you added a file to '/projects/ABC/'. Hence meaningful metadata can be specified by placing the resource files at suitable positions within the static folder hierarchy. You need one line for each mapping. An example mapping is as follows:

The options are as follows:

    • match - the path subsection to match in order to activate this rule. This can occur anywhere within the path. This restricts the action of the import to specific places within the sync folder structure.
    • field - the ID of the field to write the extracted metadata to
    • level - the depth of the extracted folder within the sync folder structure. For the example given above, where '/projects/' is the match string and '/projects/ABC' is a typical subfolder, specifiying level two would extract the value 'ABC'. Hence any files placed in the ABC folder would have the value ABC placed in the appropriate field automatically.

This is very flexible and with sensible folder design and multiple mappings can eliminate the need to enter metadata directly into ResourceSpace when uploading files. A user need only place the file to upload in the correct location in the tree and the appropriate metadata will be added automatically.