Work Package #45217

[WIP][Assignee missing] External & internal link support

Added by Sebastian Kurfuerst almost 9 years ago. Updated about 8 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
-
Target version:
Start date:
2013-03-22
Due date:
% Done:

50%

Estimated time:
(Total: 0.00 h)

Description

External & internal link support

  • Target Audience: users who want to link between pages or want to check link status
  • Responsible: XY
  • Implemented by: XY, YZ
  • Amount: XY work days
  • Version: for 1.0
  • Planned Implementation Timeframe: X - Y

Motivation

Linking to internal and external resources is a key feature of any CMS and are fundamental to the WWW. As such, providing easy to use and convenient support for linking is simply a must have.

Goal

Linking to internal resources should be very easy, possibly using some link wizard / browser. Links to internal resources should never break; if targets are moved or deleted, links should adapt automatically. For links to external resources some checking would be nice to have, so dead links can be detected. Links to the site (from the outside) should be maintained as good as possible as well - if a page is moved a redirect should occur instead of a 404 - and if pages are deleted providing a proper 410 response is advisable.

Deliverables

  • Link plugin for Hallo / Aloha
  • Update Aloha Integration
  • redirect management for moved pages
  • page removal results in 410 being sent
  • outbound link checker
  • 404 logging for incoming requests

Subtasks

Story #46526: Media/Scheme aware URL handlerNew2013-03-22

Actions
Task #48291: Redirect management for moved pagesAcceptedTim Kandel2013-05-16

Actions
Task #48365: Support editing basic external links with AlohaResolvedSebastian Kurfuerst2013-05-17

Actions
Task #48366: Support editing internal links with AlohaResolvedBastian Waidelich2013-05-17

Actions
#1

Updated by Sebastian Kurfuerst almost 9 years ago

  • Subject changed from [WIP] well-working link support to [WIP][Assignee missing] well-working link support
  • Target version set to 1.0 beta 1
#2

Updated by Karsten Dambekalns almost 9 years ago

  • Subject changed from [WIP][Assignee missing] well-working link support to [WIP][Assignee missing] External & internal link support
#3

Updated by Bastian Waidelich over 8 years ago

some initial thoughts/questions:

  • use protocols for internal links!? (resource:// for resources, page:// for TYPO3CR page nodes?)
  • use persistence_object_identifier, identifier or path to reference nodes?

I can think of four ways to create (page) links:

1. Referencing the node path

Lorem <a href="page://sites/somesiteorg/the/page/path">ipsum</a> dolor sit amet

+ one can determine the target page from reading the source!
+ easy to implement
- if the page path or the site changes we need to iterate through all nodes & deserialize the properties

2. Referencing the node identifier

Lorem <a href="page://02f9fcb6-95ac-61a5-ba6f-e41705ca6d48">ipsum</a> dolor sit amet

+ easy to implement
- if the page is (about to be) removed we need to iterate through all nodes & deserialize the properties

3. Using a links property in node containing the link

Lorem <a href="link://123">ipsum</a> dolor sit amet

and a property links with a value of (s.th. like):

...
123:
  node: 02f9fcb6-95ac-61a5-ba6f-e41705ca6d48

+ a bit easier to find and adjust links
- if new properties are added to the link relations (e.g. status, ...) all existing nodes must be updated

4. Using a links table

Lorem <a href="link://5d5c95ee-6f39-6234-6b29-0778e04f09d6">ipsum</a> dolor sit amet

+ easy to find and adjust links
+ extensible (new properties can be added to the links table)
- integrity of relations must be ensured

#4

Updated by Sebastian Kurfuerst over 8 years ago

I'd opt in for 2 or 4. :-)

And maybe we need to use <a href="...." data-target-node="[uuid here]"> to make links directly working when they are inserted through Aloha...

Greets, Sebastian

#5

Updated by Adrian Föder over 8 years ago

Bastian, were you aware of #46526, too? I think `page://` and/or `link://` will soon lead into trouble because it lacks extensibility and especially is subject to collisions.

#6

Updated by Bastian Waidelich over 8 years ago

Adrian Föder wrote:

Bastian, were you aware of #46526, too? I think `page://` and/or `link://` will soon lead into trouble because it lacks extensibility and especially is subject to collisions.

Thanks for the heads-up. The examples were just foo bar, but I wasn't aware of the issue!
I don't think extensibility is an issue, but maybe we should use some kind of namespace to avoid collisions

Also available in: Atom PDF