consider moving the Bundle to the CMF org

[lsmith77]

I would be open to moving this Bundle to the CMF org. At first I thought it might even be integrated into the RoutingBundle, but as it requires the RequestStack, which requires 2.4, I guess its better to keep it separate.

what do you think?

/cc @dbu @dantleech

[dantleech]

So I understand what this about, what is the use case?

[hacfi]

@dantleech Have a look at symfony-cmf/routing-bundle/pull/156

[EmmanuelVella]

@lsmith77 It also requires the expression language from sf 2.4

[dbu]

i am +1 to move this to the cmf organization. i guess we should target the 1.3 release and not the upcoming 1.2 to integrate it in a demo and the doc, so we have some time to review it and clean it up.

i think its good to keep it separate. RoutingBundle is quite complex already, and multidomain is a specific requirement not everybody has. i think @ElectricMaxxx could have some inputs here as well, as he is doing a multidomain site if i am not mistaken.

being on holidays, i don't have time to examine this bundle in detail - but i think we should give it a good review and see to it that things play well together (e.g. when combining language by domain name with multidomains, where you would have groups of domains that represent the same site in different languages. this should at least be feasable if not supported outright.)

[ElectricMaxxx]

Yea @dbu you are right.
Will try to have a look at the weekend. I am nearly ready with my project and will run 3 different portals out of one backend in the end of september (before i will leave Company+project). But i am very interessted in that bundle and its aproach/solutions.

[ElectricMaxxx]

Ohh yea that's the idea i should have had some month ago:
https://github.com/M4nu/MultiDomainBundle/blob/master/DependencyInjection/Compiler/OverrideRouteBasepathsCompilerPass.php#L12-L30
instead of (re-) creating an own route provider and filter, new route candidates are use, that's nice. Cause implementing an own provider causes many issues (forgot some stuff).

[EmmanuelVella]

If you think this bundle is ok, I can reorganise/rename it in order to move it to the CMF org. Here are some name proposals :

• symfony-cmf/RoutingMultiDomainBundle
• symfony-cmf/MultiDomainBundle

Or with host (closer from the routes host attribute)

• symfony-cmf/RoutingMultiHostBundle
• symfony-cmf/MultiHostBundle

[hacfi]

I like symfony-cmf/RoutingMultiHostBundle

[EmmanuelVella]

symfony-cmf/MultiHostRoutingBundle is also possible. However, maybe the bundle won't be limited to routing, so I'm not sure including Routing in its name is a good idea.

[lsmith77]

+1 for symfony-cmf/RoutingMultiHostBundle

[dbu]

If we just call it MultiHostBundle it could be used for things not directly related to routing. Are there any non-routing things to consider?

[ElectricMaxxx]

+1 for symfony-cmf/MultiHostBundle trust me, there will be more tasks then "just" routing, like:

• content in different representations per host
• different route strategies for each host
• ...

[ElectricMaxxx]

especially the new RoutingAutoBundle will got lots of new interesting tasks. Currently doing that with an fancy, crazy listener.

[dantleech]

Do we have any concrete use cases? It would be a shame to call it MultiHostBundle only to find out later that it is only Routing. (e.g. "differnet route strategies per host" sounds like routing :)

RoutingAutoBundle is very much only Routing.

[dbu]

different templates per domain would be a quest for some "theme" bundle. i think there already are some theme bundles for that.
but there could be access control or publication workflow things maybe? or something to help with multidomain menues? like i can just ask for a menu and get either the site specific menu or a fallback menu?

[dantleech]

For the last usecase I would really like to see some sort of cascading node locator. e.g.

/cms/sites/mysite/sites/subsite/template/foo.html.twig
/cms/sites/mysite/template/foo.html.twig
/cms/global/template/foo.html.twig

But I don't think that belongs to multi-host ...

[ElectricMaxxx]

@dantleech there are possible solutions for every usecase to do it that or the other way. But as you can see, there are many tasks for such a bundle - not only routing. All three types of our /cms tree are afected. You can have different representations for menu, routes and content. And should have some fallback handling for all.

[dantleech]

I am proposing a cascading node resolution service to handle that use case. But such a service is not about hosts, it is a generic service for which hosts would be just one way to resolve the resource. It would also work in a single-host situation or a single site where, for example, you want to fallback from one node to another.

[dbu]

