A starting Drupal configuration for Islandora sites.
The Starter Site is a ready-to-customize Drupal site that shows off Islandora's features. It can be used as a template for your site, but once you start using it, your site (and all its config) are managed by you. Like a template MS Word document, changes that are made to the template after you've started using it cannot and will not be automatically transferred into your copy (in this case, your Islandora site). If you need these kinds of services done for you, check out our service providers. However, we will endeavour to document and communicate changes, should you wish to incorporate them.
The Starter site contains instructions to set up a Drupal site, but several features requre the presence of external services such as Fedora, Solr, and others (see installation instructions below).
The Starter Site uses semantic-like versioning now, but this is only for compatibility with the tools that install it. The Starter Site will change major versions whenever it requires something new from the tools that create its environment (Playbook/ISLE).
To launch a fully-functioning Islandora Starter site as well as the (non-Drupal) tools and services that support it, try one of the Islandora deployment tools:
- Islandora Playbook - Ansible-based, works locally with VirtualBox and Vagrant.
- use the
starter
(default) orstarter_dev
option
- use the
- ISLE-DC - Docker-based
- use the
make starter
ormake starter_dev
option
- use the
The config files in the Starter Site assume a full suite of external services. If you do not need all the external services (such as Fedora or Matomo) then you can skip them but you will also want to adjust the Drupal configs. Such a partial install is beyond the scope of this document.
- PHP and Composer installed
- A Database server installed and configured for Drupal
- The Starter Site installs drivers for MySQL/MariaDB/Percona (
mysql
), PostgreSQL (pgsql
), and SQLite (sqlite
). Using other (contrib) drivers would require additional installation/configuration, and is outside the scope of this document.
- The Starter Site installs drivers for MySQL/MariaDB/Percona (
- Fedora Commons (FCRepo) installed
- Syn installed and configured with a key.
- Triplestore installed
- Cantaloupe installed
- A IIIF URL is expected to be resolvable, and to accept full URLs as
resource IDs. If the URL is not
http://127.0.0.1:8080/cantaloupe/iiif/2
, this will have to be set (see Usage step 5).
- A IIIF URL is expected to be resolvable, and to accept full URLs as
resource IDs. If the URL is not
- ActiveMQ/Alpaca/Crayfish installation
- ActiveMQ expected to be listening for STOMP messages at a
tcp
url. If not the defaulttcp://127.0.0.1:61613
, this will have to be set (see Usage step 5) - Queues (and underlying (micro)services) configured appropriately:
- ActiveMQ expected to be listening for STOMP messages at a
Queue Name | Destination |
---|---|
islandora-connector-homarus |
Homarus (Crayfish ffmpeg transcoding microservice) |
islandora-indexing-fcrepo-delete |
FCRepo indexer |
islandora-indexing-triplestore-delete |
Triplestore indexer |
islandora-connector-houdini |
Houdini (Crayfish imagemagick transformation microservice) |
islandora-connector-ocr |
Hypercube (Crayfish OCR microservice) |
islandora-indexing-fcrepo-file-external |
FCRepo indexer |
islandora-indexing-fcrepo-media |
FCRepo indexer |
islandora-indexing-triplestore-index |
Triplestore indexer |
islandora-indexing-fcrepo-content |
FCRepo indexer |
islandora-connector-fits |
CrayFits derivative processor |
- A Drupal-compatible web server
- A Matomo installation
- Further details in the
matomo
module's documentation
- Further details in the
- FITS Web Service and
CrayFits installed
- Further details in the
islandora_fits
module's README/documentation
- Further details in the
- A Solr server installed or available with a core set up
- Further details on Drupal's Search API Solr module page.
- If not available at
127.0.0.1:8983
, or if the core name is notISLANDORA
its information will need to be set up (see Usage step 5)
-
Create a project based on this repository:
composer create-project islandora/islandora-starter-site
This should:
- Grab the code and all PHP dependencies,
- Scaffold the site, and have the
default
site'ssettings.php
point at our included configuration for the next step.
-
Configure Flysystem's
fedora
scheme in the site'ssettings.php
:$settings['flysystem'] = [ 'fedora' => [ 'driver' => 'fedora', 'config' => [ 'root' => 'http://127.0.0.1:8080/fcrepo/rest/', ], ], ];
Changing
http://127.0.0.1:8080
to point at your Fedora installation. -
Install the site:
composer exec -- drush site:install --existing-config
After this step, you should configure your web server to serve
web/
directory as its document root. -
Add (or otherwise create) a user to the
fedoraadmin
role; for example, giving the defaultadmin
user the role:composer exec -- drush user:role:add fedoraadmin admin
-
Configure the locations of external services.
Change the following Drupal configs to your values using any method (GUI,
drush cset
, config overrides in settings.php
...):
Value | Drupal Config item | Default Starter Site value |
---|---|---|
ActiveMQ (broker) | islandora.settings broker_url |
tcp://127.0.0.1:61613 |
Cantaloupe (for OpenSeadragon) | openseadragon.settings iiif_server |
http://127.0.0.1:8080/cantaloupe/iiif/2 |
Cantaloupe (for Islandora IIIF) | islandora_iiif.settings iiif_server |
http://127.0.0.1:8080/cantaloupe/iiif/2 |
Matomo URL | matomo.settings url_http |
http://localhost:8000/matomo/ |
Solr - URL | search_api.server.default_solr_server backend_config.connector_config.host |
127.0.0.1 |
Solr - port | search_api.server.default_solr_server backend_config.connector_config.port |
8983 |
Solr - core name | search_api.server.default_solr_server backend_config.connector_config.core |
ISLANDORA |
-
Make the Syn/JWT keys available to our configuration either by (or by some combination of):
- Symlinking the private key to
/opt/islandora/auth/private.key
; or, - Setting the appropriate location as
key.key.islandora_rsa_key key_provider_settings.file_location
(using the methods listed in step 5 or at/admin/config/system/keys/manage/islandora_rsa_key
)
- Symlinking the private key to
-
Run the migrations tagged with
islandora
to populate some taxonomies, specifying the--userid
targeting the user with thefedoraadmin
role:composer exec -- drush migrate:import --userid=1 --tag=islandora
This should get you a starter Islandora site with:
- A basic node bundle to represent repository content
- A handful of media types that store content in Fedora
- RDF and JSON-LD mappings for miscellaneous entities to support storage in Fedora, Triplestore indexing and client requests.
-
Uninstall the database driver modules you are not using; for example, if you are using
mysql
to use a MySQL-compatible database, you should be clear to uninstall thepgsql
(PostgreSQL) andsqlite
(SQLite) modules:composer exec -- drush pm:uninstall pgsql sqlite
Some modules presently have some bad expectations as to the system state when
hook_install()
is invoked and as such, some messages are emitted:
$ composer exec -- drush site:install --existing-config --db-url=mysql://user:***@localhost/db
You are about to:
* DROP all tables in your 'db' database.
Do you want to continue? (yes/no) [yes]:
>
[notice] Starting Drupal installation. This takes a while.
[notice] Performed install task: install_select_language
[notice] Performed install task: install_select_profile
[notice] Performed install task: install_load_profile
[notice] Performed install task: install_verify_requirements
[notice] Performed install task: install_settings_form
[notice] Performed install task: install_verify_database_ready
[notice] Performed install task: install_base_system
[notice] Performed install task: install_bootstrap_full
[error] The Flysystem driver is missing.
[warning] Could not find required jsonld.settings to add default RDF namespaces.
[notice] Performed install task: install_config_import_batch
[notice] Performed install task: install_config_download_translations
[notice] Performed install task: install_config_revert_install_changes
[notice] Performed install task: install_configure_form
[notice] Performed install task: install_finished
[success] Installation complete. User name: admin User password: ***
$
There are two "unexpected" messages there:
[error] The Flysystem driver is missing.
- Appears to be from the
flysystem
module'shook_install()
implementation where it tries to ensure that all schemes defined are in a state ready to be used; however, all the modules are not yet enabled (in the particular case,islandora
is not actually enabled, so thefedora
driver is unknown), and so leading to this message being emitted. Theislandora
module is enabled by the time the command exits, so this message should be ignorable.
- Appears to be from the
[warning] Could not find required jsonld.settings to add default RDF namespaces.
- Appears to be from the
islandora
module'shook_install()
implementation where it tries to alter thejsonld
module'sjsonld.settings
config object to add some namespaces; however, because the configs are not yet installed when installing the modules with--existing-config
, it fails to find the target configuration to alter it. As exported, thejsonld.settings
already contains the alterations (at time of writing), so this warning should be ignorable.
- Appears to be from the
In summary: These two messages seem to be ignorable.
If a patch (external or internal) is necessary, it can be applied automatically by composer by using the composer-patches plugin. Any patches included in the Starter Site should be described fully in this section (including when they should be removed).
- rest_oai_pmh - issue#3283661 - https://www.drupal.org/files/issues/2022-06-01/mods_view_render.patch is being applied to fix an issue related to getting view data into the MODS twig representation.
It is anticipated that Composer will be used to manage Drupal and its extensions, including Islandora's suite of modules. The Drupal project has already documented many of the interactions in this space, so we will just list and summarize them here:
Using Composer to Install Drupal and Manage Dependencies
-
The "install" describing:
- Composer's
create-project
command, which we describe above being used to install using this "starter site" project; and, - The
drush site:install
/drush si
command, described above being used to install Drupal via the command line.
- Composer's
-
"manage[ment]", describing:
- Composer's
require
command, used to add additional dependencies to your project - Updating, linking out to additional documentation for Drupal's core and modules:
Generally, gets into using Composer's
update
command to update extensions according to the specifications in thecomposer.json
, and Composer'srequire
command to change those specifications when necessary to cross major version boundaries. - Composer's
It is also recommended to monitor and/or subscribe to Drupal's security advisories to know when it might be necessary to update.
Further documentation for this ecosystem is available on the Islandora documentation site.
Having problems or solved a problem? Check out the Islandora Google Groups for a solution.
If you would like to contribute, please get involved by attending our weekly Tech Call. We love to hear from you!
If you would like to contribute code to the project, you need to be covered by an Islandora Foundation Contributor License Agreement or Corporate Contributor License Agreement. Please see the Contributor License Agreements page on the islandora-community wiki for more information.
We recommend using the islandora-playbook to get started.
For development of this starter site proper, we anticipate something of a particular flow being employed, to avoid having other features and modules creep into the base configurations. The expected flow should go something like:
-
Provisioning an environment making use of the starter site
- It may be desirable to replace the environment's starter site installation with a repository clone of the starter site at this point to avoid otherwise manually copying changes out to a clone.
-
Importing the config of the starter site
-
This should overwrite any configuration made by the provisioning process, including disabling any modules that should not be generally enabled, and installing those that should be.
-
This might be done with a command in the starter site directory such as:
composer exec -- drush config:import sync
-
-
Perform the desired changes, such as:
- Using
composer
to manage dependencies:- If updating any Drupal extensions, this should be followed by running Drupal's update process, in case there are update hooks to run which might update configuration.
- Performing configuration on the site
- Using
-
Export the site's config, to capture any changed configuration:
composer exec -- drush config:export sync
-
Copying the
config/sync
directory (with its contents) andcomposer.json
andcomposer.lock
files into a clone of the starter site git repository, committing them, pushing to a fork and making a pull request.- If the environment's starter site installation was replaced with a repository clone, you should be able to skip the copying, and just commit your changes, push to a fork and make a pull request to the upstream repository.
Periodically, it is expected that releases will be published/minted/tagged on the original repository; however, it is important to note that automated updates across releases of this starter site is not planned to be supported. That said, we plan to include changelogs with instructions of how the changes introduced since the last release might be effected in derived site for those who wish to adopt altered/introduced functionality into their own site.
A few modules are included in our require-dev
section but left uninstalled from the Drupal site, as they may be of
general utility but especially development. Included are:
config_inspector
: Helps identify potential issues between the schemas defined and active configuration.devel
: Blocks and tabs for miscellaneous tasks during developmentrestui
: Helper for configuration of the corerest
module
These modules might be enabled via the GUI or CLI; however, they should be disabled before performing any kind of config export, to avoid having their enabled state leak into configuration.