TLD and default content dimensions

Creating Neos & Flow
1

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
2

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.

3

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.

4

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

5

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.

6

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.

7

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:

8

Possible duplicate of:

Have you seen the other discussion already, @kapale ?

I think this one could be closed then.

1 Like