(blocking) multiple domains per site

[testbird]

Alias domains have been implemented and are now working well.

The remaining usage issues have been reported in this comment:
#45 (comment)

---

Multiple domains per site are rather common, and usefull for different things. One example is a security relevant use case: A 1:1 mapping (simple alias, same skins etc.) of a ssl domain like https://mywebaccount.ssl-hoster-domain.tld -> to one's regular www.example.org site, together with allowing logins only on the not-advertised SSL domain.

But more generally, multi-domains should allow that different frontend websites (URLs) that may have distinct appearance and functionallity, can share common node data.

Ideally, this could be as simple as alowing to add additional "sites" (more precisely domains) to the "Sites" table in the admin pages. (There is currently no "add" button under the "Sites" table.)

Zena would have perfect support for multiple domains per site with two fields in the "Sites" table (rather Domains table) that allow to assign a default skin and root node for each domain, and making the domain that the visitor requested available for "if" clause tests in zafu emplates.

[gaspard]

Multiple sites could be implemented with the notion of site alias where the "site_id" (used to secure finding nodes in shared hosting) parameter would be shared. Things to redefine in the site alias:

1. root node
2. anonymous user
3. forced skin (to overwrite the skin setting on the nodes themselves)

Things that could go wrong:

1. root node has a parent. What happens if this parent is accessed (ancestors method for example) ?
2. session management

First steps:

1. Change all secure code to use: "current_site.site_id" instead of "current_site.id".
2. Secure all site editing to protect new "site_id" field.
3. Create SiteAlias class with differing "site_id" and "id".

[testbird]

In your comment, I have trouble following what is meant by each instance of the word "site". Maybe call one domain_id?

root node:
Does the index page always have to be the root node? Maybe it is easier to make the index page configurable, and with this multiple domains may share the root node and structure. Then use as index pages either the root node or different child nodes (depending on the use case).

Hm, I haven't thought about different anonymous user groups. That would be to optionally make nodes available only on some domains?

Do we need to force a skin?
It may unnecessarily take away finer grained configurability. I thought just having different per-domain default skins allows to use different skins by default (if required) and the per node setting could still allow to override it as usual to a uniqe skin (that may again render differnt things depending on the requested domain, if that is required)

[gaspard]

I think we must move on with this by changing the minimum amount of things at a time. Let's first create an alias that with just a different host and root node and see how it goes.

[testbird]

That would be great. Maybe we don't even need to mess with the root node to begin.

More important may be to make the requested domain available for if clauses in zafu templates. Then these can be used to render the same nodes differently when it is required.

[testbird]

Page caching would have to be separate for each domain, maybe that was the reason you refered to this as alias "site" from the zena perspective?

[gaspard]

The first implementation supports root node setting and some custom authorization options. Blog post on the new feature: http://zenadmin.org/888.

[testbird]

Wow, thanks!!! perfect, trying this out is the next thing on the my zena list then!

I may miss this later: the post mentions “orphan node”, but not how/where it gets configured.

[gaspard]

The 'orphan' node cannot be defined: it is the true root of the data (what "root" used to be).

[testbird]

Ok, I may then only ask where is the root node configured, if I don't find it in the the opened edit form for host and alias.host (not shown in the screenshot). ;-)

Thanks again.

[gaspard]

There is a "root" field in the form:

[testbird]

The wording keeps confusing me ;-)
One, where zafu refers to the "user" I think it is much clearer to say it refers to the "owner" of the node. And calling a child node "root" really seems to let me think in circles... doesn't it just set the "index" or "home" node?

Still to overcome: As far as I know, it is not be possible to rename or delete an existing domain/site, which prevents to recreate it as an alias to another site.

[gaspard]

"Owner" instead of user is fine. I agree, I will rename the "root" node "home" in 1.2.5 and add necessary scoping in querybuilder and such so that <r:home> and "menus from home" work as expected (orthogonality with "root" keyword).

[testbird]

That is great. When you are renaming maybe also consider to rename the "Sites" configuration in the admin panel (within a site) into "Domain" and "alias-domain" configuration, to differenciate it from creating the "Sites" (different node spaces) with rake or possibly the admin interface for superuser accounts.

[testbird]

Two remaining issues:

1. The new "home" method does not yet support replacing some uses of "root" in zafu. The error is "unknown method 'home()') for Zena::ZafuCompiler)":

<r:link href='home'>

<r:if test='id != home.id'>

2. The "in site" sqliss scope always returns all matching nodes from anywhere in the master site, and there is no way to restrict the returned nodes to be child nodes of the alias's home node. (see http://zenadmin.org/443)

My suggestion would be to introduce new scopes like "in home_site", to fetch from everything below the home node, and "in root_site", to fetch from everything below the root node. And make the "in site" scope return the same as "in home_site", i.e. return nodes from anywhere below the current site's home. For a master site where the home node equals the root node, "in site" then continues to equal "everything below the root node". Whereas for alias sites with different home node "in site" is confined to the alias's home.

[testbird]

solved in 1.2.9