Mirror right-to-erasure/retention purges to external systems
An erasure request is only honoured if the data is erased everywhere. Benecaster clears its own records, but it cannot reach a CRM, an email platform, or an analytics warehouse that your add-on has been feeding. Left alone, a site can answer an erasure request truthfully and still be holding the person’s data one system over.
benecaster_after_gdpr_purge fires after each successful purge and tells you who was erased and whether it came from an operator acting on a request or from the automatic retention sweep. Use it to carry the erasure outward.
Expect one identifier, not always both. Depending on how the purge was triggered you may have the account or the email address but not the other, so match on whichever you are given rather than assuming both are present.
Two companion filters run before anything is deleted and can call a purge off — one for a single person, one for the whole sweep. Use them with care: blocking a purge means declining an erasure the operator believes has happened, which is worse than never having offered the feature.
Code
<?php
add_action( 'benecaster_after_gdpr_purge', function ( string $source, array $result ): void {
$user_id = (int) ( $result['user_id'] ?? 0 );
$email = (string) ( $result['email'] ?? '' );
// Resolve email when only the user_id is known (cron path).
if ( '' === $email && $user_id > 0 ) {
$user = get_userdata( $user_id );
$email = $user instanceof WP_User ? $user->user_email : '';
}
if ( '' === $email ) {
return;
}
// Mirror the deletion to your CRM.
my_crm_delete_contact_by_email( $email );
// Operator-driven deletions are right-to-erasure requests — log them
// for your compliance audit trail. Cron sweeps are routine retention.
if ( 'manual' === $source ) {
my_compliance_log()->record( 'gdpr_erasure', $email );
}
}, 10, 2 );
Hooks Used
Need this built rather than just documented? See our services →