To discuss: extensions to Janeway core

[nuest]

Context

The geometadata plugin works entirely as a standalone plugin, but several enhancements
to Janeway's core would improve the integration and functionality. These are collected
here for discussion and potential upstream contribution to
openlibhums/janeway.

See also: Janeway Issue #1928

Proposed Core Changes

1. Hook for Article Sidebar/Detail Page

Current Limitation: The article_footer_block hook places content at the
bottom of the page. A dedicated sidebar hook would allow better placement.

Proposed Change: Add article_sidebar_block hook in article detail templates, low impact without breaking changes

Files to Modify:

• src/templates/journal/article.html
• Various theme article templates

2. Submission Workflow Step Hook

Current Limitation: No hook exists for plugins to add custom submission
workflow steps.

Proposed Change: Add plugin hook system for submission workflow, considerable impact:

• submission_step_<step_name> hooks
• Plugin registration for custom submission steps

Files to Modify:

• src/submission/views.py
• src/core/plugin_loader.py

3. Custom Fields Type Extension

Current Limitation: core.models.FieldType has hardcoded field types
without plugin extensibility.

Proposed Change: Allow plugins to register custom field types, considerable impact:

# In plugin_settings.py
CUSTOM_FIELD_TYPES = [
    {
        'name': 'geometry',
        'kind': 'text',
        'widget': 'geometadata.widgets.GeometryWidget',
    }
]

Files to Modify:

• src/core/models.py - FieldType model
• src/core/forms/fields.py - Field rendering

4. Metadata Export Enhancement

Current Limitation: Export formats (CrossRef, DataCite, Dublin Core) don't
include spatial/temporal metadata.

Proposed Change: Add hooks in metadata export, though is is not a trivial extension.

• export_crossref_metadata filter hook
• export_datacite_metadata filter hook

Files to Modify:

• src/identifiers/logic.py
• src/export/views.py

5. Search Integration

Current Limitation: No spatial search capability.

Proposed Changes:

1. Add bounding box search to article/preprint filters
2. Consider a geospatial index for advanced spatial search

Files to Modify:

• src/submission/views.py - Article list filters
• src/repository/views.py - Preprint list filters

6. Repository Metadata Page Hook

Current Limitation: No dedicated hook for preprint detail pages equivalent
to journal article hooks.

Proposed Change: Add consistent hooks across journal and repository, just an additive change.

• preprint_detail_sidebar
• preprint_detail_footer

Files to Modify:

