• Christian Kuhn's avatar
    [FEATURE] Introduce Site Handling · 0824e6e8
    Christian Kuhn authored and afernandez's avatar afernandez committed
    TYPO3 is famously known for the "multi-site"
    functionality, allowing multiple websites running
    within one TYPO3 instance.
    However, configuring a multi-site had various downsides,
    mostly regarding to domain/entrypoint handling for a site,
    and if lots of languages were in place.
    Concepts like "absRefPrefix", "baseURL", various language
    related TypoScript settings, and the infamous
    "L" GET parameter can now be seen obsolete.
    Also, handling page-not-found or access-denied errors
    have never been easier, as every admin/integrator is able
    to configure this.
    What TYPO3 calls a "site" is a entrypoint / pagetree,
    and contains both configuration values relevant for
    Backend and Frontend.
    A site configuration has a unique (human-readable)
    "site identifier" and the following additional values:
    * Root page ID
    This is a page on the root level (pid=0) or having
    "is_siteroot" checked.
    * The base path / base URL
    This HTTP entry point e.g. https://www.mydomain.com/
     ("Base URL" / HTTP entry point,
    like https://www.mydomain.com/)
    -- This allows to fully identify a pagetree with
    an entrypoint without having to guess during "runtime".
    * The definition of all available languages for this
      pagetree, including the default language for this
      specific pagetree.
    -- This includes both values for backend-related as
    well as information, previously only settable via TypoScript.
    This way, it is possible to have a TYPO3 installation
    with 20 languages, but only using 5 languages within
    one pagetree (site), using 15 different languages in
    another site, while also giving meaning for all records
    within one site.
    A site configuration can be added or edited within the
    TYPO3 Backend in a new backend module for admins,
    and is then persisted in
    The configuration format yaml is chosen as it minimizes
    the risk of doing hacks, but the concept of a SiteConfiguration
    can be adapted / exchanged to be overloaded or found
    in various other places in the future.
    Adding a site configuration for a project has various
    - Configuration is in one place, stored in the file system
      thus, is deployable.
    - Configuration can be done by an integrator/admin without
      any programming skills => in one place.
    - The necessity to query sys_language is only needed when
      configuring a site.
    - No need to configure TSconfig options like
      "previewDomains" and "defaultLanguageLabel" are gone.
    - No need to configure any TypoScript conditions, or
      even TypoScript settings related to language handling.
    - It is possible to configure error handling on a per-site
      level, even language-dependant, without having to
      code or configure anything.
    However, if no site is configured for a pagetree, the
    previous behaviour is still in place, allowing to migrate
    slowly to the sites handling, as some key functionality like
    URL path handling for speaking URLs is not in place yet.
    It is important to understand that adding a site
    configuration comes with various restrictions:
    - "sys_domain" handling is not necessary anymore, as a page
      is resolved via the domain+base URL given in the configuration
    - Any previously configured TypoScript conditions based
      on L parameter do not apply anymore if a site is configured
    - This also applies to any config.*language* related TypoScript
    - It is necessary to use a URI with scheme and path to configure
      a site, where as previously, TYPO3 would work without a base
    - mod_rewrite or something similar is a requirement for sites
      to work properly.
    Further improvements not yet implemented:
    - Ensure backend modules like Web->Page, Web->View, Web->List
    and Web->Info only show records in the configured site languages.
    - Enable the possibility to handle "domain entry aliases",
      also for multi-server setups with different domain names.
    - Ensure the new Site module can handle "read-only" / deployable
      site configurations.
    - Allow to activate a language for a site to be editable
      in the Backend but not be available in the Frontend for
    - Handling "Storage Folder" on the top level with different
      language entries.
    - Improve URL generation in frontend to skip sys_domain
    - TypoScript conditions for [site = my-identifier] and
      [siteLanguage = dk].
    - Improve proper caching for rootline resolving of pages
      without restrictions.
    - Improve resolving of siteLanguage from the current request.
    - Linking from one site to a page of a different site.
    - Centralizing access to sys_language and sys_domain.
    - Handle copying/moving of records to a different site
      with different languages and language settings.
    - Handle configuration change (like deleting a language
      in the configuration - what should happen to the
      translated records?)
    Next up for 9.3:
    - Adding "Routers" on top of sites for URL resolving
      of pages and records.
    - Handle Storage Folders on top level rootline
    - Handle Mount Points
    New API:
    - New Entity classes "Site" and "SiteLanguage" are
      resolved as part of a PSR-15 middleware and available
      for pages in FE and BE when possible.
    - A SiteFinder object is used to query Site and SiteLanguage
      objects and used in various places.
    - The new PageUriBuilder allows to create links to pages
      without any relation to the current request, and
      are already in use in Frontend links and Backend preview links.
    - A PageErrorHandlerInterface allows to custom error handlers
      to be introduced by extensions and configured on any site.
    Site handling is considered still "under development"
    until TYPO3 9 LTS, and implementation as well as the
    configuration format might change in the next sprint
    releases, in order to gather feedback on what is missing
    in the implementation.
    As a site configuration will be mandatory for TYPO3 v10.0,
    some changes regarding sys_language and sys_domain will
    - Due to the definition of every record of default language
      (language=0), it might be possible to switch to locales
      for languages and get rid of the language ID.
    - sys_domain won't make it any much longer.
    Resolves: #84581
    Releases: master
    Change-Id: Iabeeb6835a98c8f5a71d502379ed63a68dfad6dd
    Reviewed-on: https://review.typo3.org/56505
    Tested-by: default avatarTYPO3com <no-reply@typo3.com>
    Reviewed-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
    Tested-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
    Reviewed-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
    Tested-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
    Reviewed-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
    Tested-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>