AfterProfileUpdateEvent 

When it is dispatched 

• After a profile is auto-created for a frontend user ( AbstractProfileFactory::createProfileForUser() , also reached by the academic:createprofiles command).
• After a profile is updated from its frontend user record ( AbstractProfileFactory::updateProfileForUser() , command academic:updateprofiles ), per profile the update runs through, even when every value already matched. A profile whose skip_sync flag is set, or that a listener of BeforeProfileMappedFromFrontendUserEvent skips, is neither updated nor announced.
• By EXT:academic_persons_edit after every persisting frontend edit action.
• After a DataHandler save of a live, default-language profile: the backend form, and any code that writes profiles through the DataHandler. Every default-language profile in the run's datamap is announced once per run, after all of the run is written. Saves of translations alone, saves in a workspace, commands such as copy, move or localize, and a save of only a child record, such as a contract edited on its own, are not announced.

What a listener reads 

The event is read only. Besides the profile it carries the site the profile belongs to, and the origin of the update:

The case set of ProfileUpdateOrigin is fixed, so a listener may match over it exhaustively.

The extensions register three listeners of their own, which a project listener orders itself against with the before and after arguments of #[AsEventListener] :

Example 

A site renders the profiles in a view of its own, a teaser element for example, and tags the cached pages with my_profile_teaser_<uid>. The listener flushes them whenever a profile changes, whatever changed it:

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use FGTCLB\AcademicPersons\Event\AfterProfileUpdateEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Cache\CacheManager;

final readonly class FlushProfileTeasers
{
    public function __construct(
        private CacheManager $cacheManager,
    ) {}

    #[AsEventListener(identifier: 'my-extension/flush-profile-teasers')]
    public function __invoke(AfterProfileUpdateEvent $event): void
    {
        $profileUid = (int)$event->getProfile()->getUid();
        $this->cacheManager->flushCachesInGroupByTag('pages', 'my_profile_teaser_' . $profileUid);
    }
}

The pages of the plugins of this extension are flushed by the extension itself.

Rules and pitfalls 

The dispatch contract, for code that dispatches the event itself:

• The event carries the persisted default language profile: its getUid() returns a real uid, and the record is not a translation overlay. Listeners read the database, not the object, so all changes must be persisted before dispatching.
• The site is optional. Without one the synchronisation listener of EXT:academic_persons_edit determines it from the site of the global request, then from the pid, and skips the event silently when it cannot. An event of origin ProfileUpdateOrigin::Backend or ProfileUpdateOrigin::Import without a site is not synchronised at all: the DataHandler hook passes none only when the profile's page belongs to no site, and the site of a backend request is the one of the page selected in the page tree.
• A project that dispatched the event from its own DataHandler hook to have backend saves synchronised must remove that hook: the save is announced by this extension now, and the hook would announce it a second time.

For a listener:

• A large import is announced profile by profile, synchronously, in the request that writes it. A listener that does expensive work recognises an import by the origin ProfileUpdateOrigin::Import and defers it.
• A listener that writes profiles through the DataHandler marks its run as ProfileWriteCorrelation::Internal , see below, or its write is announced again.

use FGTCLB\AcademicPersons\DataHandling\ProfileWriteCorrelation;
use TYPO3\CMS\Core\DataHandling\DataHandler;
use TYPO3\CMS\Core\Utility\GeneralUtility;

$dataHandler = GeneralUtility::makeInstance(DataHandler::class);
$dataHandler->start($datamap, []);
$dataHandler->setCorrelationId(ProfileWriteCorrelation::Import->create());
$dataHandler->process_datamap();

Introduced in 

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

• Important: A created profile is translated again (2.4) synchronises a created profile into its translations again.
• Feature: Profile updates from user data announce themselves announces the updates of academic:updateprofiles .
• Important: Backend saves announce profile updates announces backend saves and imports.
• Feature: The profile update event carries the site and the origin added the site and the origin.