1. 08 Jun, 2022 1 commit
  2. 14 Mar, 2022 1 commit
  3. 02 Mar, 2022 1 commit
  4. 14 Feb, 2022 1 commit
  5. 13 Oct, 2021 1 commit
  6. 24 Sep, 2021 1 commit
  7. 22 Sep, 2021 1 commit
  8. 08 Aug, 2021 1 commit
  9. 05 Aug, 2021 1 commit
  10. 20 Jul, 2021 1 commit
  11. 20 Nov, 2020 1 commit
  12. 17 Nov, 2020 1 commit
  13. 12 Nov, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Do not create new version placeholders in workspaces anymore · 74899ecf
      Benni Mack authored
      Creating a new record in a workspace adds two database rows.
      One that is the "placeholder", which - since v10.4 - contains
      the same metadata as the other record:
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (simulating behavior of an "online pendant record")
      * t3ver_state = 1
      And the "versionized" record, identified by:
      * t3ver_wsid = workspaceID
      * t3ver_oid = uid of the new placeholder record
      * t3ver_state = -1
      As of TYPO3 v10, the first record is not needed anymore,
      the versioned record can be queried directly, however, since
      the relations (except MM) point to the placeholder record,
      this one is kept.
      As result, only one record is created from now on:
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (no online counterpart)
      * t3ver_state = 1
      On reading, the record is queried directly (no overlay needed anymore!)
      with the existing Database Doctrine Restrictions. On publishing, the
      record just gets the state/stage/wsid set and is "live".
      This brings fundamental benefits:
      * No overlays needed when querying
      * Fewer database records (placeholders are not helpful)
      * Conceptual problems with placeholder and shadowed fields are removed
      Resolves: #92791
      Releases: master
      Change-Id: I0288cc63fe72d8442d586f309bd4054ac44e829b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65587
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  14. 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>
  15. 16 Apr, 2020 1 commit
  16. 15 Apr, 2020 1 commit
  17. 14 Apr, 2020 2 commits
  18. 04 Apr, 2020 1 commit
  19. 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>
  20. 30 Dec, 2019 1 commit
  21. 24 Oct, 2019 1 commit
  22. 17 Jul, 2019 1 commit
  23. 28 Jun, 2019 1 commit
  24. 15 May, 2019 1 commit
  25. 09 Jan, 2019 1 commit
  26. 13 Jul, 2018 1 commit
  27. 02 Jul, 2018 1 commit
  28. 27 Jun, 2018 1 commit
    • Benni Mack's avatar
      [FEATURE] Add Contexts for storing data access modes · 5f8f50a0
      Benni Mack authored and Andreas Fernandez's avatar Andreas Fernandez committed
      A new "Context" concept is added which allows to keep
      the state of common TYPO3 Request Data in form of
      so-called Aspects.
      An aspect contains properties which can be fetched,
      but only the ones that are really necessary, instead of
      exposing a full object (e.g. BE_USER).
      The main goal is to centralize some global variables
      distributed in various places.
      In the first step the following variables are considered:
      - $TSFE->showHiddenPages
      - $TSFE->showHiddenRecords
      - $TSFE->beUserLogin
      - $TSFE->gr_list
      - $TSFE->loginUser
      - $GLOBALS['BE_USER']->workspace
      For now the Context is a singleton object, but should
      be fetched from a DI container.
      Sometimes a custom context is necessary, so it is
      cloned (see usage in TSFE).
      The difference to the PSR-7 request attributes is that the
      context is ONLY related to data access (like permissions / visibility)
      and also independent if TYPO3 is running via HTTP or CLI
      (thus, can be used in CLI mode as well).
      Next Steps:
      - Migrate PageRepository->versioningWorkspaceId
      - Migrate TSFE->simUserGroup
      - Use DateTimeAspect everywhere
      - Introduce Language + Page Aspects
      - Introduce the context object into ContentObjectRenderer and cObjects
      - Use Contexts in RestrictionContainers
      - Use Contexts in TYPO3 Backend
      - Decouple sys_page behaviour from TSFE where applicable
      - Ensure TypoScript conditions continue to work / have a documented alternative
      Resolves: #85389
      Releases: master
      Change-Id: I9e27e581a1632fcd8c3c6a9e0954b76b91f42c52
      Reviewed-on: https://review.typo3.org/57104
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan.buerk@pure-metal.de>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan.buerk@pure-metal.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
  29. 22 Jun, 2018 1 commit
  30. 03 Jun, 2018 1 commit
  31. 30 May, 2018 1 commit
  32. 20 Feb, 2017 1 commit
  33. 16 Feb, 2017 1 commit
  34. 04 Feb, 2017 1 commit
  35. 03 Feb, 2017 1 commit
  36. 22 Dec, 2016 1 commit
  37. 02 Sep, 2016 1 commit
  38. 30 Aug, 2016 1 commit
  39. 05 Aug, 2016 1 commit