Sites, SiteTrees and Pages

[mlocati]

AFAIK, concrete5 page structure is currently organized in:

• Sites: even if at the moment there's no way to handle it, a single concrete5 installation supports multiple sites. Sites are listed in the Sites database table.
• Site Trees: every site has one or more site trees, each one consisting in a multilingual section. SiteTrees are described in the SiteTrees + SiteTreeTrees database tables (persisting the SiteTree entity) with a 1:1 relation with the SiteLocales database table
• Pages, that are associated to Site Trees (via the Pages.siteTreeID database column). Pages that are not site-specific have a value of 0 in the siteTreeID column.

Currently:

• the "system" pages that are not site-specific are:
  • the dashboard pages
  • stacks and global areas
  • the trash
  • account pages (/account - but not /account/welcome)
  • the file download page
  • the login page
  • the page forbidden page
  • the register page
  • the page not found page
• the "system" pages that are site specific are:
  • the /account/welcome page
  • the drafts

I know absolutely nothing about handling different Sites in the same instance (no public information, no helper class, ...), but the above structure about Site Trees seems to have the following problems to me:

• why all the /account pages are not site-specific, but /account/welcome is? Is this wrong?
• why pages like "page forbidden" are global but "page not found" is site-specific?
• having drafts depending on the site trees leads to big problems:
  • why are them language specific?
  • what if someone deletes a multilingual section? Drafts will loose the link to the site (here's the result).
  • I'd make drafts depending on the site, not on the site tree (so, I'd add a Pages.siteID column)

[Remo]

I'd like to have a bit more information about the site concept too. A while ago I tried to dig through the code to find a problem, but gave up as it's a bit hard to follow without any documentation. While most people don't need this, it would help some of us to help the core for sure.

[aembler]

We'll get more into it in version 9 – we will be including tools to actually create site objects (to run a multisite concrete5 installation.) Don't know if we've made that official yet...consider this an official notice ;)

To answer your questions:

1. You're probably right...all the account pages should probably be site-specific.
2. You're probably right...I imagine forbidden should also be site specific. It's just less likely to matter than Page Not Found because in my experience the forbidden page isn't skinned as often as the Page Not Found page.
3. We do want drafts to be multilingual specific. Multiple multilingual sites that we have worked on create a draft in one language, and actually duplicate it into the other sections of the site and work on them simultaneously, in multiple languages, and publish them simultaneously.

[mlocati]

We'll get more into it in version 9 – we will be including tools to actually create site objects (to run a multisite concrete5 installation.) Don't know if we've made that official yet...consider this an official notice ;)

I wasn't aware of that... Great!!!!!!!!!!!!!!

We do want drafts to be multilingual specific. Multiple multilingual sites that we have worked on create a draft in one language, and actually duplicate it into the other sections of the site and work on them simultaneously, in multiple languages, and publish them simultaneously.

But we have just one /!drafts page, don't we?

IMHO we should have 3 classes of pages:

1. super global pages (for any site), like the dashboard/account pages
2. site-specific global pages (shared across all languages, but specific for one site)
3. site & language specific pages

With just one column (Pages.siteTreeID) we can just have two classes (not empty => 3., empty => 1. or 2. ?)

What I suggest is to add a Pages.siteID with:

• super global pages have both siteID and siteTreeID empty
• site-specific global pages have siteID set, and siteTreeID empty
• normal pages have both siteID and siteTreeID set

That way, if we delete a locale section, we won't have problems with the two types of global pages.

[mlocati]

PS: when I say that a field is empty, I mean NULL and not 0, so that we can use database foreign keys to be sure that data is consistent.

[aembler]

This is something we need to clarify as a part of getting our multi-site solution out for 9.0. I'm going to reopen it.

In general, we use Site Trees in a few different contexts, which is what makes our current setup confusing. If you have a single concrete5 installation running 20 sites (all of which are English), you'll have 20 site trees. And if you have a single concrete5 installation running 1 site with 20 languages you'll have 20 site trees as well. So we might want to have some differentiation there. Additionally I'm wondering if having some system where a fallback is in place might help (e.g. if you have a page not found page in every language you can localize it for a given site, but if you don't have one in a particular site tree it'll fall back to rendering from the one outside the site tree.)

[Ottokarl]

(e.g. if you have a page not found page in every language you can localize it for a given site, but if you don't have one in a particular site tree it'll fall back to rendering from the one outside the site tree.)

i would prefer: fallback to a page in the "fallback language". then i need to have only that language site tree complete, and dont need a copy for every language .