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. 29 Jul, 2021 2 commits
  2. 22 Jul, 2021 1 commit
  3. 20 May, 2021 1 commit
  4. 02 Mar, 2021 1 commit
  5. 19 Oct, 2020 1 commit
  6. 12 Oct, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove move placeholders · 27c7de8a
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      Workspaces ("Element-based versioning") previously had - due to
      the "pid=-1" logic until TYPO3 v10 - a so-called "MOVE PLACEHOLDER".
      
      This was indicated by t3ver_state = 3, all relevant fields:
      * t3ver_state = 3 (move placeholder)
      * t3ver_oid = 0 no connected live record, it allowed fetching these records
        with one query together with live records as db restrictions t3ver_oid > 0
      * t3ver_wsid = workspace UID
      * t3ver_move_id = UID of the live record
      * pid = new PID the version was moved to
      * sorting - when a record was moved within page with activated sorting
      
      Other record fields were not important. However, when moving a record, the
      value from TCA ctrl section "shadowColumnsForMovePlaceholders" was used to
      fill in gaps from the live record.
      
      The ACTUAL versioned record was indicated by t3ver_state = 4, the so-called
      "MOVE POINTER". In previous version until TYPO3 v10, it's PID field was set
      to -1, but since TYPO3 v10, it has the same PID as the "MOVE PLACEHOLDER".
      
      Characteristics of the move pointer as of TYPO3 v10:
      * t3ver_state = 4 (move pointer)
      * t3ver_oid = UID of the live record
      * t3ver_wsid = workspace UID
      * t3ver_move_id = 0
      * pid = PID the version was moved to
      * sorting - same value as the live record (not evaluated until now)
      * All other fields with optionally modified content
      
      Both move placeholder and move pointer did not know each other directly.
      Fetching the move pointer for a move placeheldor (or the other way around)
      involved the live record, leading to many queries.
      
      The patch obsoletes the move placeholder records, moving necessary
      information to the move pointer: It now contains the updated sorting
      and is considered in the Database Restrictions to be fetched.
      
      In general, when publishing, the moved record now
      behaves identical to the other versioned types.
      
      This makes the internal code much easier, creates less DB queries
      on read + write and leads to less DB records in the database.
      
      The change removes creation of move placeholders, and considers the
      move pointers when evaluating sorting and PID in DataHandler.
      
      Read functionality from BackendUtility and PageRepository don't need an
      additional step to fetch the live version of a move placeholder anymore.
      
      An upgrade wizard takes existing move placeholders (state=3), updates
      pid+sorting (PID generally not needed, just to be sure) of the move
      pointer (state=4) and then deletes the move placeholder.
      
      TCA definition $TCA[my-table][ctrl][shadowColumnsForMovePlaceholders]
      is not needed anymore and removed by an auto TCA migration.
      
      Finally, workspace enabled tables do not need the t3ver_move_id field
      anymore: The live record UID is already in t3ver_oid field for state=4
      records, just like with all other versioned records. The field will
      be fully removed with a separate patch in order to keep the actual CSV
      tests readable for this patch.
      
      Resolves: #92497
      Releases: master
      Change-Id: I206336aec8be8a324fefdfd69f648f5a298c6ad1
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65797
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      27c7de8a
  7. 18 Sep, 2020 2 commits
  8. 17 Sep, 2020 1 commit
  9. 03 Aug, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove t3ver_count and t3ver_tstamp db fields · 80a38d73
      Benni Mack authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The patch drops handling and existence of two further
      workspaces related db fields:
      
      * t3ver_tstamp has been occassionally set to 'now' when
      records in a workspaces were edited. However, the field
      was never displayed in the backend and is of little use
      since it only holds only a 'last' value. A change
      history on workspace records is available through the
      'info' button in the workspace module. This is powered
      by sys_history and shows modifications with date/time.
      
      * t3ver_count is also never rendered in the backend. It
      has been used in the (non-default) 'swap' workspace actions
      where live records become the new workspace records. The
      field was then incremented by one. The loose wording around
      that is, it's an 'archived' record. However, if swapping a
      second time, the workspace record does not count two as one
      would expect, but still one. Only after another swap, the
      workspace record would have the value two in this field.
      Together with the fact this field has never been shown/used,
      the weird behavior, and that swapping is an uncommon case
      that needs to be explicitely enabled and used, the field
      is dropped now.
      
      Resolves: #89137
      Releases: master
      Change-Id: I7cdfe6e867c14462395d7398123b14464835c1bf
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65145
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      80a38d73
  10. 04 Jun, 2020 1 commit
  11. 17 Apr, 2020 2 commits
  12. 15 Apr, 2020 1 commit
  13. 14 Apr, 2020 1 commit
  14. 02 Dec, 2019 1 commit
    • Benni Mack's avatar
      [FEATURE] Migrate various Signals to PSR-14 events in system extensions · ca19817b
      Benni Mack authored and Susanne Moog's avatar Susanne Moog committed
      The following new PSR-14 events are added:
      
      TYPO3\CMS\Core\Configuration\Event\ModifyLoadedPageTsConfigEvent
      TYPO3\CMS\Backend\Authentication\Event\SwitchUserEvent
      TYPO3\CMS\Backend\Controller\Event\BeforeFormEnginePageInitializedEvent
      TYPO3\CMS\Backend\Controller\Event\AfterFormEnginePageInitializedEvent
      TYPO3\CMS\Backend\LoginProvider\Event\ModifyPageLayoutOnLoginProviderSelectionEvent
      TYPO3\CMS\Impexp\Event\BeforeImportEvent
      TYPO3\CMS\Install\Service\Event\ModifyLanguagePackRemoteBaseUrlEvent
      TYPO3\CMS\Linkvalidator\Event\BeforeRecordIsAnalyzedEvent
      TYPO3\CMS\Seo\Event\ModifyUrlForCanonicalTagEvent
      TYPO3\CMS\Workspaces\Event\AfterCompiledCacheableDataForWorkspaceEvent
      TYPO3\CMS\Workspaces\Event\AfterDataGeneratedForWorkspaceEvent
      TYPO3\CMS\Workspaces\Event\GetVersionedDataEvent
      TYPO3\CMS\Workspaces\Event\SortVersionedDataEvent
      
      They replace the following "old" signals with a deprecation layer:
      
      TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::getPageRenderer
      TYPO3\CMS\Backend\Controller\EditDocumentController::preInitAfter
      TYPO3\CMS\Backend\Controller\EditDocumentController::initAfter
      TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfigPreInclude
      TYPO3\CMS\Beuser\Controller\BackendUserController::switchUser
      TYPO3\CMS\Impexp\Utility\ImportExportUtility::afterImportExportInitialisation
      TYPO3\CMS\Lang\Service\TranslationService::postProcessMirrorUrl
      TYPO3\CMS\Linkvalidator\LinkAnalyzer::beforeAnalyzeRecord
      TYPO3\CMS\Seo\Canonical\CanonicalGenerator::beforeGeneratingCanonical
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss
      
      Relates: #89733
      Resolves: #89813
      Releases: master
      Change-Id: I13f2454fd8f4efb5f4c5248d0b839634b77578db
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62422
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      ca19817b
  15. 21 Nov, 2019 1 commit
    • Benni Mack's avatar
      [FEATURE] Unified PageTS resolving and parsing · ef8190c5
      Benni Mack authored and Anja Leichsenring's avatar Anja Leichsenring committed
      This change introduces two new API classes relevant for PageTSconfig:
      
      - PageTsConfigLoader
      - PageTsConfigParser
      
      The loader class collects all PageTS found in a rootline, which was
      previously available in two places - BackendUtility and TSFE, although
      they were similar, they were not the same and error-prone in the past.
      
      The previous "TsConfigParser" class had an unusal dependency to
      the BackendConditionMatcher only, which did not even allow to send in
      custom arguments.
      
      The TSFE part is now also evaluating TSconfig conditions properly,
      which was not the case in the past. This part is also now cached properly.
      
      The TSconfig inclusion ("include from the list of TSconfig inclusions")
      functionality is now built into the Info module.
      
      In addition, the hard-coded "ConditionMatcher" is now seamlessly
      injected into the parsing process, allowing
      - Decoupling of Logic and Implementation of parsing in different contexts
      - Making the ConditionMatcher extensible by having a new ConditionMatcherInterface
      
      In the next steps:
      - the UserTsConfig parsing can be applied separately and split from BE_USER
      - ConditionMatcher Interface can be used properly
      - TypoScriptParser can be split up
      - BackendUtility can be cleaned up further.
      
      The following functionality is deprecated:
      - TYPO3\CMS\Core\Configuration\TsConfigParser
      - TYPO3\CMS\Backend\Utility\BackendUtility::getRawPagesTSconfig()
      
      Resolves: #89718
      Releases: master
      Change-Id: Ibd0a2d086d7e5166f16213fa4aadffd41ecb645c
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62349
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      ef8190c5
  16. 24 Oct, 2019 2 commits
  17. 16 May, 2019 1 commit
  18. 15 May, 2019 1 commit
  19. 23 Feb, 2019 1 commit
  20. 01 Feb, 2019 1 commit
  21. 28 Oct, 2018 2 commits
  22. 30 Sep, 2018 2 commits
  23. 04 Sep, 2018 1 commit
  24. 14 Aug, 2018 1 commit
  25. 16 May, 2018 1 commit
    • Christian Kuhn's avatar
      [TASK] Streamline TSconfig API · 45c582a8
      Christian Kuhn authored
      Final patch to de-mess the user / page TSconfig related API.
      
      Page TSconfig can be overriden in user TSconfig by prefixing the
      path with 'page.' in user TSconfig. However, method
      BackendUtility::getModTSconfig() violated this principle and
      had a special merge strategy that allowed ommitting the 'page.'
      prefix. This has been marked as deprecated in the TSconfig docs for
      various years and has been lately removed in the docs altogether,
      but the code still existed.
      The patch moves this merge into BackendUtility::getPagesTSconfig()
      and properly deprecates this case. Usages of getModTSconfig() are
      changed to use getPagesTSconfig() directly, dropping the artificial
      'properties' and 'value' sub arrays and omitting some rather expensive
      string operations at the same time.
      This obsoletes getModTSconfig() and a couple of related methods.
      
      Additionally, BackendUserAuthentication->getTSConfig() has been
      abused frequently to operate on different arrays than it's own userTS.
      Those usages are dropped with the patch. Handing over arguments to
      getTSConfig() is now deprecated, effectively reducing the method a getter.
      
      This reduces the API down to BackendUtility::getPagesTSconfig($pid)
      and BackendUserAuhtentiction->getTSConfig() both just returning the
      entire array. This simplified API can now be documented in the docs.
      
      Change-Id: I4bbb066c1d4e2edbc0182f7967897a1558cc3c0d
      Resolves: #85016
      Related: #84982
      Releases: master
      Reviewed-on: https://review.typo3.org/56968
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Jan Helke's avatarJan Helke <typo3@helke.de>
      Tested-by: Jan Helke's avatarJan Helke <typo3@helke.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      45c582a8
  26. 13 May, 2018 1 commit
  27. 25 Apr, 2018 1 commit
  28. 17 Mar, 2018 1 commit
  29. 14 Feb, 2018 1 commit
  30. 29 Sep, 2017 1 commit
  31. 30 Jun, 2017 1 commit
  32. 12 May, 2017 1 commit
  33. 20 Apr, 2017 1 commit
  34. 19 Apr, 2017 1 commit