MIR-1343 Do not render mir-admindata-box staticly

[Possommi]

MIR-1343 and MIR-1341

requires MyCoRe-Org/mycore#2215 to render the dates properly

[Possommi]

@toKrause should MIR-1341 included in this PR?

[toKrause]

@toKrause should MIR-1341 included in this PR?

Would be okay for me and make things easier, organizationally.

[toKrause]

Code looks okay and I've tested the modified feature in my development system.

One thing needs to be considered: Once the changes in this PR are applied, already existing statically cached content (that still contains HTML) is unsuitable to be rendered with the updated style sheets. It will look something like this:

After any change, the newly created statically cached content (that now contains XML) works fine. It will look something like this:

Since this PR targets the LTS branch, some migration strategy has to be devised and implemented. Ideally, one, that is going to be performed automatically.

What are your plans here?

Once a migration strategy has been devised and implemented, I will approve this PR.

[Possommi]

Code looks okay and I've tested the modified feature in my development system.
[...]
Since this PR targets the LTS branch, some migration strategy has to be devised and implemented. Ideally, one, that is going to be performed automatically.

What are your plans here?

Once a migration strategy has been devised and implemented, I will approve this PR.

[1] Executing repair metadata search of type mods would update all static content.

[2] Alternatively I could add a check in mods-metadata-page.xsl

<div id="modalFrame-body" class="modal-body">
  <xsl:choose>
    <xsl:when test="$originalContent/div[@id=$boxID]/table">
      <xsl:copy-of select="$originalContent/div[@id=$boxID]/*"/>
       ...
      <xsl:otherwise>     
        <xsl:apply-templates select="$originalContent/div[@id=$boxID]/*" mode="history-modal"/>
      ...
</div>

I do prefer [1] although [2] requires no additional user actions after upgrading to the new LTS.

[toKrause]

Version [1] would certainly be simpler and would be okay (if documented in the migration documentation), if this PR would target the main branch, but since this PR targets the LTS branch, there really should be no manual migration step.

So, version [2], if I understand it correctly, wold render an old static file in the old way and a new static file in the new way. I don't think that is a desirable solution, since it would be unclear users why the history (seemingly on a random basis) has a different behavior for different objects.

I think a solution should be invented, that automatically creates the missing/unfit static data for in the new way if no/old static data is found.