Project

General

Profile

Actions

Bug #90607

closed

Useless $parameters variable in "modifyQuery" hooks

Added by Christian Eßl about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2020-03-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The following classes use the new "modifyQuery" hooks since TYPO3 9.4:
  • \TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList
    uses $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][DatabaseRecordList::class]['modifyQuery']
  • \TYPO3\CMS\Backend\View\PageLayoutView
  • \TYPO3\CMS\Backend\View\BackendLayout\ContentFetcher (new Replacement for PageLayoutView)
    use $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][PageLayoutView::class]['modifyQuery']

All of these hooks use a $parameters argument, which is never used at all.

The one in DatabaseRecordList holds the following values:

$parameters = [
            'table' => $table,
            'fields' => $fieldList,
            'groupBy' => null,
            'orderBy' => null,
            'firstResult' => $this->firstElementNumber ?: null,
            'maxResults' => $this->iLimit ?: null
        ];

$table and $fieldList are already assigned as separate arguments to modifyQuery(). Only the 'firstResult' and 'maxResults' are actually useful in the hook as information.

But in both the hooks for PageLayoutView and ContentFetcher $parameters only holds this information:

$parameters = [
            'table' => $table,
            'fields' => $fields,
            'groupBy' => null,
            'orderBy' => null
        ];

Which makes the $parameters array for both of these hooks completely useless and misleading.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Epic #88027: Properly handle Hooks/Signals and EventsClosedBenni Mack2022-04-22

Actions
Actions #1

Updated by Christian Eßl about 4 years ago

  • Category set to Backend API
Actions #2

Updated by Christian Eßl about 4 years ago

  • Related to Epic #88027: Properly handle Hooks/Signals and Events added
Actions #3

Updated by Christian Eßl about 4 years ago

Of course this can't be changed now, as this would break things, but this should be considered to be dropped, once these hooks are migrated to PSR-14 events. That's why I added the related epic.

Actions #4

Updated by Susanne Moog about 4 years ago

  • Status changed from New to Closed

Actually, they are both only there for compat reasons as they were in use when the new hooks were introduced (though even then deprecated). In 'buildQueryParameters' they have been separately deprecated and removed already.

For the other usages: I'd rather wait for PSR-14 to refactor all hooks (when introducing events we also take a look at which parameters actually make sense) - and I would rather not have tickets for each one (similar to the signal slot dispatcher patches I'd prefer if that's done extension-by-extension).

I'll close this one for those reasons now.

Actions

Also available in: Atom PDF