AWOL

@andreiglingeanu the latest update I ticked the last version and the new version, and this page loads – https://themes.trac.wordpress.org/changeset?reponame=&new=342442%40blocksy&old=341299%40blocksy
Tell me you can work out which files have changed from that?

I am reopening this thread because the earlier “fix” did not address the underlying problem I reported.

My original report explained that Better Messages was loading and executing its OneSignal integration code on a free installation where the WebSocket push-notification feature is unavailable. I specifically asked for the code to be prevented from running unless the relevant integration was actually enabled and fully instantiated.

The original console error was:

Uncaught (in promise) TypeError: BetterMessages.getSetting is not a function
/wp-content/plugins/bp-better-messages/addons/onesignal/sub-update.min.js

That particular error disappeared after your update, so I initially assumed the underlying issue had been fixed.

It had not.

The file below is still being loaded and executed:

/wp-content/plugins/bp-better-messages/addons/onesignal/sub-update.min.js

The Better Messages settings still state that the OneSignal plugin has been detected, the Browser Push Notifications option remains forcibly enabled and cannot be switched off, and the integration code still runs despite the fact that I do not have or use the WebSocket version.

The code in that file automatically reads the Better Messages user ID and calls the equivalent of:

OneSignal.login(Better_Messages.user_id.toString());

For my WordPress administrator account, the user ID is 1.

OneSignal now rejects "1" as an External ID. The resulting API request fails with HTTP 400:

{
    "errors": [
        {
            "code": "invalid-argument",
            "title": "Unable to create subscription: external_id is blocked, please use a different ID"
        }
    ]
}

This prevented OneSignal from creating a valid push subscription. The browser permission was granted and a Firefox push token was available, but OneSignal could not complete the subscription because Better Messages had automatically forced the blocked External ID "1" into the process.

I confirmed the cause by commenting out the contents of:

/addons/onesignal/sub-update.min.js

After clearing the browser’s stored OneSignal state and subscribing again, OneSignal immediately created a valid subscription ID and push token without error.

So the situation is now clear:

• Better Messages is still loading an integration that I do not use.
• The integration is tied to a premium feature that is unavailable in my installation.
• The setting cannot be disabled.
• The code automatically takes control of OneSignal user identification.
• It conflicts with my own standalone OneSignal implementation.
• It caused a complete failure of OneSignal subscription creation.
• My original request to prevent this addon from running in the free version was not implemented.

The previous change appears to have suppressed the BetterMessages.getSetting exception while leaving the unwanted integration itself active. In other words, the symptom was patched while the cause was left untouched.

This is not acceptable plugin behaviour. A free plugin should not silently load and execute integration code for an unavailable premium feature, particularly when that code modifies the identity state of an independently installed third-party service and cannot be disabled by the site owner.

Please implement a proper fix:

1. Do not load or execute addons/onesignal/sub-update.min.js unless the Better Messages WebSocket OneSignal integration is genuinely enabled and licensed.
2. Provide a functioning setting or filter that allows site owners to disable the Better Messages OneSignal integration completely.
3. Do not automatically call OneSignal.login() merely because the standalone OneSignal plugin has been detected.
4. Do not assume that a raw WordPress user ID is always a valid OneSignal External ID.

I have had to patch your plugin file manually to stop Better Messages from breaking an unrelated and otherwise functioning OneSignal installation. That patch will, of course, be overwritten by every Better Messages update.

This should not be necessary, especially after the underlying issue was clearly described in the original report.

@sergiuradu, thanks, marked as resolved, in anticipation.

Hi @andrijtkachenko – I had the previous version with no issues, so no question for me it was the update that changed something that either triggered something directly, or triggered something indirectly in some kind of chain reaction. The key part is that somewhere along the line, something in your update caused this, not necessarily as the AI interpreted it though. It is entirely possible that some previously unrevealed issue in my code contributed but this sort of thing is almost impossible to track down. Your plugin may not do anything with $wp_query, $post; variables but something was changed that impacted these somehow. Without knowing your code or the exact changes made I can’t possibly guess what that might be. So we will just have to leave it unless either other users have issues or either of us find something in our code. Just so long as you are aware of it.

• This reply was modified 5 months ago by AWOL.

Just an update – I have eliminated the possibility that this is anything being caused by my custom code. I have completely deactivated my custom plugins and emptied my child theme’s functions.php, and the error still persists on Forminator admin pages and flashes on the Customiser. Obviously turning off debug eliminates it but it is clear there is some sort of conflict going on, probably involving Forminator, because when debug is true, it is only the Customiser and Forminator admin pages showing the error.

OK, thanks and I don’t wish to be picky, but shouldn’t that be packaged with your plugin in the first place?

Unfortunately I have to report that I have had to deactivate and remove your plugin entirely from my site – I don’t know what the exact cause was, but I was getting many errors on post/page edit screens, and huge spikes in CPU and Memory usage on my host, that were resolved by deactivating the plugin, and seemed particularly connected to your post query blocks, but also a number of other ones. This may have been caused in conflict with another plugin or plugins, but I had neither the time nor the inclination to look further into it to discover the exact root of it, as replacing all the blocks has delayed me enough already. I do believe though, if it is of any help, that it is connected to the number of API calls that your blocks/plugin is making, which was overwhelming my server limits (in combination with other plugins and WordPress itself). It was causing 503 errors all over the place.

I have been doing some further testing with the ‘payment_page_after_payment’ hook and this doesn’t seem to be triggering anything at all – I used it with just the error_log as displayed in the documentation and there was no entry in the debug log on a Test setup, when it should be recording the transaction id and the amount. And there is still no email. The transaction is being recorded in the database and by a process of elimination I am having to assume that the transaction id is the id column in the payment_page_payments table? But the hook is not doing anything.