Skip to content
Snippets Groups Projects
  1. Apr 08, 2024
    • Stefan Bürk's avatar
      [BUGFIX] Ensure working count query in `DatabaseRecordList::getTable()` · 6ec3eb49
      Stefan Bürk authored
      `\TYPO3\CMS\Backend\RecordList\DatabaseRecordList` provides the ability
      to modify the QueryBuilder used for the record list representation with
      $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][DatabaseRecordList::class]['modifyQuery']
      after generic query information like default orderings and similar have
      been added.
      
      That is covered within the `getQueryBuilder()` method, which is used in
      other class methods, for example in `getTables()` where it is changed
      to a `COUNT()` query.
      
      MariaDB for example is picky about count queries using `order by`,
      `group by` or aggregation methods which are not reflected or added
      in the counter parts leading to a not so useful error like
      
        Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP
        columns is illegal if there is no GROUP BY clause
      
      or similar variants. This error message can be missleading for the
      case a order by has been used along with a COUNT() query.
      
      Hook consumer do not get the information if order-by can be added
      or should be left out, therefore maybe adding sorting conditions
      for a count query.
      
      This change now resets any order statements for the count-query
      like other places in the TYPO3 core.
      
      Resolves: #103427
      Releases: main, 12.4, 11.5
      Change-Id: Ie421993a1890dd6682d02f54203d538e6ae1b76c
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83524
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarGarvin Hicking <gh@faktor-e.de>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarGarvin Hicking <gh@faktor-e.de>
      6ec3eb49
  2. Apr 07, 2024
    • Markus Klein's avatar
      [BUGFIX] Use correct timezones with timestamp based \DateTime · f66272ae
      Markus Klein authored
      As documented by PHP, `\DateTime` or `\DateTimeImmutable`
      objects created with a timestamp only ('@12345678') as the
      first constructor argument will use UTC as TimeZone.
      
      Creating an object instance without any constructor arguments
      will use the `date_default_timezone_get()` timezone for the
      object - and setting the timestamp using `setTimestamp()` will
      not change the object's timezone.
      
      That means, that formatting the value will be done using
      the object Timezone and **NOT** the default PHP Timezone
      (`date_default_timezone_get()`).
      
      Consequently, this may lead to wrong interpretation of
      the displayed formatted value in the context of another
      timezone - if no timezone information (+0000/-0100) is
      included.
      
      This change streamlines this for a couple of places were
      it is expected to format date, datetime or time values
      for the current context timezone by ensuring objects get
      the current timezone set instead of `UTC`.
      
      Note: Changing the date default timezone on the fly after
      an object has been created will show a similar effect like
      using constructor values, even if the object has been
      created by using the `setTimestamp()` method.
      
      [1] https://3v4l.org/sGEe2
      
      Resolves: #98045
      Resolves: #99627
      Releases: main, 12.4, 11.5
      Change-Id: I095a0b0b376361e25396647d02727ac08f35cae0
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83684
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      f66272ae
  3. Apr 05, 2024
  4. Apr 04, 2024
  5. Mar 23, 2024
  6. Mar 22, 2024
  7. Mar 20, 2024
  8. Mar 19, 2024
  9. Mar 17, 2024
  10. Mar 15, 2024
  11. Mar 12, 2024
  12. Mar 11, 2024
  13. Mar 10, 2024
  14. Mar 09, 2024
  15. Mar 08, 2024
  16. Mar 07, 2024
  17. Mar 06, 2024
  18. Mar 05, 2024
    • Benjamin Franzke's avatar
      [TASK] Allow execution of acceptance tests with local chromedriver · a598d0c2
      Benjamin Franzke authored
      A local instance can sometimes be easier to debug and browser issues
      can be introspected, when acceptance tests are possible to be run on
      the host instead of in containers only.
      
      Allow to run acceptance tests against a local server using a local
      chromedriver. Also avoid the usage of precalculated session hashes,
      which has no clear advantage, but requires codecept to perform
      database connections directly: The tests now login via the backend
      login form instead and store the session cookies between test runs.
      
      As a side effect the codeception suites are cleaned up, to use
      more efficient module config, instead of redundantly repeating
      all WebDriver settings for headless and non-headless environment.
      
      To execute codeception with local chromedriver against a custom
      server URL run:
      
        chromedriver --silent & # use `killall chromedriver` when done
      
        typo3TestingAcceptanceBaseUrl=https://mycore.example.com/ \
        typo3TestingAcceptanceAdminPassword=...
      a598d0c2
  19. Mar 04, 2024