Hello “Islandora Starter Site!" Later, "Defaults"!

112 views
Skip to first unread message

Rosie Le Faive

unread,
Sep 15, 2022, 11:58:10 AM9/15/22
to islandora
The Context For Having A Starter Site

Islandora Defaults was an optional module to get a site “set up” doing Islandora behaviors like derivatives and viewers. It was only ever meant to be a demo, or in practice, a starting point for configuring your own site to work as you like it. We needed something to do this because “islandora behaviors” often required a chain reaction of various things set up together.

Unfortunately, it was easily affected by external modules, got out of date quickly. Making changes to Islandora Defaults was beyond the capabilities of all but some very technical people, a level of gatekeeping that was unforeseen and absolutely never intended. It has also led to some misunderstandings that were the result of using Drupal’s “Features”. The Drupal “Features” interface implies that changing your code away from what is included in the Feature is a maintenance failure, when in fact that is what we hope sites do. The Features interface also allows you to load the config in code into your live database, implying that you can use this to receive “updates” including new features or functionality, when that was never intended with Islandora Defaults (and would destroy the careful customizations we hope you did). So we saw a huge benefit in stopping using Features. 

We’re therefore switching to a new thing we’re calling the “Islandora Starter Site”. The Starter Site sets up a new Drupal to have the same configurations as Islandora Defaults (launched via the Playbook) contained. It is no longer a Drupal Module, but is (as of now)

  • A Composer project that will be your Drupal root, specifying (among other things) all required Drupal modules and their versions

  • A folder containing a full Drupal site’s worth of configuration. In part, this includes the configs that used to live in Defaults (or very similar versions thereof).

  • A migration to import ‘tags’ just like in Defaults

Goals of the Starter Site
  • Demo the many features of Islandora. 

  • Be a starting point for creating a new Islandora site (expected: you’ll remove extraneous features, uninstall modules, add your own favorite modules, etc)

  • Serve as the location of collaboration for the community to solve common repository problems.

  • Require regular maintenance, but be easy to maintain.

What do I do with the Starter Site?

It is, as the name suggests, a starting point. You launch it, then customize your site until you’re happy with it. You may wish to use the structure of the Starter Site as an inspiration for doing (private) version control on the sites you’re maintaining. 

Can I get updates?

No. The site is yours once you launch it, meaning you can customize it to work the way you want. You should, of course, run the updates required for any Drupal site. 

You can replicate anything you see in the starter site on your own site, since it contains nothing but configuration for other modules. 

Installation

Shortly, the Starter Site will be an option on ISLE-DC and the Playbook. PRs are undergoing QA at this time. At the moment, there are manual install instructions in the README. 

Documentation

Lots of the Islandora Documentation contains references to Defaults, and we’re working on PRs for that too!

Sandbox

When it’s a little fuller-featured, we intend to use this as the Islandora Sandbox (at sandbox.islandora.ca). See the section below on Contributing Features.

Deprecating Islandora Defaults

When the site can be deployed in ISLE and the Playbook, we will deprecate Islandora Defaults. If you have Islandora Defaults, don’t uninstall it just yet (there are a few thorny configs that will remove themselves from your site!) (We’re working on a set of instructions). But don’t worry - having it around won’t hurt you. New sites, however, shouldn’t have Defaults.

Changes to Downstream modules

In the possible event that “downstream” Islandora modules (modules required by Islandora Starter Site) change the values of existing configuration that they ship with (i.e. edits to any Drupal configuration .yml file, usually they live within the config/install or config/optional directories), we need to be careful. 

Configuration changes are usually covered by the Drupal update hooks, but changes to default values that were already in place will not be reflected in the starter site, and configuration files that set up other entities (e.g. sample views, contexts, etc) will need to be replicated in the Starter Site. 

Contributing features to the Starter Site

The Starter Site looks a little bare-bones at the moment, especially compared to something like the Install Profile. Since the Starter Site is intended to be way easier to modify through PRs (and instructions are included in the README), I hope that the community can/will help contributing new features. I’d like to see some policy/guidelines just so that it remains maintainable, which I hope to work on with the community. A first draft is below:

Draft Contribution Policy for the Islandora Starter Site
  • Document all features including scope, expected behavior, and required modules.

  • Unless there’s a good reason, only include Drupal.org modules that have stable releases and are covered by the security advisory policy.

  • Code (including modules) must be installable through Composer. 

  • Use Semantic Versioning to require a module, allowing updates but pinning its major version (as suggested on Drupal.org) (unless there’s a good reason not to)

  • All modules included must be FOSS and have a license compatible with how we’re using them.

  • Try to avoid patches, but if necessary, document them

  • Modules should only be included in the project if they are active and configured to help with a documented feature.

  • Try to avoid redundancy by doing features one “way”. Do not set up or make available alternate “ways” if not used. Instead, document them.

  • Before merging, cross-test features with other aspects of the site. They should make holistic sense.

  • If features require new external services/libraries make sure ISLE/Playbook PRs happen simultaneously.

Reply all
Reply to author
Forward
0 new messages