[MGNLDAM-498] Provide SEO friendly urls (for PDFs and other relevant files) Created: 07/Aug/14  Updated: 25/Aug/14  Resolved: 21/Aug/14

Status: Closed
Project: Magnolia DAM Module
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.0.3

Type: Improvement Priority: Critical
Reporter: Christian Ringele Assignee: Eric Hechinger
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
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)
Date of First Response:

 Description   

The current pattern the JcrAssetProvider of the DAM module are not SEO friendly for certain file types.
The path link is not containing the path of the asset node where it is located.
Only the UUID and the file name.

This is fine for images, as the URL is not SEO relevant for images.

But for other files it is, for example for PDFs.

It would be a great SEO improvement, if it could be defined for certain file types to have the links being created containing the path itself.

I suggested a way to achieve this for a customer's project here: http://jira.magnolia-cms.com/browse/SUPPORT-3856?focusedCommentId=89329&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-89329



 Comments   
Comment by Magnolia International [ 19/Aug/14 ]

We can add the path in the generated links (e.g http://localhost:8080/dam/jcr:7ecd4045-45a0-4c81-b2b6-f4c4b0cd24ad/mySite/some/folder/or/other/tramnetz.pdf instead of http://localhost:8080/dam/jcr:7ecd4045-45a0-4c81-b2b6-f4c4b0cd24ad/tramnetz.pdf.

Since the links are generated by the AssetProvider, any implementation could generate the links it wants. But it needs two things:

  1. the servlet needs to be able to tell which provider to use
  2. it needs to be able to figure out exactly which Asset to retrieve, so a path might not always be meaningful (think about Flickr as a dam provider, there are no paths)

The reason the links are the way they are is because we try to use one "source of truth" (the AssetKey, which is <provider-id>:<whatever-key-the-provider-users> and avoiding magic parsing in the download servlet.

That said, we need to re-establish a certain backwards compatibility, in particular with Dam 1.x; we could probably support the following link patterns:

  • /dam/jcr:7ecd4045-45a0-4c81-b2b6-f4c4b0cd24ad/<whatever, this is ignored anyway, so filename or path if that makes you happy>
  • /dam/static:7ecd4045-45a0-4c81-b2b6-f4c4b0cd24ad (compat with dms)
  • /dam/foo/bar/lol.pdf (compat with dam 1.x)
  • /dam/jcr/foo/bar/lol.pdf (so /dam/<provider-id>/<path>.ext: we ignore .ext and ensure that the corresponding provider is a PathAwareProvider
Generated at Mon Feb 12 05:00:26 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.