fox-didl

Same error on staging site:

Ein Fehler vom Typ E_ERROR wurde in der Zeile 237 der Datei /wp-content/plugins/woocommerce/includes/admin/settings/class-wc-settings-general.php verursacht. Fehlermeldung: Uncaught Error: Class “Automattic\WooCommerce\Enums\DefaultCustomerAddress” not found in /wp-content/plugins/woocommerce/includes/admin/settings/class-wc-settings-general.php:237

Update – complete working solution found

After further analysis, the two-bug fix I described earlier was not sufficient. The Brevo CDN SDK (sdk-loader.js) autonomously initializes WonderPush based on the server-side Brevo account configuration, regardless of what PHP options are passed. Simply omitting service_worker_url and push from brevo_init_options() does not prevent the CDN SDK from triggering the WonderPush ServiceWorker chain.

A third fix is required: intercept navigator.serviceWorker.register at the browser level, before the Brevo SDK loads, so that any ServiceWorker registration attempt for the Brevo plugin scope is silently blocked.

The complete working patch requires changes to three files plus a functions.php filter:

1. inc/push-utils.php – is_push_sdk_enabled()

Add at the very beginning of the method:

php

if ( get_option( ‘sib_push_sdk_force_disabled’, ‘0’ ) === ‘1’ ) {

return false;

}

2. inc/push-utils.php – brevo_init_options()

Wrap all push-related keys (push, service_worker_url, frame_url) in a conditional so they are only included when push is actually enabled:

php

$options = array( ‘client_key’ => $ma_key, ’email_id’ => $ma_email );

if ( self::is_push_sdk_enabled() ) {

$options[‘push’] = $push_options;

$options[‘service_worker_url’] = ‘…’;

$options[‘frame_url’] = ‘brevo-frame.html’;

}

return $options;

3. sendinblue.php – install_ma_script()

Output the following JavaScript before the Brevo SDK <script> tag when push is disabled. This patches navigator.serviceWorker.register so the CDN SDK cannot autonomously register WonderPush, and also cleans up any previously cached ServiceWorker:

javascript

(function() {

if (‘serviceWorker’ in navigator) {

var _origRegister = navigator.serviceWorker.register.bind(navigator.serviceWorker);

navigator.serviceWorker.register = function(scriptURL, options) {

if (typeof scriptURL === ‘string’ &&

scriptURL.indexOf(‘woocommerce-sendinblue-newsletter-subscription’) !== -1) {

// Return forever-pending Promise: WonderPush waits silently, no console errors

return new Promise(function() {});

}

return _origRegister(scriptURL, options);

};

// Unregister any previously installed Brevo ServiceWorker from browser cache

navigator.serviceWorker.getRegistrations().then(function(registrations) {

registrations.forEach(function(sw) {

if (sw.scope && sw.scope.indexOf(‘/woocommerce-sendinblue-newsletter-subscription/’) !== -1) {

sw.unregister();

}

});

});

}

})();

4. functions.php (theme) – activate the override

php

add_filter( ‘pre_option_sib_push_sdk_force_disabled’, function() { return ‘1’; } );

Why new Promise(function() {}) instead of Promise.reject()? WonderPush does not gracefully handle a rejected registration promise in all code paths, producing an Uncaught (in promise) error in the console. A forever-pending Promise causes WonderPush to wait silently without errors.

Verified on: Plugin version 3.3.4, WP 6.x. All wonderpush.min.js, sdk-loader.js and sibautomation.com errors are gone after this patch.

Root cause summary for the Brevo developers:

1. is_push_sdk_enabled() uses a 30-day transient cache → deactivation via the UI has no immediate effect
2. brevo_init_options() always passes push parameters to the MA SDK → SDK initializes WonderPush autonomously
3. The MA CDN SDK reads account-level push config from Brevo’s API → push initializes regardless of PHP options

All three layers need to be addressed for a proper fix.