Peter Hardy-vanDoorn

@shameemreza your woocommerce_coming_soon_exclude snippet does absolutely nothing – the badge in the admin bar is still there, as is the tab in the Woo settings page.

I’ve collected all of the suggestions together (tidying things up a little as I personally don’t like anonymous functions) and added one of my own to hide the tab in the Woo settings screen:

/************************************************/
/* Remove Woocommerce Site Visibility From Admin*/
/************************************************/

// This doesn't seem to do anything, but @shameemreza from Woo suggested it
add_filter( 'woocommerce_coming_soon_exclude', '__return_true', 100 );

// Remove badge from admin bar (props https://gist.github.com/RiaanKnoetze/5193516e172554b8871236351e666cf1)
function fabulosa_woo_visibility_badge_begone( $wp_admin_bar ) {
	$wp_admin_bar->remove_node( 'woocommerce-site-visibility-badge' );
}
add_action( 'admin_bar_menu', 'fabulosa_woo_visibility_badge_begone', 100 );

// Hide tab in Woo settings (props @petervandoorn)
function fabulosa_woo_visibility_tab_begone() { 
	echo '<style> .woo-nav-tab-wrapper a[href*="tab=site-visibility"] { display: none; }</style>';
}
add_action( 'admin_head', 'fabulosa_woo_visibility_tab_begone' );

Hi @manni02

The removal is only temporary and it’ll be back very soon.

It was hit by an over-zealous security researcher misunderstanding how it works, so WordPress removed it from the repository without any consultation with me. I’m a bit p*ssed about the whole saga to be frank!

Yes, it is completely safe to use in the meantime. I’m working up a patch this weekend and then it’s in the hands of the plugin review team, so how long that’ll take I’ve no idea!

Thanks for your kind words and support.

Peter

Hi @robertskiba

Thanks for your kind words and the offer to translate the plugin.

I’ve had a look into offering FQDN functionality, but I’m afraid that I don’t think it’s going to be possible to add it to the plugin.

The reason is that this information is not always part of the $_SERVER global. The documentation does say that there is a 'REMOTE_HOST' variable, but that it is not on by default and the server must be configured to provide it.

There is the gethostbyaddr() PHP function to fetch that information via the IP address, but my reading on the subject has found that it can put quite a heavy load on a site, especially if the DNS for the hosting environment is not properly configured. This could cause long page loads and even timeout failures. This is probably why 'REMOTE_HOST' is turned off by default.

My own testing has also shown that gethostbyaddr() doesn’t always work – for my own (hosted) server, it only ever gave me back the IP address that I had given it!!

So, sorry to disappoint, but I think it would add too much possibility for causing problems for the end user of the plugin.

However, that’s not to say that you couldn’t do it yourself by using the wpjf3_matches hook and writing your own function to test for it. If your server is configured to supply it you can test $_SERVER['REMOTE_HOST'] or, if not, you could use gethostbyaddr($_SERVER['REMOTE_ADDR'])

For example (I haven’t tested this):

function my_wpjf3_fqdn_matches( $wpjf3_matches ) {
	$remote_fqdn = isset( $_SERVER[ 'REMOTE_HOST' ] ) ? $_SERVER[ 'REMOTE_HOST' ] : gethostbyaddr( $_SERVER[ 'REMOTE_ADDR' ] );
	$my_fqdn = "mydomain.dyndns.org";
	if ( !empty( $remote_fqdn ) ) {
		if ( stristr( $remote_fqdn, $my_fqdn ) ) 
			$wpjf3_matches[] = "<!-- FQDN -->";
	}
	return $wpjf3_matches;
}
add_filter( "wpjf3_matches", "my_wpjf3_fqdn_matches" );

Thanks so much – I can confirm it’s fixed.

Hi @veetihsu

Disabling any plugin from the Plugins screen will completely stop it from working. There is nothing in the way that WordPress works that can leave a plugin running after you’ve disabled it.

So, you almost certainly have some caching going on, either via a plugin which you have installed on your site, or which is provided automatically by your hosting environment.

However it’s provided you will need to clear the cache.

Peter

Oh that’s marvellous – thanks for that! Great article, btw.

