1. 21 Dec, 2020 1 commit
    • Imko Schumacher's avatar
      [BUGFIX] Set timezone on TCA dbType input · 6b0be8e1
      Imko Schumacher authored and Benjamin Franzke's avatar Benjamin Franzke committed
      The value from columns that are marked as "dbType" date(time) fields
      in TCA configuration are now explicitly interpreted using UTC timezone,
      when the string value has no timezone specifier given.
      JS supplied values contain Z as specifier, while records from the database
      (which are processed during copy operations) do not contain a timezone
      Local time was assumed by PHP in the latter case before, as we did not
      pass an explicit timezone information to the DateTime constructor.
      Therefore we now assure no timezone conversion will happen and no
      time/date-offset will be added, by using UTC explicitly.
      Resolves: #89914
      Releases: master, 10.4, 9.5
      Change-Id: I8e531ae5f3367c4493ce1e7db4bec0ef02311e24
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67200
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
  2. 20 Dec, 2020 1 commit
  3. 12 Dec, 2020 1 commit
  4. 09 Nov, 2020 1 commit
  5. 19 Oct, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Workspace and reference index fixes · cd94f3dd
      Christian Kuhn authored
      This drops all left over calls that suppress the refindex
      integrity checks in DataHandler functional tests, except those
      within ManyToMany tests: This area needs more work before the
      reference index can be fixed.
      Two bugs indirectly related to the reference index are fixed
      along the way, those can't be separated as standalone patches:
      * When a translated page is deleted in workspaces, the
        DataHandler deleted live records on this page, too. This
        is fixed by adding a proper db restriction. This also
        fixes the reference index state in this scenario.
      * When publishing a delete placeholder that has inline children,
        workspace delete placeholders are created for the children, which
        is wrong. This happens because the user is not set to the live
        workspace during the publish operation. Temporarily changing the
        user workspace to live not only fixes the reference index, but
        does not create the bogus inline children placeholder records
        anymore, too.
      Change-Id: I897f6a93b1d5a579bfa5c52e93e65119a018e4aa
      Resolves: #92589
      Related: #92467
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66168
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  6. 02 Oct, 2020 1 commit
  7. 27 Sep, 2020 1 commit
  8. 23 Sep, 2020 4 commits
  9. 22 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Deferred reference index updating · 29c821b8
      Christian Kuhn authored
      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/+/65816
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  10. 20 Sep, 2020 1 commit
  11. 19 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Skip sys_refindex for workspace placeholders · 8457e825
      Christian Kuhn authored
      The reference index can be seen as a cache for relations.
      It is used in various places to show how many other records
      have a relation to a given record, for instance in list
      and filelist module and in the record info modal.
      In workspaces, new and moved records create records pairs:
      t3ver_state -1 & 1 and t3ver_state 3 & 4. The backend
      always shows only one of these pairs. The reference index
      creates an entry for each record, so two for each pair.
      This is useless and confusing for editors: If for instance
      a new file reference is added to a content element in
      workspaces, the file list shows two usages of the file
      instead of only one.
      The patch suppresses reference index entries for the
      placeholder records - t3ver_state 1 and 3 - so each pair
      ends up with only one sys_refindex entry.
      Resolves: #92345
      Related: #61917
      Releases: master, 10.4
      Change-Id: I16ede3a9f1b66a7195526a224e9f1c43c03d7ba6
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65782
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  12. 18 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Separate 'delete' and 'discard' in DataHandler · 2e037b7c
      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
      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/+/65766
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  13. 03 Sep, 2020 1 commit
  14. 28 Aug, 2020 1 commit
  15. 10 Aug, 2020 1 commit
  16. 06 Aug, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Allow moving a workspace record after itself · 37fb5ba1
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      Another 'broken since ever' fix: Sorting a record in
      workspaces by moving it 'after itself', the record vanishes
      from the interface. While this action is kinda useless,
      it can for instance accidently happen by an editor.
      As with other move operations in workspaces, a move
      placeholder and the versioned data record is created.
      In case of inserting after itself, the move placeholder
      state is not correctly updated - both pid and sorting
      values end up with 0. The records then no longer belong
      to the correct pid and are not 'seen' by workspaces.
      The patch fixes this case by making sure the pid and sorting
      determination of the move placeholder does not accidently
      operate on itself as reference record. A series of functional
      DataHandler tests nail the correct state for pages and
      tt_content in non-workspace and workspace scenarios.
      Resolves: #53619
      Releases: master, 10.4
      Change-Id: I39b5e9f72bd05645dcd429bed3833d2a792efaec
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65171
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  17. 04 Aug, 2020 1 commit
  18. 25 Jul, 2020 1 commit
  19. 07 Jul, 2020 1 commit
    • Johannes Schlier's avatar
      [BUGFIX] Handle null values correctly to avoid PHP errors · e5d157de
      Johannes Schlier authored and Oliver Hader's avatar Oliver Hader 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
  20. 30 Jun, 2020 1 commit
  21. 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>
  22. 30 Apr, 2020 1 commit
  23. 21 Apr, 2020 1 commit
  24. 17 Apr, 2020 2 commits
  25. 15 Apr, 2020 2 commits
  26. 14 Apr, 2020 3 commits
  27. 12 Apr, 2020 1 commit
  28. 06 Apr, 2020 1 commit
  29. 24 Mar, 2020 2 commits
  30. 20 Mar, 2020 1 commit
  31. 19 Mar, 2020 1 commit
  32. 15 Mar, 2020 1 commit