Remove Feature-ness of Islandora Core Feature.

[rosiel]

GitHub Issue: #902 (comment)

• Other Relevant Links (Google Groups discussion, related pull requests,
  Release pull requests, etc.)
• Discussed at Aug 2's Tech call

What does this Pull Request do?

Removes the "Feature"-ness of islandora core feature.

What's new?

• It should not show up in the Features list
• It should not consider the config as part of a feature already

How should this be tested?

Does it install properly, and still install the needed configs?
Does it update okay on existing sites?

Documentation Status

• Does this change existing behaviour that's currently documented?
• Does this change require new pages or sections of documentation?
• Who does this need to be documented for?
• Associated documentation pull request(s): ___ or documentation issue ___

Additional Notes:

Any additional information that you think would be helpful when reviewing this
PR.

Interested parties

@seth-shaw-asu

[rosiel]

I don't know if we can proceed. The error now is:

 In PreExistingConfigException.php line 65:
                                                                               
  Configuration objects (field.storage.media.field_media_audio_file, field.st  
  orage.media.field_media_document, field.storage.media.field_media_image, fi  
  eld.storage.media.field_media_video_file, filehash.settings, rest.resource.  
  entity.node) provided by islandora_core_feature already exist in active con  
  figuration   

This seems to imply that we can't both install from existing config and load modules with their own config.

[seth-shaw-asu]

We need to move the configs from config/install to config/optional. The optional directory allows them to be installed if they don't exist but ignored if they do.

[rosiel]

Does that leave the "core feature" with a useful reason for existing?

Noting that with the standard install profile and/or installing required modules like filehash, those configs will always already be installed so the version in the "core feature" - with our islandora stuff - will be ignored. The Starter Site installs versions of all these configs, so the core feature won't come into play there either.

Maybe we should examine what's in this folder and trim out what's not useful in a standard install?

[seth-shaw-asu]

Does that leave the "core feature" with a useful reason for existing?
...
Maybe we should examine what's in this folder and trim out what's not useful in a standard install?

If we ever want to let someone install islandora on an existing Drupal site (like I did for UNLV), that config needs to be installable on it's own. That said, we could add it directly to the islandora module's config, instead of using a separate "core" config module.

[rosiel]

If someone were installing on an existing drupal, they'd already have - so would skip - a big chunk of the config that we considered "core". This includes messing with existing media types. Would they (a) be informed that they're skipping some config as it already exists, and (b) have a recourse option to install the skipped configs if they so desire?

[seth-shaw-asu]

I guess that depends on the definition of core; which admittedly is a conversation with a long and sometimes difficult history as I'm sure you recall. How much should a site be handed when they install the core module? This is why we broke out islandora_defaults from islandora oh so long ago. The config that remained in islandora_core_feature are there because we make code references to them.

Field storage configs are a good example because we make several code references to 'field_member_of' but a site can choose to add the field it to their content type or not. We need these particular configs that are in core on every site or things blow up. Beyond that how to implement islandora on their site in terms of what content types will include islandora-provided fields, what taxonomy and terms they add, etcetera, becomes their choice. Good documentation of that, of course, is important.

[seth-shaw-asu]

Another thought on this line:

a big chunk of the config that we considered "core".

I think this conflates "core" with "standard". Again, the division between islandora/islandora_core_feature and islandora_defaults (which is now supplanted with the starter site) represents this same division. The config in islandora_core_feature is what I consider "core" (those things code requires to exist) and the starter site (formerly islandora_defaults) I consider "standard" (what we expect most sites will want to build with it).

[rosiel]

Questions from the tech call:

• are all these configs really "core"?
• how to deal with the ones that you probably already have?
• remove enforced dependencies on core feature module

Testing note: make sure this doesn't break an existing site.

[seth-shaw-asu]

I can't get the PR's patch to apply to 2.x:

~/islandora-pr$ git status
On branch 2.x
Your branch is up to date with 'origin/2.x'.

nothing to commit, working tree clean
~/islandora-pr$ git apply ../islandora-968/968.patch
error: patch failed: .github/workflows/build-2.x.yml:53
error: .github/workflows/build-2.x.yml: patch does not apply

[rosiel]

@seth-shaw-asu that was because we already changed our workflows to use the 3.x branch instead of the 2.x branch of the checkout and other actions. I've rebased this feature branch onto islandora's 2.x branch so the patch applies now (I tested, it seems to work). And I learned how to do pull requests as patches, which is cool!