Sorry starting writing this last sunday, but took quite some time and had to reflect a bit over it, so switched focus to the release stuff.
Anyway thanks for bringing this important topic up. We’ve discussed parts of this before when talking about structured editing and multi-site support, but haven’t taken any action to fix them yet.
In general the current implementation is broken by design and the concept is not generic since the whole thing is tightly coupled to a site, which happened for pragmatic reasons. We should come up with a solution where sites is just one example of a “bounded context” of the CR. There are many aspects in this to consider, so we should think things through before deciding on a path.
Decouple URL from the backend
One of the first thing to do is to decouple the front end URL from the backend. This will allow us to show any node from the CR and allow showing entities as well. Additionally it will allow viewing a site regardless of the domain, which is very useful for multi-sites. Either using the node identifier with a context string, e.g. 75a28524-6a48-11e4-bd7d-7831c1d118bc@user-admin;language=en_US or the full path. And then keep the uriPath accessible as a fallback and for flexibility & backwards compatibility.
This means the backend URL won’t be as “accessible” as before, but it will make it more robust and it’s the URL for the page could be displayed in the backend. A speaking URL should be an optional enhancement, not a requirement.
Domain
I found it odd that the current implementation accepts patterns, although potentially useful, it is currently not always working as expected and people get confused by it.
The only reason we need a host name is for linking from one site to another. In all other scenarios using the request for determining the URL should suffice for which the current solution works.
Now there are two ways of solving that problem. Either add a primary flag (canonical) as you suggest, which requires that it’s a host name and not a pattern. Or we make it possible to order them and the first one with a host name is used. We can easily display a warning if a site in a multi-site setup doesn’t have at least one domain with a host name.
I’m not sure which solution is best, but I’m leaning towards the priority one from a UX perspective and since it would fit the existing concept.
Btw. there’s already a ticket for adding a primary flag to the domain entity.
Removing site from context
The current implementation to determine the site in other places than the route part handler is indeed a pragmatic solution.
Option 2 sounds reasonable to me, but I’d like to get a better overview of what the content context actually helps with.
- Node linking?
- Could be determined using the node hierarchy instead with a fallback as suggested further up.
- Resource linking?
- Resource linking should be done relatively instead of using absolute paths (unless using a CDN ofc.)
- Node tree limiting?
- Node tree should be bound to a context and starting path, not a site, see related issue. Multiple trees can cater for different context needs.
- Node / asset search limiting?
- Currently these are limited by the viewed site, however if using a context with a starting path, the same could be used here.
So in general I think we should try to come up with a solution that doesn’t involve a site, but rather a flexible context that’s being parsed around (like in CR).
Maybe @radmiraal would be interested in chiming in, since he’s considering some scenarios similar to this.
Related to all this is the challenges about site specific configuration. Currently site packages has quite some built-in conventions, which might not be the optimal solution. But I’m entirely certain on this topic, so having some kind of concept brain storming would be great.
Actually there’s more to it than that, Flow in general doesn’t handle linking to different hosts. Here’s a ticket.
Sorry this isn’t a direct answer to your questions, but I think we need to think take a step back to be able to make the right decisions here.
Ps. while looking into this matter I found a site dependency in CR