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. 17 Dec, 2020 1 commit
    • Oliver Bartsch's avatar
      [!!!][TASK] Rework shortcut PHP API functionality · e4833fda
      Oliver Bartsch authored and Christian Kuhn's avatar Christian Kuhn committed
      To be able to introduce URL rewrites for the backend,
      the internal handling and registration of the shortcut
      PHP API is reworked.
      
      The Shortcut PHP API previously has the full URL of
      the shortcut target stored in the database. This lead
      to many problems such as shortcuts got invalid as soon
      as their target module changed its route path. Furthermore,
      this required unnecessary functionality like replacing
      tokens on URL creation.
      
      Therefore, a shortcut record now stores only the route
      identifier of the module to link to and necessary arguments
      in two new database columns. A upgrade wizard is in place
      to migrate existing data.
      
      The rework also required to deprecate some methods in
      the ShortcutButton API and a parameter signature change
      of the JavaScript function `TYPO3.ShortcutMenu.createShortcut()`
      which performs the AJAX call to create new shortcuts.
      
      Side effect, this also deprecated the last remains of
      xMOD_alt_doc.php in the core.
      
      Resolves: #93093
      Releases: master
      Change-Id: I07666a299651e4953b4adf2987fcd3469094c288
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67143
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      e4833fda
  3. 14 Dec, 2020 1 commit
  4. 22 Oct, 2020 1 commit
  5. 20 Oct, 2020 1 commit
  6. 08 Oct, 2020 2 commits
  7. 02 Oct, 2020 1 commit
  8. 05 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Refactor create bookmark handling · 5be7b805
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The backend shortcut / bookmark handlig API was designed to
      hand over relevant get/post arguments as key only (eg. 'id').
      The underlying code then pulled values from GET/POST or from
      SOBE->MOD_SETTINGS. This is ugly, there shouldn't be such
      magic: Only controllers know relevant keys and values, so
      it should hand them over directly to the shortcut API.
      
      The patch changes this:
      * Old and unused ViewHelper f:be.buttons.shortcut is deprecated.
      * ViewHelper be:moduleLayout.button.shortcutButton deprecates
        argument 'getVars' and adds new argument 'arguments'.
      * Class ShortcutButton has a new setter 'setArguments' that
        accepts all relevant argument key/value pairs to create a
        shortcut. Existing get/set related methods are deprecated.
      * Helper methods 'makeShortcutIcon' and 'makeShortcutUrl' of
        class ModuleTemplate are deprecated and implemented in class
        ShortcutButton directly.
      * All core usages are adapted to new API.
      * Shortcut handling was the last core usage of SOBE, so last
        $GLOBALS['SOBE'] = $this assignments can be finally removed.
      
      Impact:
      * Shortcuts to modules not directly reachable via main menu
        do not work due to limits of the module registration API. An
        example is the 'create multiple pages' controller. This issue
        exists before the patch, affected controllers no longer render
        a shortcut button for now.
      * The old code usually added the 'route' argument twice for shortcuts.
        This has been resolved. As a side effect, the comparison if a
        shortcuts exists (yellow shortcut icon) fails currently for existing
        shortcuts when the patch is applied: The comparison relies on
        direct string equality since shortcuts always store the final url in
        the database. This storage strategy should be changed with another
        patch that will solve the 'no yellow icon' issue at the same time.
      
      Change-Id: I3ccd2b8f6adab8e7780c5f9911fdea013ccfa99b
      Resolves: #92132
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65503
      
      
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      5be7b805
  9. 04 Sep, 2020 1 commit
  10. 11 May, 2020 1 commit
    • Helmut Hummel's avatar
      [BUGFIX] Consistently fetch SiteConfiguration from DI · cd8a613c
      Helmut Hummel authored
      SiteConfiguration is available from the DI container (both in failsafe and
      symfony DI), therefore no constructor arguments MUST be passed to
      GeneralUtility::makeInstance when fetching the SiteConfiguration singleton
      instance, or a new instance will be created.
      
      There are however multiple places where this object is still created
      by passing constructor arguments to GeneralUtility::makeInstance
      (this bypasses proxying to the container).
      This leads to the situation that two different objects are created and
      retrieved, depending on how it is fetched.
      
      This is now fixed by changing each remaining retrieval via makeInstance
      to NOT provide constructor arguments, which in turn results in a call to
      the container to fetch the SiteConfiguration object.
      
      Additionally the ServiceProvider introduced in #89892 is changed to allow
      providing an alternative implementation using XCLASS. Although XCLASSES
      are generally discouraged in favor of Services.yaml overwrites, there is
      no other way to provide an alternative for this class, as it is registered
      in an internal service provider.
      
      Resolves: #91260
      Releases: master
      Change-Id: I8af1cafd737feccff9e06eacb23d6991105238d0
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64386
      
      
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      cd8a613c
  11. 15 Apr, 2020 1 commit
  12. 14 Apr, 2020 2 commits
  13. 13 Apr, 2020 1 commit
  14. 13 Mar, 2020 1 commit
  15. 25 Jan, 2020 1 commit
  16. 19 Dec, 2019 1 commit
  17. 26 Sep, 2019 1 commit
  18. 13 Sep, 2019 1 commit
  19. 17 Jul, 2019 1 commit
  20. 14 Feb, 2019 1 commit
  21. 08 Feb, 2019 1 commit
  22. 02 Nov, 2018 1 commit
  23. 01 Oct, 2018 1 commit
  24. 20 Sep, 2018 3 commits
  25. 07 Sep, 2018 2 commits
  26. 28 Aug, 2018 1 commit
  27. 17 Aug, 2018 1 commit
  28. 26 Jul, 2018 1 commit
  29. 23 Jun, 2018 1 commit
  30. 14 Jun, 2018 1 commit
  31. 21 May, 2018 1 commit
  32. 25 Apr, 2018 1 commit
  33. 09 Apr, 2018 1 commit
  34. 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