Michael

In notification\src\Admin\CheckRestApi.php

You need to replace

		if ( array_key_exists( 'data', $message ) ) {
			$is_available = 'RestApi' === $message['data'];
		}

with

		if ( is_array( $message ) && array_key_exists( 'data', $message ) ) {
			$is_available = 'RestApi' === $message['data'];
		}

$message is not always an array but can be null.

Thank you @kubitomakita for confirming, this is exactly what I did as workaround.

Thanks the quick reply, the link was very useful.
I hope you will consider the php hooks in the future as this would allow safer & smoother integrations.

Hi James, I assure you there was no malice in my support post and review. I thought it was important to let other users know about the issue and try to get your attention. In my humble opinion, the issue wasn’t minor and the conflict could lead to serious issues.

I appologize if my communication did feel upsetting, be assured it wasn’t my attention.

I really appreciate your feedback and I will be happy to test the new version and edit my review and change the rating of course.

Thank you

Michael

Thanks for the links and the info, I’ll surely take a look into it ??

Thank for the quick reply, it is really appreciated.

I realized that my question was a bit confusing but yes I was talking about dynamic content. I haven’t tested the plugin yet so didn’t know that the cache configuration was done in Cloudfront.

I’m familiar with Cloudfront, used as a CDN for assets but not so much for full page caching on wp.

I will have to look that closely and see if how this can work with woocommerce and dynamic pricing per role.

Thanks

Michael

Thanks yehudah!

I edited my rating ??

Thanks for the update, the new version fixed the issue.
The transients are normally not persistent, especially with an object cache or transient periodical cleaning. I get it why it kept coming back ??
However full screen ads and forced redirects are very intrusive, hope next time you will consider an alternative.
I really appreciate your quick reaction time on the issue.

if $_REQUEST[‘page’] is meant to be a url, you’re right

htmlspecialchars() doesn’t escape anything.
I haven’t check the code but I would probably use wp_kses_post() instead.

Try going to https://clearcharity.org/unloq or https://clearcharity.org/wp-login.php directly.

Else you’ll have to login through the ftp and disable the plugin by renaming the folder of the plugin, by example from unloq to unloq_. It should be enough to deactivate the plugin and gain back control.

Thanks for the feedback, I guess everyone noticed all the updates yesterday ??

I can see how much work you guys did put in the plugin and it’s much appreciated but with a plugin that sensitive more careful updates would have been even more welcomed. The key of success is simplicity and reliability. Getting locked up has tendency to irritate a lot!

On some sites, I had to delete the site options related to the previous version of the plugin for allowing the update. I hope you would consider an option to reset the configuration from the plugin itself either manually or on uninstall of the plugin.

I also hope that you won’t discontinue the v1 compatibility (showing both standard and unloq login) on wp-login. I think this remains a very good option, as much as the new options introduced.

Agreed what a mess!

Latency can be different but yes the result is the same. The API might be faster.