hm, i see. now you talk about this, we do this by hand in a couple of places on liip.ch, most notably the headers (see if content has a header child, otherwise render default header). i am not sure how hard or easy it will be to provide a generic solution for that (given that a non-generic solution is rather easy to do). but even if we do that, one fallback path could be based on the host, so that part could again be in here.

and what about preventing content limited to a specific domain from being shown on a different domain? i think publication workflow / access control would be a good approach to that, so we could add the corresponding voters here.

[dantleech]

A more advanced use case would be for granularaly overriding templates / content per client on a platform-based CMS (e.g. all clients share the same website but with subtle differences). This would be a hierarchical way of answering your last problem, but maybe not the best solution. But this is a digression :)

The question is if it makes sense to bundle all the multi-site stuff into one component / bundle. Would there be any reason for the functionality NOT to be in the component/bundle that I am discussing? (the relevant class would only need the RequestStack).

It is the same question as to if this functionality should be in the RoutingBundle in the first place I guess, so I don't really mind.

Although, if this we kept this as a separate bundle I would not include "Host" -- sites can be determined on other criteria (e.g. browser locality, URL prefix etc.). Would MultiSiteBundle be better?

[dantleech]

btw. in a coincidence I was talking to the EZ publish people at the conference today and they said they were thinking about open sourcing their "MultiSiteBundle" which sounded interesting. /cc @bdunogier

[ElectricMaxxx]

It sounds a little bit like a Bad translation from german, but i call those identifiers to separate the items just "Portal". Site got many other meanings - i think. So what about MultiPortalBundle?

An other use case of this bundle would be to create a bunch of configuration , and We will need them, and keep them in one place instead of polluting all other bundles with specific edge cases.

[dantleech]

Hmm but this makes me think. We are dynamically modifying configuration based on the request right? DynamicRequestConfiguration, RequestConfigurationBundle ? Do we have to mention anything so specific as Site, Host, Portal or Domain?

[EmmanuelVella]

My own use case is multiple domains (one for each locale) for the same website. So this is not necessarily for different websites. That why I think multi host is more apropriate.

@dantleech Currently the bundle doesn't change the configuration depending of the request. This was the start idea but it didn't work as I expected (in case of a locale/host mapping configuration). Instead it uses routes locale and host requirements to generate or match urls.

[ElectricMaxxx]

Right, But would the common dev/user expect that name-behavior-combination when he tries to implement a cms for several Portals/Sites/Domains?

[dbu]

i guess it would be really helpful to see the ez MultiSiteBundle before doing a final decision here. chances are that that bundle is currently very specific to ez, but rather than do yet another approach, we could work with ez to make it generic enough to be used for our scenarios. if there is cmf specific integration, we can again see if its small enough that we just add it in RoutingBundle or we need an extra bundle for that.
so @bdunogier, where do those plans stand? is this code visible/documented somewhere so we could take a look at it?

[johnpancoast]

Hate to bring up a 2 year old thread but was there anything to add here? Basically, I'm evaluating different CMS' but a multi-tenant site is necessary. Being a symf person, CMF seemed an obvious choice and I'll likely go that route regardless. I'm just curious if anything's been done or what types of bundles there are. Thanks!

[dbu]

in the symfony cmf, not very much happened with regard to multi-domain/site/tenant systems. the editable routing is designed in a very flexible. with the phpcr-odm provider, you can for example configure more than one route root node, and have routes under those roots. you could use expression language or a custom listener to add roots based on the domain, to use routes (and content) from some or other sites.

however, there is no specific tutorial on multisite and there might be some code to make things more convenient. another piece of the puzzle can be https://github.com/liip/LiipThemeBundle to manage different designs for different domains.

from the cmf side, we are just about releasing version 2 with symfony 3 support and a lot of cleanup. there are no plans to work on multi-site as far as i know (the open source rule: we focus on the stuff we need ourselves...). if you want to invest some time into working out how multi-site is best done with the cmf, i am happy to discuss ideas and guide you writing documentation / code pull requests to improve that topic in the cmf bundles. there is a symfony_cmf channel in the symfony dev slack which is probably the best place to discuss.

[johnpancoast]

@dbu super informative! I'm still getting up to speed on the CMF side of things so it might be a bit but I'd love to help if time allows. I might be around anyway if I jump into CMF for this project. Thanks!