joeathomas

Follow-up: Root cause identified in set_locale() timing

I dug into the plugin code and found the source of the notice.

In includes/class-wpvivid.php, translations are initialized via:

private function set_locale() {
	require_once WPVIVID_PLUGIN_DIR . '/includes/class-wpvivid-i18n.php';
	$plugin_i18n = new WPvivid_i18n();
	add_action( 'init', array( $plugin_i18n, 'load_plugin_textdomain' ) );
}

And load_plugin_textdomain() itself is correctly implemented:

load_plugin_textdomain(
	'wpvivid-backuprestore',
	false,
	dirname( dirname( plugin_basename( __FILE__ ) ) ) . '/languages/'
);

However, the issue appears to be when set_locale() is called, not the hook itself. If set_locale() runs during class construction or before plugins_loaded, WordPress 6.7 triggers _load_textdomain_just_in_time() and surfaces the notice.

This matches the new WP 6.7 behavior around early translation loading.

Suggested fix:

• Either call set_locale() no earlier than plugins_loaded, or
• Move load_plugin_textdomain() registration to a top-level init hook in the main plugin file

Hope this helps —
Joe

One more question, Oliver…

We’d like to find the entries in the database, so we can simply know which sites had filled in their credentials. Where could we find any one of those three field’s entries?

Thanks!

No, we don’t have anything that would reset the SALT keys. We’re using Wordfence and a couple database optimizer plugins, but I can’t imagine those would change SALT keys.

Have the PayPal Express credential fields had a fieldname change in any of the updates over the last several months?