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. 21 Dec, 2020 1 commit
  2. 20 Dec, 2020 1 commit
  3. 14 Dec, 2020 1 commit
  4. 12 Dec, 2020 1 commit
  5. 10 Dec, 2020 1 commit
    • Benni Mack's avatar
      [!!!][FEATURE] Refactored Session Handling · 733353c1
      Benni Mack authored
      The AbstractUserAuthentication class handles way too much
      of what it should know / do.
      
      For this reason, a new UserSession object which contains
      basic information needed for everything belonging to a non-fixated
      session, a fixated anonymous session, if a session was evelated,
      or if a session has expired, is kept in there.
      The "SessionManager" should not be used anymore publically
      but slowly dissolve into a SessionBackendManager.
      
      Design goals:
      * UserAuth object should not know about session backends
      * UserAuth should not store sessionData etc. directly in its own object
      * Decouple UserSession info from any properties of UserAuth
      * A UserSessionManager deals with the creation and validation of the UserSession objects. No Session Objects can be created etc outside
      of this class to maintain persistability
      * UserSessionManager also encapsulates ipLocking and the responsible SessionBackend
      
      Final goals to be tackled later:
      * Build a user session object from the request object, and not within the UserAuth object
      * Session Handling can be accessed outside of UserAuth
      * Cookie Handling and Session Handling are separated from UserAuth
      * Load Session information from PSR-7 request instead of $_COOKIE
      
      Resolves: #93023
      Releases: master
      Change-Id: Ia2d8244e433d0f6adf220d443b2c0947f251b5e9
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66935
      
      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>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      733353c1
  6. 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>
      74899ecf
  7. 09 Nov, 2020 1 commit
  8. 19 Oct, 2020 2 commits
  9. 15 Oct, 2020 1 commit
  10. 14 Oct, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Drop 'recursive delete' backend user setting · f3e221a2
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      The 'you can not delete pages that have sub pages' user
      settings restriction has been annoying ever since. Users
      who actually want to delete a full tree were annoyed by
      this flag if they did not had it and had to rely on an
      administrator action to actually give it to them, and
      had to delete pages on a one-by-one base meanwhile.
      Clever admins thus often enabled that flag by default.
      
      It was meant as a feature to prevent casual users from
      commiting accidential harm to a site tree. There are
      better ways to achieve this goal however: Admins
      can set proper access rights for important key pages
      preventing editors from deleting them. Furthermore,
      a better 'prevent editors from doing harm in live'
      way is available by using the workspaces extension. And,
      in case of accidental deletion, admins can always
      resurrect full page trees using the recycler extension.
      
      The patch drops the 'recursive delete' option from
      specific user settings and always allows deleting
      pages including sub pages.
      
      Resolves: #92560
      Releases: master
      Change-Id: I8401edc10daece7f83d0c5f85f99129616fac957
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66136
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      f3e221a2
  11. 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
  12. 02 Oct, 2020 1 commit
  13. 25 Sep, 2020 1 commit
  14. 23 Sep, 2020 4 commits
  15. 22 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Deferred reference index updating · c333efe9
      Christian Kuhn authored and Georg Ringer's avatar Georg Ringer committed
      Within DataHandler processing, updating the reference index
      is an expensive task since it needs tons of queries to do
      the job.
      
      With DataHandler instances and it's sub instances created
      for relations and localizations, the code tends to update the
      reference index for the same table/uid combination multiple times:
      As example, core test IRRE/ForeignField/Modify copyParentContent()
      copies a content element with one hotel, one offer and one price
      around. This leads to 3 update reference index calls for the
      tt_content element, 4 for the hotel, 4 for the offer and 3 for
      the price.
      Of course, the situation is worse in workspaces.
      
      There have been various attempts over the years to reduce the
      query load, usually by adding runtime caches everywhere.
      
      With proper sys_refindex functional test coverage in place, we
      can however finally solve the root problem: The patch adds the
      helper object ReferenceIndexUpdater to fill a registry with
      to-update workspace/table/uid combinations. The object is carried
      around within DataHandler and RelationHandler to DataHandler sub
      instances. Only the outer most instance of a DataHandler then
      finally executes the update() operations in one go and only
      once per combination.
      
      The patch tries to be rather conservative to allow a 10.4 backport.
      For master, there should be further mess-reducing cleanup patches
      to streamline related parts of the ReferenceIndex update process.
      
      Result: The DataHandler query load is reduced significantly. It
      heavily depends on the structure that is changed, to get an idea,
      the above test goes down from 448 queries to 346 queries!
      
      Change-Id: I49f5ed73114ca5d6e2cb75fa43846bde5ea72d26
      Resolves: #92356
      Related: #88134
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65796
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      c333efe9
  16. 20 Sep, 2020 1 commit
  17. 19 Sep, 2020 1 commit
  18. 18 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Separate 'delete' and 'discard' in DataHandler · 01e2c1e6
      Christian Kuhn authored
      There are 4 "drop record" scenarios in workspaces:
      * Delete a new or changed record in list/page module
      * Create a delete placeholder in list/page module to mark a
        live record as to-be-deleted on workspace publish
      * Discard (throw away) a change in workspace module
      * Flush all workspace changes by deleting a sys_workspace
        record.
      
      All these scenarios are handled with the same DataHandler
      code which leads to tons of bugs since especially
      "delete & create delete placeholder" compared to
      "discard & flush" are logically different things.
      
      The patch separates discard and flush to a new codebase.
      First patch sets started with a 1:1 copy of the delete code,
      then carefully refactored the code to its final state. The
      roughly 850 lines of delete code are streamlined to about
      300 lines for discard and flush. The code is much easier
      to follow, recursions are simplified and access checks are
      in one place.
      
      Discard previously created a mixture of hard and soft deleted
      records in the database, leading to a huge mess. This changed:
      Discard now always means that records are dropped from database.
      
      The discard code now properly cascades down into relations,
      solving tons of bugs along the way. The functional DataHandler
      tests are refactored and heavily extended to cover discard.
      Two previously existing issues are not fixed yet: ManyToMany
      relations are not properly cleaned up on discard, and discarding
      does not fully follow localization overlays in 'connected' mode.
      Those scenarios are marked with @todo's in the .csv files and
      should be relatively easy to solve with dedicated single patches.
      
      Change-Id: Ie33dd2bdc333a4d8ed9314b7520212cc11942c89
      Resolves: #85778
      Resolves: #92336
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65638
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      01e2c1e6
  19. 11 Sep, 2020 1 commit
  20. 03 Sep, 2020 2 commits
  21. 26 Aug, 2020 1 commit
  22. 10 Aug, 2020 1 commit
  23. 06 Aug, 2020 1 commit
  24. 04 Aug, 2020 1 commit
  25. 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
  26. 31 Jul, 2020 1 commit
  27. 25 Jul, 2020 1 commit
  28. 07 Jul, 2020 1 commit
    • Johannes Schlier's avatar
      [BUGFIX] Handle null values correctly to avoid PHP errors · 25871186
      Johannes Schlier authored and Benni Mack's avatar Benni Mack committed
      The new RteHtmlParser->transformTextForPersistence() method
      expects a string value. Before this patch the given value
      was simply passed without checking its type or casting it.
      
      However, if "null" is handed in (by e.g. a translated record which
      expects null), null is now kept.
      
      Resolves: #91749
      Releases: master, 10.4
      Change-Id: I9db872ca73dcf2bbfc2ac2d0b67d45ca3ffd4c5e
      25871186
  29. 30 Jun, 2020 1 commit
  30. 29 May, 2020 1 commit
  31. 11 May, 2020 1 commit
    • David König's avatar
      [BUGFIX] Correctly evaluate "unique" eval for slug fields · f1a8ae98
      David König authored and Helmut Hummel's avatar Helmut Hummel committed
      TYPO3 v9.5.16, fixed functionality for URL resolving
      for records with slug fields defined as "uniqueInSite".
      With such setting, it is important to limit URL resolving
      to the site the slugs are generated for. Because we currently
      don't support records to be stored within one site, but
      generating slugs for another one, this change enforced the storage
      of news records to be in the same site as the detail page.
      
      This however led to not working installations, where a record storage
      folder is available in a site where other sites are fetching this
      information from, which is a quite common use case.
      
      To cover such use case, TCA needs to be adapted to the existing configuration
      eval=unique, which diables the site check in URL frontend resolving.
      However the current implementation of DataHandler only checks uniqueness
      of fields of type "input".
      
      This means for slug fields, the functionality of 'unique'
      is currently not taken into account when generating the slug,
      which can lead to duplicate slugs.
      To fix this problem, a check for the unique eval setting is added to
      DataHandler and FormSlugAjaxController. SlugHelper is adapted
      to correctly generate slugs for this use case.
      
      Resolves: #91235
      Releases: master, 9.5
      Change-Id: Id6e5c1d27860b09604787132f2cd83976418baa4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64428
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Henrik Ziegenhain's avatarHenrik Ziegenhain <henrik@ziegenhain.me>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      f1a8ae98
  32. 30 Apr, 2020 1 commit
  33. 21 Apr, 2020 1 commit
  34. 17 Apr, 2020 2 commits