Funny thing is, I’ve actually been meaning to add a “buy me a coffee” link for ages!

I had searched for the best way to do this, but of you include “plugin” and “donations” or “payments” in your search, Google just returns loads of sites about adding donations to your site, rather than your plugin, so I gave up searching!!

I don’t personally like PP, and since I already had a Stripe account I thought that would be the easiest option. But, if someone wants to be generous then it certainly doesn’t make sense to put obstacles in their path, so I’ve opened an account and here’s the link: https://paypal.me/fabulosawebdesigns

Thanks again

Thanks so much Anne-Mieke, that’s much appreciated.

This plugin was always my go-to for pre-launch development, which is why I was keen to take it over and keep it alive when it was abandoned by the original developer.

I’ve no intention to offer a “pro” version, but I’ve set up a payment link if you’d like to make a contribution: https://donate.stripe.com/00gaI15lOby737i5kk (if that’s allowed on here).

The problem is they’ve added height: 100% to the container.

Until they fix it, add this line of CSS via the Customiser:

.frm-fluent-form .ff-t-cell .ff_submit_btn_wrapper_custom { height: unset !important; }

Hi

If you select the redirect option and tell it to redirect to a page on the same site, then this will happen. If you think about it, you’re telling the plugin to redirect to page X, but when WP tries to display page X, the plugin then tries to redirect to page X, which then tries to redirect to page X, which then… and so on, ad infinitum!

You can add a function to your theme (or child theme) functions.php file to tell the plugin to ignore a specific page or URL, like this:

function my_wpjf3_matches( $wpjf3_matches ) {
	if ( stristr( $_SERVER['REQUEST_URI'], 'demo' ) ) 
		$wpjf3_matches[] = "<!-- Demo -->";
	return $wpjf3_matches;
}
add_filter( "wpjf3_matches", "my_wpjf3_matches" );

This example looks in the $_SERVER global to see if any part of the URL contains “demo”.

Hope that helps

Peter

• This reply was modified 2 years, 1 month ago by Peter Hardy-vanDoorn.
• This reply was modified 2 years, 1 month ago by Peter Hardy-vanDoorn.

Hi @pinkish1

Yes, I noticed the sprintf() error when I was investigating your issue yesterday. I’ve released a new version to fix that.

I think it’s probably to do with PHP 8.1.9 – I’ve never tested it on such a “bleeding edge” version of PHP. I’ll have to do some further investigation.

Cheers

Peter

Hi @pinkish1

Try as I might, I just can’t replicate that error. It’s in the part of the code that checks the IP address, but that function has not changed in a long time. Maybe it’s got something to do with the version of PHP you are using, so perhaps you could check that and I can have a further look?

BTW, a PHP Warning is not fatal, so although your logs might get filled up with warnings, they generally don’t stop the site from working.

Cheers

Peter

I got fed up waiting for a reply about this (and reading other posts, it looks like I’m never likely to get one), so I took matters into my own hands.

Thankfully, the error message that is output at the top of every admin page is contained in this file: /advanced-access-manager/application/Backend/tmpl/partial/license-violation-notice.php

All you need to do is delete the contents of that file (but not the file itself).

Hi @apxavier

The plugin sends an email using WordPress’ built-in email functions. If you haven’t installed an SMPT plugin then those types of emails are often marked as spam. Also, some hosts don’t allow WordPress to send email at all.

The latest version of the plugin now has a “Copy link” button next to each access key, which will copy the whole URL with the access key to the clipboard ready for you to paste into an email yourself.

Peter

I just came here with the same problem. Shame this hasn’t been fixed yet as this is one of the better forms plugins for the block editor.

Hi @manni02

Fixed it ??

The problem was caused by a tiny little change that I made just before submitting the update that I honestly never would have thought would be an issue, and was The reason why it put the focus in the email address field.

I had changed the input type on the email field from “text” to “email” (thinking that makes things nicer on iOS as it changes the keyboard to include the “@” and “.com” buttons). But, what I didn’t realise is that it also makes the browser try to validate the field for a proper email address and thus prevent submission because there’s no email and therefore the field is not valid.

D’oh!

Peter