Multisite support

[neilferreira]

Hey,

I'm currently chasing a CMS that has multisite support, after having a quick browse around here in the frontend bundle I figure doing multisite support would not be extremely difficult.

Custom routes added by the user will soon be able to have a _host param passed to it (see symfony/symfony#3378) and if you adjust the content schema to support a parent which is infact a 'site' I think you'll be well away.

Is this something you're likely to plan? I noticed that RadiantCMS does not support it, I don't know how closely you wanted to resemble Radiant.

Cheers

[marekkalnik]

Hi,

We're not willing to copy RadiantCMS, we just thought it was a good CMS to start with.

As for full multisite support - I think we would have some problems with it. Names and slugs are unique (I'm working to change it for slugs), so it's far more collision prone with multiple sites.

But if you want, I think that we're not so far from having it in current implementation - just create a site structure like:

homepage
| - first_site
|   `- some_page
`- second_site
   ` some_other_page

You'd need to create your own FrontendController and check the host to create the full slug. I'm doing some refactoring on slugs, so I'll add a getPageByFullSlug() soon. We'll change how the slugs are saved in database so a compatibility migration script may be necessary.

For our own implementation of multisite support - I think it would be made exactly as I told you, so it should be made as a plugin/separate bundle, with it's own routing/frontend.yml and FrontendController called instead of those of the CMS bundle. But I won't have the time to do it any time soon. If you're wanting to do it, feel free to drop in on: https://groups.google.com/group/theodo-roger-cms for any support we can provide.

Cheers

[neilferreira]

Hi,

I'm not sure how your schema works yet as I'm about to check it out, what I was thinking is that every piece of content could have a unique index on it (schema level) that encapsulates the parent id (null if this is a root node or 'site') and the 'slug' - meaning that the unique checks are not done by the slug alone, because then having it done at a db level, and checks within your codebase you would have a fairly sure way of knowing that there are no pags on the same level (ie. site.com/foo/bar and site.com/foo/bar would never exist, as trying to create the second 'bar' would violate the unique index of having the slug 'bar' under 'foo'

I'm not 100% sure with this setup yet how you would do the routing, I'm guessing you could split up the request URI by slashes and form up a big SQL query like 'WHERE record.slug = 'bar' and record.parent.slug = 'foo' recursively)

Anyways these are my rambles, there are a few open source sf2 cms's at the moment that I'm looking at to see which one would make my job easiest to fork and work from.

Cheers

[marekkalnik]

I'm going for saving the full slug in database, this will allow us do the parent check only while saving.