AfterProfileUpdateEvent 

When it is dispatched 

The profile editing dispatches the event once after each write it stored, of the profile and of everything that belongs to it:

• a field of the profile, one or all of them,
• the synchronisation switch and the visibility switch,
• the upload and the removal of the profile image,
• the creation, update, hiding, deletion and sorting of a document, a contract or a profile information entry, and of a contact of a contract.

The event comes after the write is stored, and after the write event a listener may have used to change or refuse it. A write a listener refused neither stores nor announces anything, just like one the editor refused itself.

Nothing is announced in three cases:

• An edit in a translated site language. The editor then works on the translation of the profile, and the event announces default-language profiles only. Edits in the default language of the site are announced, and with profile.allowedLanguages configured, the translation synchronisation of this extension carries them into the translations.
• A write that changed nothing. A sort that left every row in its place, and the removal of an image the profile does not have.
• A failed write. A request the editor or a listener refused, or one that failed while it was stored.

What a listener reads 

The event carries no information about what was written. A listener that needs it listens to BeforeProfileEditingWriteEvent as well, keeps what it needs of the write, and acts on it once the update is announced.

Example 

An office that reviews the profiles people maintain themselves wants a log entry for every change made through the editor, and none for the changes made in the backend or by an import:

<?php

declare(strict_types=1);

namespace MyVendor\MyExtension\EventListener;

use FGTCLB\AcademicPersons\Event\AfterProfileUpdateEvent;
use FGTCLB\AcademicPersons\Event\ProfileUpdateOrigin;
use Psr\Log\LoggerInterface;
use TYPO3\CMS\Core\Attribute\AsEventListener;

final readonly class LogProfileEdit
{
    public function __construct(
        private LoggerInterface $logger,
    ) {}

    #[AsEventListener(identifier: 'my-extension/log-profile-edit')]
    public function __invoke(AfterProfileUpdateEvent $event): void
    {
        if ($event->getOrigin() !== ProfileUpdateOrigin::FrontendEditing) {
            return;
        }
        $profile = $event->getProfile();
        $this->logger->info('Profile {uid} was edited in the frontend.', [
            'uid' => $profile->getUid(),
            'site' => $event->getSite()?->getIdentifier(),
        ]);
    }
}

Rules and pitfalls 

• This extension listens itself. Two listeners of this extension react to the event: one carries the change into the translations of the profile when profile.allowedLanguages is configured, see General configuration, and one regenerates the slug of the profile from its name. Their identifiers are not public API, and no order between them and a listener of a project is promised.
• Writing a profile again. A listener that writes the profile through the DataHandler marks that run as internal, or the backend announcement of academic_persons announces it once more. The extension points page names the class for it.
• The answer waits for the listeners. The event is dispatched inside the request of the editor, so the person waits for every listener before the editor shows the write as saved. Hand slow work, a mail or a request to another system, to a queue.

Introduced in 

• Feature: Frontend profile edits synchronize translations