Feature: Change the project lists by event 

Description 

\FGTCLB\AcademicProjects\Event\ModifyProjectDemandEvent and \FGTCLB\AcademicProjects\Event\ModifyProjectListEvent are PSR-14 events dispatched by both project list plugins.

The demand event fires after the demand has been built from the content element settings and the request and before the projects are queried; the demand a listener hands back is the one that is queried and assigned to the view. The list event fires after the query and before the view variables are assigned; a listener replaces the projects, replaces the applicable categories, or assigns further view variables.

Both carry \FGTCLB\AcademicBase\Domain\Model\Dto\PluginControllerActionContextInterface , so a listener knows the request, the site, the content element, its settings and which of the two list plugins is rendering.

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use FGTCLB\AcademicProjects\Event\ModifyProjectDemandEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;

final class ShowRunningProjectsOnly
{
    #[AsEventListener(identifier: 'my-extension/show-running-projects-only')]
    public function __invoke(ModifyProjectDemandEvent $event): void
    {
        if ($event->getPluginControllerActionContext()->getPluginName() === 'ProjectList') {
            $event->getDemand()->setActiveState('active');
        }
    }
}

Impact 

Nothing changes in an installation that has no listener. A project that subclasses ProjectController to adjust the demand, the result or the view variables listens instead, and drops the subclass and the plugin re-registration that goes with it. The controller is final in 3.0, so the subclass no longer loads, see Breaking: The project controller is final.

One detail is worth knowing: the applicable categories are computed once, before the list event, and not recomputed afterwards - a listener that replaces the projects and wants the filter to match them sets the categories as well.