[META: ENHANCEMENT] Flexible Metadata Display Configuration for Enhanced Workflow and Version Control while preserving the current UI-editing Feature

[roromedia]

By introducing a setting to override metadata displays, such as a checkbox “Use file-based metadata displays,” and providing an absolute path to the relevant file, users can gain flexibility in how they manage metadata. Additionally, a separate textarea could allow users to add an include statement to the Twig file (e.g., {{ include '@theme/metadatadisplay_xyz.html.twig' }}), enabling both the use of the UI for content changes and the option to work in an IDE with full GIT-versioning support.

This setup could be applied globally within the Archipelago backend or on a per-Metadatadisplay basis. In “classic” mode, the UI would overwrite file-based metadata displays, ensuring compatibility with updates. Saving changes in the GUI would also update the underlying files, making them visible as modified in GIT. For having full control, the option to link save operations with file changes could be controlled through a separate setting.

[DiegoPino]

@roromedia I would need you to expand on this further. Most of our community users don't manage their own backends so this is very specific to having control over that, but also PHP won't have permissions at all to write on any @theme folder (very dangerous) and adding more moving pieces to an already very busy Metadata Display preview edit interface might add confusion. I wonder if rather having a sync from/sync to functionality (e.g from a folder, might be even a drush command) would make all easier and also an action you do during GIT push/version control management.

Please add more info so I can understand this better and also would be great to know how much of development time you/your group could volunteer if we act on this. Thanks a lot!

[roromedia]

@DiegoPino, I came up with this idea because I thought it could benefit others who make changes to Metadata Displays. Since the code can get quite extensive, using an IDE might sometimes be easier. To work around this, I currently do the following:

1) I create a file in the theme, like metadata_xy.html.twig 2) I include it in the UI editor with a simple {% include '@theme/archipelago/metadata_xy.html.twig' %}

On second thought, it might be even better to separate the metadata displays into their own module. That way, we could use the module’s namespace for the include, and we could store these files in a separate Git repository for version control (like any other module). If tagged, we could even add it as a private repo and use Composer.

For the UI, we could enable this feature with a global flag, like “Override UI metadata displays by module displays,” or let users enable it individually in the UI for each metadata display. When this option is checked, the module’s metadata display file would be included.

If others find value in this idea, it might be worth pursuing and investing resources. Otherwise, it may not be practical to dedicate capacity to a low-value feature.