TLD and default content dimensions

Hey guys,

a customer asked me if Neos could support/add the following feature:

The customer has the following domains in one Neos instance:

Currently we have a configuration like this:

ContentRepository:
  contentDimensions:
     'language':
        label: 'Language'
        icon: 'icon-language'
        default: 'de'
        defaultPreset: 'de'
          presets:
            'de':
               label: 'Deutsch'
               values: ['de']
               uriSegment: 'de'
           'en':
               label: 'English'
               values: ['en']
               uriSegment: 'en'
              constraints:
                 country:
                     'global': true
                     '*': false
           'fr':
             label: 'French'
             values: ['fr']
             uriSegment: 'fr'
            constraints:
               country:
                 'global': true
                 '*': false

   'country':
     default: 'global'
     defaultPreset: 'global'
     label: 'Country'
     icon: 'icon-globe'
     presets:
       'global':
         label: 'Global'
         values: ['global']
         uriSegment: ''
       'at':
         label: 'Östereich'
         values: ['at','global']
         uriSegment: 'at'
       'ch':
         label: 'Schweiz'
         values: ['ch','global']
         uriSegment: 'ch'

This leads to urls like this:

The target would be:

1 Like

I am not sure how a core implementation could look like it would have to be very flexible to support all possible use-cases. What i already did on some occasions already was adding some http-components that are manipulating the incoming url-path.

The following steps were required for my solution:

  • manipulate incoming urls to add the dimension path segments if they are missing
  • Manipulate the generated urls to take out the url-segments you want to hide. I aspected the LinkingService for that.

Make sure to do the above only in live context to avoid trouble in the backend.

What imho would make sense in the core would be a service that is responsible for encoding and decoding of the context. This could be used in the FrontendNodePartHandler and the LinkingService.

By creating an alternate implementation for such a contextEncodingService i think the above scenario could be implemented.

I am not sure how complicated such a solution would be and how the interface for the contextService would look like.

My idea would be to have yaml configuration like:

defaultDomainContentDimension:
  -
    domain: my-domain.de
    defaultContentDimemsions:
       language: de
       country: de
       uriSegment: ''
  -
    domain: my-domain.ch
    defaultContentDimemsions:
       language: de
       country: ch
       uriSegment: ''
  -
    domain: my-domain.at
    defaultContentDimemsions:
       language: de
       country: at
       uriSegment: ''

Based on this settings you could build the url. If a request is coming in e.g. from my-domain.ch it will be resolved to content dimension de_ch and works internally like it did before.

So this would be the steps you mentioned -> incoming mapping -> outgoing adjustment

The problem i see here is that while this is a very common problem the solution is not generic and will often require further adjustments. That is why i would prefer extracting the contextEncoding. That would make it possible to create the above as separate package.

The core would come with a simple basic solution like now that can be replaced with more sophisticated ones.

I think this is a very good idea!
I would contribute as much as I can to the separate TLD <-> ContentDimension package, so I have to find someone who would do the “context encoding” stuff in the core and can say how much the client has to invest for the core function.

I really like this idea and was already searching for sth. like this on some earlier projects.
Please contact me if you start any package to achieve the mapping as i would like to contribute as much as possible to get this done :tada:

Possible duplicate of:

Have you seen the other discussion already, @kapale ?

I think this one could be closed then.

1 Like