Work Package #45217
[WIP][Assignee missing] External & internal link support
| Status: | New | Start date: | 2013-03-22 | ||
|---|---|---|---|---|---|
| Priority: | Should have | Due date: | |||
| Assigned To: | - | % Done: | 50% |
||
| Category: | - | Spent time: | - | ||
| Target version: | 1.0 beta 1 |
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
Related issues
History
#1 Updated by Sebastian Kurfuerst over 2 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 over 2 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 about 2 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 about 2 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 about 2 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 almost 2 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