kimu
Forum Replies Created
-
OK, that’s interesting. I am using Elementor Pro, but I don’t think it makes any difference because that widget should be the same regardless of the version used.
This suggests that something else, somehow, is interfeering with this feature… but only on Firefox.
It might be another one of the plugins I have installed, hard to tell. I can try to deactivate them one by one in the development installation and see if I can find the culprit.
If I manage to find it I will report back to you.I guess that you are doing some sort of user-agent detection to determine whether is a bot or human interacting with the website and I cannot think of anything out of my head that can mess up with that, expect for one thing maybe, but yeah, I will do some testing and I will come back to you.
Yes, I use the free version.
Hi,
I use[obfuscate email="..."]Forum: Plugins
In reply to: [WooPayments: Integrated WooCommerce Payments] Error on line 6078Just a few minutes after I posted my comment, version 7.5.2 have been released with the aforementioned patch.
Problem solved.
ThanksForum: Plugins
In reply to: [WooPayments: Integrated WooCommerce Payments] Error on line 6078I have just updated WooCommerce to version 8.8.2 and I have started getting this warning in the backend.
I have the latest version of WooPayments, version 7.5.1 and the warning it is still there.
If you think that version 7.5.1 contains the fix to this issue you are mistaken and you are providing misleading information.The deprecation warning is thrown when
WCPay\MultiCurrency\Analytics->register_customer_currencies()
invokes
Automattic\WooCommerce\Blocks\Assets\AssetDataRegistry->add() with the third parameter $check_key_exists set to true. In my case this happens when EUR/Euro is being registered, but I guess this will happen with any currency other than USD.An ETA for the release of a new version of WooPayments with a working solution would be appreciated.
Gotcha, I am probably less worried that it can be discovered rather than it can automatically be hit by robots because it is a globally known URL. This is what I mainly use the plugin for.
If you want people to be able to access members only features that URL is going to be exposed in a way or the other, but not having the default one makes it a bit more safe.
Anyhow, good shout for those who use it to hide WP primarily.I am not sure what is the purpose of that message.
For enhanced security and preventing spam enabling the option “Users must be registered and logged in to comments” seems to be a wise choice.Your message seems to suggest that with that option enabled the connection link will be visible anyway, which does not sound like a problem.
Maybe, the problem is that that link will use the default login URL instead of the custom one defined in WPS Hide Login?
If that is the case what choice would we have. Lower the defences disabling that option to avoid leaking the default URL?