[MAGNOLIA-6626] Generated links do not have always the same format Created: 11/Apr/16  Updated: 23/Feb/18  Resolved: 23/Feb/18

Status: Closed
Project: Magnolia
Component/s: rendering, templating components
Affects Version/s: 5.4.5
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Mercedes Iruela Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: blocked, support
Remaining Estimate: 3.5d
Time Spent: 1.5d
Original Estimate: 5d

Issue Links:
Relates
relates to MGNLETK-28 multi-site support: fixing various is... Closed
relates to MAGNOLIA-5292 Make Magnolia respond to only registe... Closed
causality
dependency
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: Align references and links implementations
Story Points: 8

 Description   

Links generated by LinkUtil.createLink(node) should end up with the same link pattern always. It would not matter if the link is to a root page or a child one. Links should respect the pattern defined at /server@defaultExtension.

For example, in Demopublic. You can see that generated link to root page in the header (magnolia logo) is generated to href='/' and the rest of the links are generated to '/*.html'. This happens when the generated link points to a site definition root node.

Changed link render manager from MultiSiteLinkTransformerManager to LinkTransformerManager and works in the same way.



 Comments   
Comment by Mikaël Geljić [ 06/Dec/16 ]

So, I got some pointers and skimmed through those tickets re: "strict extensions":

  • Historically we were advising to do it with a custom filter
  • Then I also found the property you had were referring to:
    • first as ImagingServlet#validateFileExtension (MGNLIMG-115)
    • then reverted and moved to ContentTypeFilter as #validateContentType + #registeredExtensionsOnly. See MAGNOLIA-5292 for details.

It is in fact documented at https://documentation.magnolia-cms.com/display/DOCS/MIME+type+mapping, was just not quite an easy find

oanh.thai can we confirm whether it solves the client's request?

Comment by Mikaël Geljić [ 06/Dec/16 ]

... and (couldn't resist) actually it does not prevent accessing the page:

  • if defaultExtension is configured as empty and one appends .html or /,
  • if defaultExtension is html and one removes extension or add /

Access is only prevented if extension is undeclared or incompatible MIMEtype-wise.
Now question is: SEO tools typically crawl for links, so configuring those 3 properties appropriately shouldn't point to the unwanted "url variants". miruela, could this alleviate the issue meanwhile?

Comment by Mercedes Iruela [ 23/Feb/18 ]

Closed because the behavior cannot be reproduced again.

Generated at Mon Feb 12 04:16:18 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.