tezalsec

Still hoping for an answer ??

Hi,

thank you for responding and pointing out the setting, I had overlooked it.

However, I am still not getting it to work how I want it without some custom function. I would like direct url access to be completely unavailable, not just overridden. I tried disabling the underlying WP search, but your plugin did not like that. Too bad they both seem to have to use the same “s” url parameter.

Below simple function works though, maybe not very clean, but effective. Loading it as soon as possible, so there is as little memory cost to the server as possible. Is this a viable solution in your opinion, I assume this can not cause any trouble to your plugin’s functionality?

function avoid_direct_searches() {

	if(isset($_GET['s']) && !isset($_GET['asp_active'])) {
		wp_safe_redirect(site_url());
		exit;
	}

}
add_action( 'plugins_loaded', 'avoid_direct_searches' );

Thanks!

• This reply was modified 3 years ago by tezalsec.

Thanks. I was somewhat confused by you referring to both feature-policy and x-frame-option policy, but it is clear now. Cheers.

@rsioncke , I have a similar issue. Where is this setting you are referring to? In your Apache config? Is it the X-Frame-Options header?

Or in your browser, and if so, which browser?

Thanks.

You are right, I’ll contact support. Thanks.

Great. I’ll await your next release. ??

Cheers.

Hi,

here is a screenshot showing the top right corner on the Woocommerce Products overview page after updating a product. The message “The product is updated” is not visible, it is behind the white bar, only the “First logged.. etc.” is visible as you can see. On pages without this white bar the notices are perfectly positioned and fully visible.

Don’t know what more I can share about it. The issue is caused by the white bar as used by both Woocommerce and Elementor.

Good luck debugging it. Appreciating your plugin, thanks.

Screenshot: https://pasteboard.co/bnwGAQHiPLj6.png

Thanks!

I see you include the space issue in your last update. ??

I can confirm now for sure this was the issue with the occurrences I spoke about. I pointed the space issue out to them, and afterwards they registered succesfully.

Glad its sorted out. Again, I hope there will be more a bit more differentiation in validation message categories, it avoids looking for errors in the wrong direction. ??

Cheers.

Cool, thanks!

Thanks for the speedy action ?? I just updated, so let’s see what happens.

After reading your changelog notes, I am suspecting now it was just a matter of people accidently starting or ending their email address with a space.

Besides auto trimming start/end spaces, maybe you could choose to differentiate in validation error messages, so in that case it would say “invalid email address” instead of “you are already registered”?

This last issue is still the case, so maybe that’s something for a next update? ??

Thanks again.

I have Supercache active, but excluded it on the registration page. No object caching.

I did notice that when someone couldn’t register, when I put in their email address myself, the validation error did not appear. It sounds like some form of clientside caching, but I am assuming that should not be possible, since there was no previous registration and you probably use ajax in the form.. So I have no idea.

• This reply was modified 3 years, 8 months ago by tezalsec.

Really? Wow, I really thought it was functioning fine. Frontend pages are faster than without it. The CLI monitoring behaves exactly as I would hope to when visiting pages.

Having Redis active on my backend gave me way too much outdated admin data, I rather wait a little longer and get fresh data in the backend.

I guess you suspect my issues are a result of the excluding of urls? Because these issues only happened recently, long after setting up my solution of excluding urls.

Thank you.

Thanks for getting back to it, but I decided to go back to Contact Form 7. I loved your lightweight solution, but the lack of multilingual support was just too much of an obstacle. I hope you’ll integrate it someday.

Cheers.

Hi Till,

the issue I am describing stands apart from what you are describing. Apart from these links/actions not working, Redis is functioning perfectly.

I flush all the time. And I wrote a little function that withholds redis from certain pages, including the entire admin area (except the redis settings). I’ll paste it here, maybe it helps someone.

/* 
 * Redis activation
**/
function wp_redis_activate() {

	$url = "https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

	// activate only on redis config page, to get status
	if (strpos(strtolower($url), 'redis') !== FALSE) { return TRUE; }

	// no redis as logged in admin (except for above redis setting page)
        if(wp_login_cookie_exists()) { return FALSE; }

	// exclusion pages, expand if needed
	$excluded_pages = array("wp-admin", "admin", "login", "logout", "login", "ajax", "json", "404", "cancel", "contact", "cart", "checkout", "video", "event", "session", "post_type");

	// loop through exclusion pages
	foreach ($excluded_pages as $excluded_page) {
		if (strpos(strtolower($url), $excluded_page) !== FALSE) {
			// exclusion page found, do not activate
			return FALSE;
		}
	}
	// no exclusion reasons found, activate redis
	return TRUE;
}

if (wp_redis_activate()) { 
	define( 'WP_REDIS_DISABLED', false ); //activate
} else {
	define( 'WP_REDIS_DISABLED', true );  //deactivate	
}