Content Dimensions and TLDs

Using Neos & Flow
#1

Hi!

Through searching the forum I can see, this topic is as old as NEOS is. But I found only threats which are a few years old.

My wish is to use Content Dimensions (de, fr, en_UK, en_US and so on) with individual top level domains.

I can’t find recent publicated information to this topic. Is it currently and furthermore the best practice to work with one TLD and language token like

mydomain.com/de/
mydomain.com/fr/
mydomain.com/en-us/
mydomain.com/en-uk/

… and so on? Like it is also in other well known systems, or is there in meanwhile a special feature in NEOS?

Kind regards,

Maximilian

#2

Hi,

not without a plugin, but there was this discussion RFC: Domain based content dimensions

And this Flowpack package https://github.com/Flowpack/neos-dimensionresolver

1 Like
#3

I had a similar usecase. I created a “Base” application, containing all design, assets and nodetypes, and then a package per tld.

  • Website.Denmark (for .dk domain)
  • Website.Sweden (for .se domain)
  • Website.International (for .com domain)

And the root fusion included the Base fusion. Set the HTML lang attribute and move on :slight_smile:

Deploy new package, site and domain and we were running :slight_smile:

#4

Hi @sorenmalling

Thanks for you reply. This would be an option, off course. Basically this means you’re not working with dimensions, right?

Did you can work with language fallbacks this way? What’s with general content? Like global categories? Do you would have to create a new category for every single site separate / redundant?

In my case I have to build a page, where one language has the main / base content and the other languages have to working as much as possible automatically.

#5

Correct, no dimensions configured at all. Separate trees, sharing nodetypes and design.

No fallbacks - only the content present in the sites tree. This means, that you don’t automatically have a “map” on one domain to a page in antoher tld. (think language menu)

Everything created for that specific market, as content would vary.

#6

If you want fallbacks etc. check out the package I mentioned.
It is probably the solution that fits better.

There was simply not enough interest from the community yet to integrate the functionality into the core.

#7

I will test it @sebobo

Anyhow it’s great that there is a package for this use case at all, even it’s not a core feature.