---
title: "ChooseProfileFactoryEvent"
manual: "Academic Profiles"
version: "main"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-persons:developers-event-choose-profile-factory-event@main"
source: "Developers/Events/ChooseProfileFactoryEvent.rst"
rendered: "2026-10-15T10:24:29+00:00"
---

# ChooseProfileFactoryEvent {#developers-event-choose-profile-factory-event}

`\FGTCLB\AcademicPersons\Event\ChooseProfileFactoryEvent` lets a listener
choose the profile factory that creates or updates the profiles of a frontend
user in the frontend user synchronisation. Without a listener, the default
factory `\FGTCLB\AcademicPersons\Profile\ProfileFactory` does it.

Before a factory of its own, check whether a listener of the mapping events is
enough, see [Taking part in the frontend user synchronisation](https://docs.typo3.org/permalink/fgtclb/academic-persons:developers-frontend-user-sync-events@main): a factory replaces the
default one as a whole, and does not pick up later fixes to it.

## When it is dispatched {#when-it-is-dispatched}

The commands `academic:createprofiles` and
`academic:updateprofiles` dispatch the event once for every frontend user
they process, after the environment of the frontend user's site is set up and
before anything else happens for that user. The factory the event names is then
asked whether it creates or updates profiles for the user at all, and does it.
It is the first step of the run described in
[Taking part in the frontend user synchronisation](https://docs.typo3.org/permalink/fgtclb/academic-persons:developers-frontend-user-sync-events@main).

## What a listener reads and changes {#what-a-listener-reads-and-changes}

| Method | What it does |
| --- | --- |
| `getFrontendUserAuthentication()` | The frontend user, with its record in `$user` and its groups fetched. |
| `getAction()` | `ProfileActionType::Create` for `academic:createprofiles`, `ProfileActionType::Update` for `academic:updateprofiles`. |
| `getProfileFactory()` | The factory a listener before chose, or `null`. |
| `setProfileFactory()` | Chooses the factory, an implementation of `\FGTCLB\AcademicPersons\Profile\ProfileFactoryInterface`. |

## Example {#example}

A site keeps the frontend users of its staff directory on one storage folder
and builds their profiles with a factory of its own, which reads a directory
service. Every other frontend user keeps the default factory:

**EXT:my_sitepackage/Classes/EventListener/ChooseDirectoryProfileFactory.php**

```php
<?php

declare(strict_types=1);

namespace MyVendor\MySitepackage\EventListener;

use FGTCLB\AcademicPersons\Event\ChooseProfileFactoryEvent;
use MyVendor\MySitepackage\Profile\DirectoryProfileFactory;
use TYPO3\CMS\Core\Attribute\AsEventListener;

final readonly class ChooseDirectoryProfileFactory
{
    private const STAFF_DIRECTORY_FOLDER = 42;

    public function __construct(
        private DirectoryProfileFactory $directoryProfileFactory,
    ) {}

    #[AsEventListener(identifier: 'my-sitepackage/choose-directory-profile-factory')]
    public function __invoke(ChooseProfileFactoryEvent $event): void
    {
        $frontendUser = $event->getFrontendUserAuthentication()->user ?? [];
        if ((int)($frontendUser['pid'] ?? 0) !== self::STAFF_DIRECTORY_FOLDER) {
            return;
        }
        $event->setProfileFactory($this->directoryProfileFactory);
    }
}
```

`DirectoryProfileFactory` extends
`\FGTCLB\AcademicPersons\Profile\AbstractProfileFactory`, so the mapping
events are dispatched for its profiles as well. How such a factory is built is
described in [Custom profile factories](https://docs.typo3.org/permalink/fgtclb/academic-persons:configuration-frontend-user-sync-factories@main).

## Rules and pitfalls {#rules-and-pitfalls}

-   The last listener that calls `setProfileFactory()` wins. A listener
    that only chooses for some frontend users returns early for the others and
    leaves the choice of a listener before it alone.
-   A factory that implements `ProfileFactoryInterface` directly, without
    extending `AbstractProfileFactory`, dispatches neither
    `BeforeProfileMappedFromFrontendUserEvent` nor
    `AfterProfileMappedFromFrontendUserEvent`, and announces nothing
    unless it dispatches `AfterProfileUpdateEvent` itself.
-   A chosen factory may ignore the extension configuration that makes the
    default factory create profiles at all.
-   Listeners are shared services, one object for the whole run. Keep nothing
    of one frontend user in a property of the listener.

## Introduced in {#introduced-in}

The event is part of the extension since its first release. Later changes:

-   [Feature: Events to add data to the synchronisation and adjust profiles](https://docs.typo3.org/permalink/fgtclb/academic-persons:feature-frontend-user-sync-data-events@main) added the mapping events,
    which make a factory of its own unnecessary for most projects.
-   [Important: Profile create and update commands refuse wrong page lists](https://docs.typo3.org/permalink/fgtclb/academic-persons:important-ace-845-academic-persons@main) (2.4) names the default factory
    in the hint the commands print.
