[MGNLRES-179] Migrate all resources from templates to resources Created: 14/Jul/15  Updated: 29/Mar/22  Resolved: 26/Oct/15

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.2

Type: Story Priority: Critical
Reporter: Magnolia International Assignee: Philip Mundt
Resolution: Fixed Votes: 0
Labels: requires_documentation
Σ Remaining Estimate: 0d Remaining Estimate: 0d
Σ Time Spent: 3d 3.25h Time Spent: 3d 3.25h
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLRES-233 Users should have a way to enable/dis... Closed
relates to MGNLINTEMPL-77 Migrate installed templates to the 'r... Closed
causality
caused by MAGNOLIA-6214 FreeMarker template scripts should be... Closed
caused by MAGNOLIA-6128 Introduce uniform resource loading API Closed
is causing MGNLRES-273 TemplateMigrationTask will create res... Closed
dependency
is depended upon by MGNLINTEMPL-83 Remove legacy in-place templating "Te... Closed
is depended upon by MGNLRES-227 Remove module descriptor dependencies... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLRES-220 Remove install tasks from several mod... Sub-task Closed Federico Grilli  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Epic Link: Phase out in-place templating app
Sprint: Basel 17
Story Points: 13
Team: Nucleus

 Description   

Timebox: 2 days
After this timebox, we should have at least follow up stories.
Additionally it would be good to have an understanding of how we can actually implement it with validated corner cases.


With MAGNOLIA-6128 and MAGNOLIA-6214, FreeMarker templates are now loaded from the Resources API and thus the resources workspace. Somehow we did not "finish" everything in this regard.

If one upgrades to 5.4, and freemarker config wasn't customized, templates will be loaded solely via resources API - so it's pretty confusing to have an app that lets one edit the"templates" workspace, but never gets used.

I'd suggest the inplace-templating module is now unnecessary:

This issue obviously needs to be replicated in MGNLINTEMPL; issues from MGNLINTEMPL might need to be moved to MGNLRES (some are probably redundant)



 Comments   
Comment by Philip Mundt [ 17/Sep/15 ]

Templates from templates workspace have the following properties:

  • autoImport (Boolean defaults to true) (when true, contents were overwritten by an install of a new version: automagically solved by origins...)
  • enabled (Boolean) (activate template from workspace – as suggested above, use as "flag" to install into new resources workspace)
  • text (String) (contents of file)
Comment by Mikaël Geljić [ 18/Sep/15 ]

All fine to remove install tasks on 5.4, but careful about 5.3:
If I remember correctly, we actually need to install templates so that they're seen by the system (goes through URI2RepositoryMappings), even if in most cases we actually just want to bypass them. (Maybe worth verifying though).

Comment by Mikaël Geljić [ 18/Sep/15 ]

We need a proper flow diagram on how to react to various cases:

  • autoImport
    • true:
      • delete?
      • only if also present via ResourceOrigin?
      • comparing changes and warning if needed
        • at later point in time (general resource sanitization task)
    • false:
      • migrate to resources ws?
      • make sure potential versions come along
      • what if there's already a "hotfix" in there?
  • manually created templates (JCR-only)
  • extension: should always be assumed to be .ftl? (add if not there)
    • info.magnolia.module.inplacetemplating.setup.TemplatesInstallTask has "flag" to stripExtension (since 2008)
    • info.magnolia.module.resources.setup.AbstractInstallResourceTask has the stripExtension flag since 2014. Default was always–and still is–true if not specified.
      • same goes for subclass info.magnolia.module.resources.setup.InstallBinaryResourceTask
      • same goes for subclass info.magnolia.module.resources.setup.InstallResourceTask
    • deprecated info.magnolia.module.resources.setup.InstallResourceTask has been stripping extension from the first day (2009).
  • enabled: that property has actually correct naming (vs. resources' bypass property)
    • so we would migrate this property "as is"
    • we should instead rename bypass (into enabled) for all resources (see TODO in JcrResourceOrigin)
    • support both bypass and enabled in JCR origin (precedence to the latter if needed).

Side note:

  • new ResourcesServlet (and underlying JcrResourceOrigin) don't have any fancy handling of extension

Besides, if we actually do cleanup w/ templates that do not need to be installed anymore, how about doing that for installed resources too? (out of consistency)

More questions:

  • Lack of common model for resources (already pointed out while implementing new app)
  • How does inplace-templating resolve scripts and extension, via URI2RepositoryMapping (they're typically configured w/ extension, and stored without) FTL-only? Similar question for resources.
    • inplace-templating: info.magnolia.module.inplacetemplating.JcrRepoTemplateLoader configures the extension to be .ftl and actually implements freemarker.cache.TemplateLoader – we can indeed assume that templates are ftl templates.
      Templates were never stored with the extension (in the nodename)!
    • resources: all within info.magnolia.module.resources.mapping.URI2ResourcesRepositoryMapping, will only find nodes without extension (actually disregards extension entirely; doesn't check any extension property).
      seems that if a node matches the URI "handle" directly (with extension), it's not even gonna pick it up!
  • How far do we go w/ trying to match files vs. nodes, given the extension inconsistencies?
Comment by Philip Mundt [ 05/Oct/15 ]

†emplates workspace:

Does not contain any information about the extension. Shall we always consider ftl?

/mte/templates/pages/main
/mte/templates/pages/main/autoImport=true
/mte/templates/pages/main/text=CONTENT
/mte/templates/pages/main/enabled=false

resources workspace:

Contains information about the extension depending on the type.

mgnl:template available by default (using any *ResourceTask:

/sample-css
/sample-css/text=CONTENT
/sample-css/mgnl:template=resources:processedCss

extension property for binary resources (installed using info.magnolia.module.resources.setup.InstallBinaryResourceTask)
When using the InstallBinaryRT, only images contain the jcr:mimeType property!

Examples via resources-app upload:

  • Binary (image)
    /earl-randy.gif
    /earl-randy.gif/binary
    /earl-randy.gif/binary/extension=gif
    /earl-randy.gif/binary/jcr:data=<binary>
    /earl-randy.gif/binary/jcr:mimeType=image/gif
    
  • Binary (non-image)
    /untitled.zip
    /untitled.zip/binary
    /untitled.zip/binary/extension=zip
    /untitled.zip/binary/jcr:data=<binary>
    /untitled.zip/binary/jcr:mimeType=application/zip
    
  • Text
    /untitled.txt
    /untitled.txt/text=<whatever text>
    
Comment by Philip Mundt [ 06/Oct/15 ]

Template migration procedure

  • autoImport set to true?
    • Check ResourceOrigin a) 1:1 filename, b) add extension
      • Yes (exists)
        • Delete template
      • No (does not exist)
        • Migrate to resources
  • autoImport set to false?
    • Check if there a hotfix (withing JcrOrigin + ext)
      • Yes
        • Fail and log
        • Optionally compare text
      • No
        • Migrate to resources
        • Migrate versions
Function "Migrate to resources":
  • Migrate text property as is
    • (text resource in resource WS have exactly the same)
  • Migrate enabled
  • Migrate templateNodeName + ".ftl" as NEW resource nodename
    • Read extension from configured info.magnolia.module.inplacetemplating.JcrRepoTemplateLoader ?
      • obsolete, already removed as of 5.4, replaced by info.magnolia.freemarker.loaders.ResourceTemplateLoader
    • Official ext is ftl; fm used to be option
Comment by Philip Mundt [ 22/Oct/15 ]

Re-opening due to changes in actual migration-process

Generated at Mon Feb 12 06:48:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.