• src/themes/*/templates/repository/preprint.html

7. Issue Page Footer Hook ✅ (implemented locally)

Current Limitation: No hook exists on issue landing pages (issue_display.html) for plugins to inject content below the article listing.

Proposed Change: Add issue_footer_block hook in all three theme issue_display.html templates. This is an additive, low-impact change — a single line per template, no breaking changes.

Change: Insert {% load hooks %}{% hook 'issue_footer_block' %} after the issue_block.html include and before the issue_paginator.html include.

Files to Modify:

• src/themes/OLH/templates/journal/issue_display.html
• src/themes/material/templates/journal/issue_display.html
• src/themes/clean/templates/journal/issue_display.html

Diff (same pattern for all three themes):

         {% include "elements/journal/issue_block.html" %}
+        {% load hooks %}{% hook 'issue_footer_block' %}
 
         {% include "elements/journal/issue_paginator.html" %}

Used by: The geometadata plugin registers an issue_footer_block hook to display aggregated temporal coverage and an interactive map of all article geometries on issue landing pages, plus a GeoJSON download link.

8. OAI-PMH Dublin Core Record Hook

Current Limitation: The OAI-PMH Dublin Core record template (src/templates/common/apis/OAI_record.xml) is a plain Django template with no hook point for plugins to inject additional <dc:*> elements. Dublin Core defines dc:coverage for spatial and temporal scope, which is exactly what the geometadata plugin would use. However, the template lives under templates/common/ and is not theme-overridable — a journal editor cannot add plugin-specific elements without forking the template and maintaining it going forward.

Background: The article object in the template context already exposes article.geometadata via Django's reverse OneToOneField, so a plugin could in principle add dc:coverage by overriding the template. But this is fragile: any upstream change to OAI_record.xml would require re-merging, and journal editors shouldn't need to maintain an OAI template just for one metadata field.

Proposed Change: Add a template hook inside the <oai_dc:dc> element in OAI_record.xml, allowing plugins to inject additional DC elements. Low impact, additive, no breaking changes.

      {% if article.page_range %}<dc:format.extent>{{ article.page_range }}</dc:format.extent>{% else %}<dc:format.extent>1</dc:format.extent>{% endif %}
+     {% load hooks %}{% hook 'oai_dc_record' %}
  </oai_dc:dc>

Files to Modify:

• src/templates/common/apis/OAI_record.xml
• src/templates/common/apis/OAI_preprint_record.xml (same pattern)

Used by: The geometadata plugin would register an oai_dc_record hook to emit dc:coverage elements with spatial (place name, bounding box) and temporal (date range) values, making geospatial metadata discoverable by OAI harvesters such as OPTIMAP without any template customisation by journal editors.

9. JATS XML Custom Metadata Hook

Current Limitation: The JATS 1.2 encoding template (src/templates/common/encoding/article_jats_1_2.xml) has no hook point for plugins to inject metadata. JATS supports <custom-meta-group> inside <article-meta> for exactly this purpose — arbitrary key-value metadata pairs that don't fit the standard JATS vocabulary. However, like the OAI template, the JATS template is a shared core file. Expecting journal editors to override and maintain a 190-line XML template just to add a <custom-meta> element for one plugin is unrealistic — the maintenance burden would compound with every upstream update to the template.

Background: Geospatial metadata has no dedicated JATS element, but <custom-meta-group> is the idiomatic extension point. The Crossref schema (5.4.0) similarly has no spatial coverage elements, so Crossref deposits are not a viable integration path at this time.

Proposed Change: Add a template hook inside <article-meta>, after the existing content (keywords, funding) and before the closing </article-meta> tag:

          {% endif %}
 
+         {% load hooks %}{% hook 'jats_article_meta' %}
      </article-meta>
  </front>

This allows plugins to inject <custom-meta-group>, <supplementary-material>, or any other valid <article-meta> children without touching the core template.

Files to Modify:

• src/templates/common/encoding/article_jats_1_2.xml

Used by: The geometadata plugin would register a jats_article_meta hook to emit:

<custom-meta-group>
    <custom-meta>
        <meta-name>spatialCoverage</meta-name>
        <meta-value>Vienna, Austria</meta-value>
    </custom-meta>
    <custom-meta>
        <meta-name>temporalCoverage</meta-name>
        <meta-value>2020-01-01/2021-12-31</meta-value>
    </custom-meta>
</custom-meta-group>

This makes geospatial/temporal metadata available to any system consuming JATS XML (repositories, archives, indexers) while keeping the core template maintainable. Other plugins could use the same hook for their own custom metadata fields.

[nuest]

A work in progress for these changes used on the KOMET demo server is in branch https://github.com/GeoinformationSystems/janeway/tree/1928-geometadata-plugin

openlibhums/janeway@master...GeoinformationSystems:janeway:1928-geometadata-plugin

[nuest]

Press navigation hook for map page link

The plugin's nav_block hook adds a "Map" link to journal/repository navigation, but this hook is only triggered within a journal or repository context. When viewing the press landing page (e.g., http://example.com/), there is no automatic link to the press-wide map at /plugins/geometadata/press-map/.

Current workaround: Manually add a link to the press theme template (documented in README).

Proposed enhancement: Register a press_nav_block hook (or similar) to automatically add a "Map" link on press pages when the press-wide map is enabled and has data. This would mirror the existing nav_block implementation but check for press-level settings and aggregate data across all journals/repositories.

This may require a corresponding Janeway core change to add a press_nav_block hook point in press templates, similar to how nav_block exists for journal templates.