This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. 10 Jun, 2018 1 commit
  2. 06 Apr, 2018 1 commit
    • Christian Kuhn's avatar
      [FEATURE] Introduce Site Handling · 0824e6e8
      Christian Kuhn authored and Andreas Fernandez's avatar Andreas Fernandez 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.
       ("Base URL" / HTTP entry point,
      -- 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
      Tested-by: default avatarTYPO3com <>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <>
      Tested-by: Georg Ringer's avatarGeorg Ringer <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
  3. 14 Mar, 2018 1 commit
  4. 15 Feb, 2018 1 commit