1. 05 May, 2021 2 commits
  2. 21 Dec, 2020 1 commit
    • Imko Schumacher's avatar
      [BUGFIX] Set timezone on TCA dbType input · bd55644a
      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
      specifier.
      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/+/67201
      
      
      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>
      bd55644a
  3. 10 Aug, 2020 1 commit
  4. 27 Jul, 2020 1 commit
  5. 19 May, 2020 1 commit
  6. 14 May, 2020 1 commit
  7. 11 May, 2020 1 commit
    • David König's avatar
      [BUGFIX] Correctly evaluate "unique" eval for slug fields · d3297faa
      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/+/64455
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      d3297faa
  8. 30 Apr, 2020 1 commit
  9. 27 Apr, 2020 1 commit
  10. 12 Apr, 2020 1 commit
    • Christian Eßl's avatar
      [BUGFIX] Keep language or colPos when moving a record in list module · f6016b3d
      Christian Eßl authored and Anja Leichsenring's avatar Anja Leichsenring committed
      When copying a tt_content record in list module, the DataHandler would
      internally look up the 'copyAfterDuplFields' settings in TCA and ensure,
      that those fields are copied from its new neighboring record.
      
      In TYPO3 core, the 'copyAfterDuplFields' settings are only used by the
      table tt_content with 'colPos,sys_language_uid' as its values.
      
      This makes sense for copying records, but the same behaviour, that stems
      from TYPO3s very early days, was also used when records where moved
      around with the DataHandler. When an editor changes the position of a
      tt_content record in the list module, the record would then always
      automatically adopt the colPos/sys_language_uid of its new neighbour,
      which is usually not expected or desired, and often leads to much
      confusion and broken content grids.
      
      The code responsible for 'copyAfterDuplFields' is now removed from
      DataHandler::moveRecord_raw(), while retaining the behaviour for
      DataHandler::copyRecord(). Moving around tt_content records in the
      page module to different columns or languages is not affected by this
      change, as the colPos/sys_language_uid changes there are set in a
      separate update statement.
      
      Resolves: #72988
      Resolves: #59901
      Resolves: #39798
      Resolves: #25216
      Resolves: #14873
      Releases: master, 9.5
      Change-Id: Ic9c57fe2712b0996bc7b53cce4bcdc275c2820cb
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64137
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      f6016b3d
  11. 24 Mar, 2020 1 commit
  12. 20 Mar, 2020 1 commit
  13. 15 Mar, 2020 2 commits
  14. 09 Mar, 2020 1 commit
  15. 27 Feb, 2020 1 commit
  16. 27 Jan, 2020 2 commits
  17. 18 Jan, 2020 1 commit
  18. 16 Jan, 2020 1 commit
  19. 22 Nov, 2019 1 commit
  20. 20 Nov, 2019 1 commit
  21. 07 Oct, 2019 1 commit
  22. 10 Sep, 2019 1 commit
  23. 30 Aug, 2019 1 commit
  24. 28 Aug, 2019 1 commit
  25. 12 Jul, 2019 1 commit
  26. 25 Jun, 2019 1 commit
  27. 19 Jun, 2019 1 commit
  28. 07 May, 2019 1 commit
  29. 06 May, 2019 1 commit
    • Benni Mack's avatar
      [BUGFIX] Unhide page translations by default · 06c6c1eb
      Benni Mack authored and Richard Haeser's avatar Richard Haeser committed
      In TYPO3 v8, new page translations within pages_language_overlay
      were visible by default when using plain DataHandler.
      
      In TYPO3 v9, due to the merge into "pages" for translations,
      the default value for "hidden" is used. Every new page translation
      is now hidden by default - this is a different behavior.
      
      Tests had to be modified to make this work again. However,
      the change now removes the "hacks" within the tests,
      and adds the functionality to take-over the "hidden" flag
      from the default record.
      
      For future TYPO3 major versions, the hidden field could be migrated
      into a "allowLanguageSynchronization" once the Context API
      is used throughout Core properly.
      
      Resolves: #88248
      Releases: master, 9.5
      Change-Id: I2a684a0d4225451c3fbfc0021c09935c1224aaca
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60636
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Richard Haeser's avatarRichard Haeser <richard@maxserv.com>
      Reviewed-by: Richard Haeser's avatarRichard Haeser <richard@maxserv.com>
      06c6c1eb
  30. 29 Apr, 2019 2 commits
  31. 03 Apr, 2019 1 commit
  32. 07 Mar, 2019 2 commits
  33. 04 Mar, 2019 1 commit
  34. 01 Mar, 2019 2 commits