Enhance `@site` endpoint to include site bootstrap information

[sneridagh]

Background: We need an endpoint that provides the required information to bootstrap the UI. This information now it's "configured" hardcoded into the Volto config object.

We have to make an exhaustive list but it includes:

• Default language
• Supported languages
• If PAM is enabled
• The logo
• If Registration is enabled
• WorkingCopy support is enabled
• useEmailAsLogin?
• navDepth? ...

I've been giving a thought on how this initial call should work, and given the initial data acquire architecture in Plone 7, it will be convenient that it has the form of a content extender, so we can include this information along with the initial SSR data. The endpoint can have the @bootstrap name, as a suggestion.

Feedback?

/cc @tisto @davisagli @ericof @pnicolli @plone/volto-team

[erral]

We have some of that information already available on the @site endpoint:

• plone.site_logo
• plone.default_language
• plone.available_languages

The names are the same as in the registry.

[sneridagh]

Right, another alternative is to complement the @site endpoint with the remaining of the bootstrap data.

[ericof]

Important reminder for Intranets: the @site endpoint should be accessible even when the portal root View permission requires authenticated user.

[davisagli]

@sneridagh IMO this is exactly what the @site endpoint was created for. Let's look at the specifics but my gut preference is to use it if possible.

it will be convenient that it has the form of a content extender, so we can include this information along with the initial SSR data.

Unlike content extenders though, we only need this data on the SSR load, and not when content is loaded via the client-side router.

[davisagli]

From discussion with @sneridagh today:

• Add-ons might need to add additional info that is loaded as part of the bootstrap (e.g. theme colors from volto-light-theme)
• Sometimes this additional info may be context-dependent (i.e. different theme colors for a subsite) and sometimes not
• So we need to get data in different namespaces and different contexts. This sounds like API expanders.
• The only new thing we need is a configurable list of some API expanders that are only fetched for SSR rendering and not while browsing via the client-side router. Then we could include context-independent bootstrap data like @site in that list.