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.
Last successful update .
  1. 06 Jan, 2021 1 commit
  2. 09 Dec, 2020 1 commit
  3. 17 Apr, 2020 1 commit
    • Benjamin Franzke's avatar
      [TASK] Inject singletons used by EXT:install in service providers · c020e9ba
      Benjamin Franzke authored and Susanne Moog's avatar Susanne Moog committed
      This will allow both, dependency injection for these services (manually
      wired in service providers), and usage in install/maintenance tool
      (where we do not use the caching symfony container for basic tasks).
      The move to DI is possible thanks to the failsafe container and the
      service providers which can fed the failsafe container with service
      factories. These factories are used to wire services manually.
       * The definition in a service provider means we are required to use
         manual wiring and are forced to define the dependencies in the service
         provider when we add new depenencies to services that are being used
         by the install..
         With that approach we can assure that we do not accidentally add new
         dependencies to services which would become available in symfony DI due
         to autowiring, but would be unavailable in the install tool.
       * The install tool has operations that require a booted symfony
         container which is provided by the LateBootService. Services that
         are used in that mode do not need to be listed in service providers.
         Therefore we do only add core services to service providers if they
         are used in a context without a fully booted symfony DI container.
       * GLOBALS['LANG'] mocks in Core\Tests\Unit\DataHandling\DataHandlerTest
         have been removed as the code under test does no longer use
         $GLOBALS['LANG']->csConvObj->substr() but mb_substr. The test had been
         introduced with #68602 but the tested code was adapted in #78670.
       * We got a bit ugly constructs now, where a unit(!) test previously used
           $GLOBALS['LANG'] = new LanguageService();
         …we now have to encode the dependency structure:
           $GLOBALS['LANG'] = new LanguageService(new Locales,
               new LocalizationFactory(
                   new LanguageStore,
         This isn't nice, but this change reveals that the affected unit tests
         should either be adapted, removed or be moved to a functional test.
         Such adaption are out of scope for this change.
       * loadExtLocalconfDatabaseAndExtTables() is removed from the
         EXT:install AbstractController, as it hides the implicit dependency
         to LateBootService
       * Nullable constructor arguments have been changed to be non-nullable
         whenever possible. That results in some more test adaptions, but
         reveals, where unit tests rely on implicit dependencies and offers
         better readability and less possible codepaths.
      Releases: master
      Resolves: #89892
      Resolves: #89891
      Change-Id: Ib72d6440f81b2c0d05279e8768697c3b48aecfe4
      Tested-by: default avatarTYPO3com <>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Tested-by: Susanne Moog's avatarSusanne Moog <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <>
  4. 15 Apr, 2020 1 commit
  5. 14 Apr, 2020 1 commit
  6. 13 Apr, 2020 1 commit
  7. 10 Jan, 2020 1 commit
  8. 24 Oct, 2019 1 commit
  9. 21 May, 2019 1 commit
  10. 15 May, 2019 1 commit
  11. 11 Jun, 2018 1 commit
  12. 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 <>
  13. 08 Mar, 2018 2 commits
  14. 15 Feb, 2018 2 commits