General Fedora-Drupal in First Islandora

General Fedora-Drupal

This is a general description of the UPEI Fedora/Drupal system and how we are using bth products, on their own and integrated. This is based on a description created by Paul Pound on March 28, 2008. *

General System and Components

  • Fedora 2.2.1 with fgsearch 1.1, Kowari (xx) and Postgres (XX).
  • Drupal 5.x, php5, and mysql (XX).
  • Lucene (XX), curl (XX)
  • api-a (api-a includes methods to mostly consume the objects) is locked down so authorization is required.
  • api-m (mangement api used for ingest etc.) needs authorization as well and can only be used from specific ip addresses. Both of these settings are pretty common but some users probably have api-a more open and rely on the xacml security policies.

We have drupal on one box, Fedora on another and the databases are on a third.

Search and Display

Currently we send rest type calls to Lucene via Curl. The results are provided in xml that we display using an xslt to transform the results to html.

  • Collection listing: we send an itql query to Fedora's resource index (in our case Kowari as mptStore does not understand itql) via curl/rest. We receive xml results and for the modules in test we are parsing the xml in php but will be switching to xsl. This will give us much more flexibility as we can store the xsl with the collection object.
  • Datastream listing: we send a soap call to Fedora that returns an array which is displayed using php code.
  • Metadata display: we are grabbing the QDC or DC datastream from the object via soap. Since the returned datastream is xml we are using an xsl to transform the stream to html.

Editing and Ingest

  • To edit the metadata we grab the QDC/DC xml stream and parse it to create a html form. In our standalone app we use an xsl, but our newer Drupal-based technique uses Drupal's form api: after parsing it in php we pass a php array to Drupal which builds the form.
  • For ingest each collection will have a collection_policy datastream (if it doesn't have one we can fallback to a standard that is part of the module). The collection_policy defines what content_models are allowed as part of this collection. A content_model in our case defines what type of file can be ingested and what to do to that file (such as create thumbnail etc).
  • All the management functions use soap to add, purge, modify, ingest etc.


  • We are mapping drupal paths/menus to php functions.
  • We use the form api for the forms.
  • We use IMCE to upload the files. By using IMCE we can give file size quotas, and storage limits to drupal roles. We can also limit what type of files they are allowed to upload using IMCE. IMCE is the same widget tinyMCE uses to upload files.
  • We rely on clean urls and the drupal file system being public. Initially we tried to support normal urls and clean urls but it gets to hard to maintain when there are so many paths to something.
  • We have several permissions you can configure which include add fedora datastreams, edit fedora metadata, ingest new fedora objects, purge objects and datastreams, and view fedora collection.
  • Specific roles can have a range of permissions so you can define who can do what.