Invalidate locale-keyed caches when the operator changes supported languages
Anything cached per language goes stale the moment the set of supported languages changes. Adding a language leaves the new one with nothing prepared; removing one leaves caches nobody will ever read.
benecaster_supported_locales_updated fires when an operator saves that setting, and hands you both the new list and the old one — so you can work out exactly what changed rather than rebuilding everything. That difference is what makes a one-time backfill for a newly added language cheap instead of a full rebuild on every save.
Core clears up after itself when the setting is saved: its own per-locale admin notices are republished or removed, and nothing else in the plugin is keyed by locale — the feed cache is keyed on show, tier and timestamps, and email templates are resolved per render.
Your add-on’s caches are the part core cannot reach. A locale-keyed transient, a generated file on disk, a warmed CDN path and a row in your own table all need different treatment, and core has no way to enumerate them, let alone invalidate them safely. That is what this action is for — reach for this recipe when your add-on stores anything per language and needs to know the moment the set of languages changes.
It fires on every save, including one that changes nothing. Compare $supported against $prev_supported before throwing away a warm cache, or an operator who opens the settings screen and clicks Save will cost you a full rebuild for no reason.
Code
<?php
add_action( 'benecaster_supported_locales_updated', function ( array $supported, string $primary, array $prev_supported, string $prev_primary ) {
$added = array_diff( $supported, $prev_supported );
foreach ( $added as $locale ) {
do_action( 'my_addon_locale_added', $locale );
}
if ( $primary !== $prev_primary ) {
delete_transient( 'my_addon_primary_language_strings' );
}
}, 10, 4 );
Hooks Used
Need this built rather than just documented? See our services →