ModifyPartnerDemandEvent 

When it is dispatched 

In PartnerController::listAction() and PartnerController::mapAction() , on every request that renders one of the two content elements, after the demand is built and before the partners are queried. The demand then holds:

• the storage pages of Startingpoint,
• the choice of Show hidden records,
• the sorting and the categories the visitor selected, or, on a request without a selection of the visitor, those of Default sorting and Default categories,
• and in the list, the page the visitor asked for.

The list reads the page and the arguments its page links carry before this event. The map restricts the demand to the partners it can draw after this event. Neither content element dispatches the event for the POST of the filter form, which is answered with a redirect first, and the partnership content elements do not dispatch it at all.

What a listener reads and changes 

The demand offers:

Example 

A site does not want hidden partners on its maps, whatever an editor switches on in a content element. The partner list may still show them. A listener switches showHiddenRecords off for the map:

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use FGTCLB\AcademicPartners\Event\ModifyPartnerDemandEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;

final class KeepHiddenPartnersOffTheMap
{
    #[AsEventListener(identifier: 'my-extension/keep-hidden-partners-off-the-map')]
    public function __invoke(ModifyPartnerDemandEvent $event): void
    {
        // The plugin name the map is registered with, not the CType.
        if ($event->getPluginControllerActionContext()->getPluginName() !== 'Map') {
            return;
        }
        $event->getDemand()->setShowHiddenRecords(false);
    }
}

A listener that restricts the partners to one storage folder instead sets the pages. setPages() becomes pid IN (...) , so this is one folder and not a page tree:

$event->getDemand()->setPages([42]);

Rules and pitfalls 

A replaced demand starts from the defaults. setDemand() is there for a listener that builds its own demand, and such a demand carries none of what the plugin put in the one it was handed: the storage pages and the showHiddenRecords choice of the editor, and the two the visitor can set themselves through the filter form, the sorting and the filterCollection . A replacement therefore resets the ordering and the category filter under them. Mutate the demand where that is enough, and carry getPages() , getShowHiddenRecords() , getFilterCollection() and getSorting() over where it is not.

The page is not the listener's. The page, and the filter and sorting the page links carry, are read from the demand the request asked for, before the demand event, as the filter redirect reads its URL. A listener that replaces the demand therefore keeps the page the visitor asked for, and a listener cannot choose the page. What a listener changes does not travel in the page links: it acts again on the request a link leads to.

The form shows what the listener set. The demand a listener hands back is the one assigned to the view, so the filter form shows its categories as selected and its sorting as chosen, and the active filter tags list its categories.

Introduced in 

• Feature: Change the partner list and map by event introduced the event.
• Breaking: The partner controller is final made the controller final, the event replaces a subclass that changed the filter or the sorting.
• Feature: Partner filter selections have a URL moved the filter submission to a redirect, which is why the event never sees the POST of the form.