Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
  • Daniel Hürtgen Daniel Hürtgen higidi
  • Jenkins Jenkins jenkins
  • **** **** project_53_bot
3 authors
  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
  3. 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
  5. Apr 05, 2024
  7. Apr 04, 2024
  9. Mar 23, 2024
  11. Mar 22, 2024
  13. Mar 20, 2024
  15. Mar 19, 2024
  17. Mar 17, 2024
  19. Mar 15, 2024
  21. Mar 12, 2024
  23. Mar 11, 2024
  25. Mar 10, 2024
  27. Mar 09, 2024
  29. Mar 08, 2024
  31. Mar 07, 2024
  33. Mar 06, 2024
  35. 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
  37. Mar 04, 2024