This project is mirrored from https://git.typo3.org/typo3/typo3.git. 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. 30 Sep, 2020 1 commit
  3. 16 Jan, 2020 1 commit
    • Susanne Moog's avatar
      [BUGFIX] Reimplement previewing of date / usergroup restricted content · a672d33a
      Susanne Moog authored and Susanne Moog's avatar Susanne Moog committed
      Preview functionality was only implemented in the Admin Panel. Previewing
      itself (as in being able to preview pages with access or user restrictions)
      should also work without having the admin panel installed and open.
      
      The basic process is now like this:
      - Backend generates preview URLs for pages with access restrictions
      -- starttime, endtime, fe groups
      --> parameters ADMCMD_simUser and ADMCMD_simTime are appended to the FE URL
      - Frontend PreviewSimulator Middleware uses these parameters to modify
      the current Context
      - Adminpanel - if installed and open - takes given parameters as settings
      for preview date/time/group - when user changes those, they are overwritten
      
      Technical Changes:
      - BackendUtility: Enable link generation for a specified context
      - DateTimeAspect: Add new property to aspect to mirror SIM_ACCESS_TIME global
      - PageRepository: Use new DateTimeAspect context property for enable fields
      - AdminPanel: Set $_GET params in settings if given, remove $_GET vars if user
      saves admin panel settings (to allow user to change date/time in AdminPanel)
      
      Resolves: #86653
      Releases: master, 9.5
      Change-Id: I3a2302845461e9c18f9349438e10f1c059a85e48
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/59927
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      a672d33a
  4. 13 Jul, 2019 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove dependencies of TSFE · e50b1c1a
      Benni Mack authored and Andreas Fernandez's avatar Andreas Fernandez committed
      This patch re-arranges the TYPO3 Core internally used
      middlewares for lifting off the weight of $GLOBALS['TSFE']
      as Site Handling already introduced a lot of functionality
      which can now be utilized further.
      
      For this reason, the Frontend Rendering chain has
      been adapted.
      
      * If there is a "Site" + "Language" resolved, this information can
      be used directly, as there are no dependencies currently.
      
      * Frontend + Backend User Authentication works regardless
      of TSFE, Frontend User is added to the Request object as
      attribute to be added to TSFE later-on.
      
      * Resolving the Page ("slug") and mapping them to Page
      Arguments (URL parts + GET parameters) as well as validation
      against cHash is fully decoupled from TSFE.
      
      After that, TSFE is instantiated, which now gets all resolved
      objects injected.
      
      TSFE now only resolves the rootline against the proper permissions
      (auth) and validates the final page. Once done, TypoScript is
      compiled / cached.
      
      TSFE still contains the rootline, TypoScript, and the information
      about which non-cacheables are there.
      
      RequestHandler creates or fetches cached content, but currently piped
      through TSFE. This should be simplified further later-on.
      
      Resolves: #88717
      Releases: master
      Change-Id: I12807455fd8b01493b2da45cf73a5c532b108cbe
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61155
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      e50b1c1a
  5. 07 Feb, 2019 1 commit
  6. 28 Oct, 2018 1 commit
  7. 28 Sep, 2018 2 commits
  8. 20 Sep, 2018 1 commit
  9. 17 Sep, 2018 1 commit
  10. 10 May, 2018 1 commit
  11. 04 May, 2018 1 commit
  12. 24 Apr, 2018 1 commit
  13. 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. 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
      "typo3conf/sites/site-identifier/config.yaml".
      
      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
      benefits:
      - 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.
        is
      - 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
        setting.
      - It is necessary to use a URI with scheme and path to configure
        a site, where as previously, TYPO3 would work without a base
        URL.
      - 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
        everybody.
      - Handling "Storage Folder" on the top level with different
        language entries.
      - Improve URL generation in frontend to skip sys_domain
        resolving.
      - 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
      follow.
      
      Beware:
      - 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: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      0824e6e8
  14. 01 Mar, 2018 1 commit
  15. 28 Feb, 2018 1 commit
  16. 19 Feb, 2018 2 commits
  17. 16 Feb, 2018 1 commit
  18. 15 Feb, 2018 2 commits
  19. 14 Feb, 2018 1 commit
  20. 12 Feb, 2018 2 commits
  21. 08 Feb, 2018 1 commit
  22. 07 Feb, 2018 1 commit
  23. 06 Feb, 2018 1 commit
  24. 03 Feb, 2018 2 commits