Siteaccess operators #

Three classes registered in kernel/common/eztemplateautoload.php give templates the addresses and names of the other siteaccesses of the installation.

The examples ran on the command line, so the scheme is http and the host comes from the settings.

Contents #

1. The operators: siteaccess_url, siteaccess_menu, siteaccess_menu_key, language_switcher
2. Compiled templates

The operators #

siteaccess_url #

Generated page: siteaccess_url.

• Input: none.
• Returns: the front page address of a siteaccess, ending in /, as a string. Without a name it is the front page of the site the current siteaccess belongs to (ezpSiteAccessURL::front()): [SiteSettings] FrontSiteAccess of the current siteaccess (an administration names its site there), else DefaultAccess. A siteaccess that is not in AvailableSiteAccessList[] gives an empty string.

The address is worked out from the scheme, host and port of the request and the way the target siteaccess is matched (MatchOrder with host_uri, host and uri; URIMatchType, HostUriMatchMapItems, HostMatchMapItems, and the siteaccess's own [SiteSettings] SiteURL), so it works for URI, host, host and URI, and port matching alike. An address is only used when the matching rules lead it to that siteaccess with nothing of the path left over, so a host-matched site never gets a /name/ path that its host would read as a module (and answer 404). In this order:

1. this host, with a HostUriMatchMapItems entry of the siteaccess for this host, else with its URI element (or its URIMatchMapItems key);
2. the siteaccess's own SiteURL (host, port and path; an index file in it is left out), unless it is empty or localhost;
3. a host that HostMatchMapItems maps to it, without a path;
4. the host and URI of one of its HostUriMatchMapItems entries.

When none of them can be shown to lead there, its URI on this host is used, else its SiteURL as written, else this host. The scheme is always the one of the request. With the settings of a demo whose administration has a host of its own (MatchOrder=host_uri;host;uri, HostMatchMapItems[]=edit.example.com;admin and =example.com;site, HostUriMatchMapItems[]=example.com;bold;bold;strict), the administration on edit.example.com links site to https://example.com/ and bold to https://example.com/bold/. It is not quoted and not escaped.

1 front: {siteaccess_url()}
2 bold: {siteaccess_url( 'bold' )}
3 starter_ger: {siteaccess_url( 'starter_ger' )}
4 not available: {siteaccess_url( 'nosuchsite' )|get_type}

Output:

1 front: http://www.example.com/site/
2 bold: http://www.example.com/bold/
3 starter_ger: http://www.example.com/starter_ger/
4 not available: string[0]

siteaccess_menu #

Generated page: siteaccess_menu.

• Input: none.
• Returns: a hash with enabled (bool), front (the item of the site the globe button opens) and groups (a list of hashes with identifier, site or admin, and items). An item is a hash with identifier, name (SiteName, else the identifier), locale, lang, url, display_url (without the scheme and trailing slash), current and admin.

It is the data of the globe button in the admin4 and admin4l headers, configured in site.ini [AdminSiteAccessMenu] of the administration siteaccess: Show, List (related uses RelatedSiteAccessList[], available uses AvailableSiteAccessList[]), HiddenSiteAccessList[], AdminSiteAccessList[] and ListAdministrations. With a user, a siteaccess other than the front site is listed only when that user may log in there (eZUser::canLoginToSiteAccess()); the admin templates pass $current_user.

Rendered on the admin siteaccess without a user:

{def $menu = siteaccess_menu()}
enabled={$menu.enabled|choose( 'no', 'yes' )} key length={siteaccess_menu_key()|count_chars}
front: {$menu.front.identifier} {$menu.front.display_url}

{foreach $menu.groups as $group}
{$group.identifier}: {foreach $group.items as $item}{$item.identifier} ({$item.locale}){delimiter}, {/delimiter}{/foreach}

{/foreach}

Output:

enabled=yes key length=32
front: site admin.example.com/site
site: bold (eng-US), bold_ger (ger-DE), editor (eng-US), starter (eng-US), starter_ger (ger-DE)

siteaccess_menu_key #

Generated page: siteaccess_menu_key.

• Input: none. Parameters: none.
• Returns: an MD5 string for cache-block keys (an empty string when the menu is switched off). It changes with the listed siteaccesses, the administration list, the front siteaccess, the current siteaccess, and the scheme, host and port of the request, so a cached header shows the right menu. Line 1 of the example above shows its length. The key reads no setting of the listed siteaccesses themselves: a changed SiteName or Locale of one of them shows after the template caches of the administration are cleared.

language_switcher #

Generated page: language_switcher.

• Input: none.
• Returns: what setupTranslationSAList() of the class in [RegionalSettings] LanguageSwitcherClass returns, or nothing when the setting is missing. The kernel's ezpLanguageSwitcher returns one entry per [RegionalSettings] TranslationSA[<siteaccess>]=<name>: a hash with url (/switchlanguage/to/<siteaccess>/ plus the destination), text (the name) and locale (ContentObjectLocale of that siteaccess). An empty array when TranslationSA is not set.

When the destination has no ?, the query string of the current request is appended to it. The url is a path for ezurl, which adds the current siteaccess prefix; the switchlanguage/to view (kernel/private/modules/switchlanguage/to.php) asks the same class for the address of the destination in the other siteaccess and redirects there. On a development installation only some siteaccesses set TranslationSA; rendered on starter:

TranslationSA has {ezini( 'RegionalSettings', 'TranslationSA' )|count} entries

{foreach language_switcher( 'privacy-policy' ) as $sa => $lang}
{$sa}: {$lang.text} {$lang.locale} {$lang.url}

{/foreach}

Output:

TranslationSA has 2 entries
starter: English eng-US /switchlanguage/to/starter/privacy-policy
starter_ger: Deutsch ger-DE /switchlanguage/to/starter_ger/privacy-policy

Compiled templates #

siteaccess_url, siteaccess_menu and siteaccess_menu_key have template hints with transformations: the compiler writes a direct call (ezpSiteAccessURL::root() or front(), ezpSiteAccessMenu::current(), ezpSiteAccessMenu::key()) into the compiled template, so they cost no operator lookup at run time and are evaluated on every run, never at compile time. language_switcher has no hints and runs through modify().

Related pages #

• URL, design, INI and HTTP operators
• Content languages
• All template operators (generated)
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.