Feature #23493: adding second parameter to $hookObj->execFinalQuery_idList - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Feature #23493

closed

adding second parameter to $hookObj->execFinalQuery_idList

Added by Adrian Föder about 14 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

Start date:

2010-09-02

Due date:

% Done:

Estimated time:

PHP Version:

Tags:

Complexity:

Sprint Focus:

Description

in extension's pi class, there are the lines

// Calling hook for alternative creation of page ID list
        if ($hookObj = $this->hookRequest('execFinalQuery_idList')) {
            $page_where = $hookObj->execFinalQuery_idList($list);
        }

It would be very useful to add '$page_join' as second parameter, so that it reads

$page_where = $hookObj->execFinalQuery_idList($list, $page_join);

The second parameter then could be passed by reference and modified at the hook's inside function.
It makes sense to allow not only the modification of $page_where but also $page_join.

Another possibility to make sure downward compatibility could be something like

$hookRet = $hookObj->execFinalQuery_idList($list);
            if(is_array($hookRet)) {
                list($page_where, $page_join) = $hookRet
            } else { 
                $page_where = $hookRet;
            }

Best,
Adrian

(issue imported from #M15623)

Actions

Copy link

Updated by Dmitry Dulepov about 14 years ago

We definitely cannot modify the return value because it will break all existing hooks. We can add the second parameter. Can you tell more when it will be useful to have?

Actions

Copy link

Updated by Adrian Föder about 14 years ago

Hi Dmitry and thank you very much for your response,

the answer is quite simple; we would like to join the "pages" table into the query (in our specific case we would like to exclude all search matches where pages.content_from_pid="" to avoid doubled search hits)

So our usage of the hook returns something like

pages.uid = ISEC.page_id AND pages.content_from_pid=""'

but this requires the table "pages" being named in the tables-section of the query and therefore $page_join being extendes with ", pages".

Please have a look at the code of the IS' pi, it should be very obvious that it would make sense to allow modifying the where and the join-Section at the same time.

Breaking all existing hooks is not guaranteed; because the hook functionality is intended to return a string so far.
When returning an array it is implied that the "new" function of the hook is meant (see my example).

Thanks and best,

Adrian

Actions

Copy link