Piranha.core: Use-cases for multi-site functionality

[tidyui]

As we're going through functionality and evaluating how to plan the long-term development for Piranha CMS we want feedback on if, and if so how you're using the current multi-site functionality. More specifically:

• What problems do you use it to solve
• What limitations does it have for your use-cases

All input is appreciated

[tidyui]

Maybe relevant to discussions in #1131, #1114 and #806

[MehranDHN]

At first allow me to say you guys are genius. But relevant to subject I should say in my opinion the multi site feature is one of the most applicable feature that can be extended because of brilliant modular capabilities of Piranha. Lets suppose I have created an IndexPage as a Model and I want to use it in my sites which all of them have it's own Layout. There must be a way to specify the Layout in each individual Instances of my IndexPage which can be achieved simply by a StringField in my Model. Far better than that I can create my own SelectLayoutField derived from IField and use it as IList<SelectLayoutField> in each instances of sites OR as a SelectLayoutField in Pages .

[MehranDHN]

Sharing assets and media between the sites is also annoying because each site is supposed to have it's own private assets and media unless the administrator want to share them between specified sites.

[tidyui]

@MehranDHN Exactly, this is the whole purpose of this discussion. When we designed the multi-site feature back in the days the use-case we were trying to fulfill was:

• A single tenant wants to manage their main website and some additional smaller sites (for example campaign sites or other focused sites)
• A single tenant wants to manage their main website and translated language versions of that site.

The feature was never intended to support multi-tenant behavior, in fact, like you mention the architecture does not support this.

What we'd like to see is what use cases you are using it for and if it is the above use cases, could we support them better or maybe do it in a different way.

[ksahmed]

i will be using it soon.. and i had some questions which mehran already answered.
i think sharing of items etc should be flexible between the sites, depending on if tenant wants or not.

Can different sites use different layout / theme ?

[tidyui]

@ksahmed Like we've already mentioned in #1131 Piranha is not multi-tenant. I am not in any way objecting to the fact that Piranha lacks lots of features for multi-tenant setup as it is not intended to support it. The multi-site feature has always been intended to be used by a single tenant.

As far as using different layouts goes you can do this in a number of ways. For example:

• Add a setting on SiteLevel where you select the Layout for the entire site
• Add a setting to Pages where you select the Layout per page

[ksahmed]

i didnt talk about multitenancy . :)
piranha has features.. its just the matter of documenting them.. i am enjoying working on it
thanks for the layout suggestion. i will try

[vjacquet]

I built a site in 4 different languages using Piranha and I found the 2 following features missing:

1. you cannot declare a page as an alternate of another one in another language (see #1079)
2. you cannot declare translations for the metadata in the media

For the first one, I ended up adding a PageField in every page type (through a base class) to link to the canonical page. Then I registered a hook on the page save to maintain a class, which, given the Id of the canonical page return the id of the alternates page.
Not being able to use a symbolic name for pages (such as "contact") was also cumbersome when working on the layout.

For the second one, I had to add fields in the page type to compensate, which is more work and not really satisfactory for my users.

And BTW, the preview not honoring the siteid of the page is troublesome (see #335)

[tidyui]

@vjacquet I totally understand. Now Piranha isn't a multi-lingual framework, it just has support for multiple sites. But like you say, one of the use cases for using multiple sites is to have translated versions of the pages.

This comes back to the main question here. When using the multi-site feature for this, is this a good workflow, or could one think of a better one. For example, if we were to define the available languages (which would be needed to solve your second issue), would it be better to just create a translated version of a page in direct conjunction to the original page. This workflow would mean that you would have one sitemap where pages could have different language versions attached to them. With this workflow it would be easy to open a page and then just switch between the different language versions of it instead of going to another site.

Or is it better to keep them separated and continue using multiple sites for this use-case for other reasons?

Regards

[vjacquet]

When working on multilingual sites, the client often start with what we need is "1 page, _n_ translations" but, on the long run, sites often needs to evolve independently, because you need to publish immediately a page not translated yet or you need to publish some pages only for one country.

So I think media and pages should not be handled the same way:

• media are reusable component, so translating the metadata available on the media will improve our ability to use them
• pages in one language can be very different from another language, and may not even exist, so the translation of a page should be another page.
  Therefore, If I understand correctly what you said, being able to "translate" a page, just as you can copy it, would be nice, as you could then create advanced translation workflow.

But, what I am starting to realize is that the translated page may or may not be in another site.

• If the translated pages are in the same site, all translations will share the same URI and the Accept-language header should be use to determine which language to display.
• If the translation are on another site, then it is independent in terms of sitemap and URI.

If you handle this case, you may start with one site and, when needed, move towards a multi-site scenario.

[iwhp]

would it be better to just create a _translated version_ of a page in direct conjunction to the original page.

I would go for this. Having a page which can be translated, instead of having to setup multiple sites.

We could then have pages which are translated already to different languages, an others which are still not yet available in a particular language but sill shown (or not shown) in other languages.

With multiple sites, they could be seen from another angle, then "just be translated version" of other sites. Then they may become "tenants"....

[tidyui]

Another site related question. Atm you’re kind of like browsing through all of sites at once. Would it be beneficial to have a “global” site picker, for example in the top left corner where the Piranha logo is placed where you select the site you’re working with and the just display data for this site instead of having access to everything on each page?

[vjacquet]

I think that adding a site selector to the "Pages" page, like in the "Alias" page, is a good idea.
I had to configure MANAGER_EXPANDED_SITEMAP_LEVELS to 0 to limit the number of pages displayed by default in the 4 languages site I have.

I have no opinion in the matter of having this selector on the left or on the right, like in the alias page.

[tidyui]

@vjacquet What I mean was one global site selector that sets the current site, then this selection follows you as you move between pages until you make another selection.

[vjacquet]

IMHO, a global selector can be misleading as to inform the user on what features are site dependent.
As far as I know, only Pages & Aliases depends on the site. Media, Comments, Users, Roles, Configuration and Modules does not.

Of course, restoring the value of the latest selected site would be appreciated.