Story #46526

Work Package #45217: [WIP][Assignee missing] External & internal link support

Media/Scheme aware URL handler

Added by Adrian Föder over 8 years ago. Updated over 8 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:


At least as soon as editors should be able to link arbitrary elements via Neos, it comes up that the various target possibilities are currently hard to distinct. In Flow and Neos, there are resources, there are (controller-) actions, there are nodes, and of course there is still the need to link to a typical URL like http:// and mailto:.

Especially the Resource, Action and Node links will result in a different "output" then their meaning representation; a Resource is a hash, resulting in the frontend-published URI; an action consists of package, controller, action, argument.. values, resulting in an URI-builder-built url.
And the node is represented by its path or identifier, resulting also in a web-accessible http url.

So, see the following examples:

  • node:///sites/exampleorg/home/welcome/some/section/with/stuff Could even result into
  • resource:///348fb109a2098234b23498 Would result into the frontend-published resource
  • media-resource:///348fb109a2098234b23498?width=500&height=800 Would provide a scaled image
  • action:///acme.package?controller=sample&action=create&arguments=.....

This is what just came in my mind and of course these are just suggestions and need to be checked
against current requirements...

Basic implementation idea

For implementing kind of this, I'm thinking about a service, where various schema implementers can hook in. Neos, for example, would then bring its own NodeSchemaImplementer (?), TYPO3.Media could provide an implementor which allows also scaling an (image) resource (like IMG_RESOURCE).
Flow on it's very own of course brings an MvcActionSchemaImplementer (?) (I'm just throwing around with name suggestions which helps me to understand what I mean ;)

I think these schemas schouldn't have anything to do with the StreamWrapper because that's more an internal PHP thing. "Our" schema here is "just" a naming convention to transpose a stringly given resource locator to its actual representation.

Locate TYPO3CR nodes

Since nodes can be moved around, it sounds making sense to use the node identifier. However, as far as I got it, the node identifier can be pretty "volatile" in regards of workspaces, etc.

But still, in order to be able to keep old "links" updated in case their nodes are moved around, their paths would need to be updated. This could only be done by something like a Refindex, and is likely also not very nice... What do you think on the long run?

Related issues

Related to Base Distribution - Story #45973: As a content editor I want improved image handlingClosedAdrian Föder2013-05-08


Updated by Adrian Föder over 8 years ago

What do you think about registering an appropriate scheme at the IANA, a so called "Provisional URI Scheme" (see

The scheme is the very first part of an URI, for example in mailto: or svn://something, the "mailto" and "svn" are the schemes.

With introducing a broader user circle, that scheme name could even be "typo3", with various defined sub namespaces then, just like "typo3:cr:node:/sites/exampleorg/home/welcome".
Just a basic idea, a "sub registration proces" could then be made on Association base.

Also available in: Atom PDF