Hi @sebastianpetrovski

Thank you for response but I’m a bit confused now.

You already can simply disable validation in field settings. If you set validation to “none” it will not check for protocol prefix.

Or do you mean to have some sort of validation there but in a way that will only skip prefix (like: if it’s there, it’s fine, if it’s not there it’s fine too, provided that the rest of the string appears to be an URL)?

Kind regards,
Adam

Hi again @thecreator01

Apparently, I got response faster than I expected 🙂

Adding below code to the site should do the trick and make all the subsites NOT use Branda’s e-mail templates; only a main site will use them. I tested it on my test setup and it seems to work just fine.

The code is:

<?php 

add_action( 'init', 'wpmudev_remove_sub_branda_email_template' );
function wpmudev_remove_sub_branda_email_template() {
    if ( is_main_site() ) {
        return;
    }

    global $wp_filter;
	$tag 			= 'wp_mail';
	$hook_method	= 'wp_mail';
	$hook_class 	= 'Branda_Email_Template';

	if ( ! isset( $wp_filter[$tag] ) ) {
		return;
	}
	
	foreach ( $wp_filter[$tag]->callbacks as $key => $callback_array ) {
		foreach ( $callback_array as $c_key => $callback ) {
			if ( substr_compare( $c_key, $hook_method, strlen( $c_key ) - strlen( $hook_method ), strlen( $hook_method ) ) === 0 ) {
				if ( $callback['function'][0] instanceof $hook_class ){
					unset( $wp_filter[$tag]->callbacks[$key][$c_key] );
				}
			}
		}
	}
}

To add it to the site:

– access your WordPress install using FTP, cPanel “File Manager” or similar way
– create an empty file with a .php extension (e.g. “branda-subsites-disable-templates.php” or similar) in the “/wp-content/mu-plugins” folder of your site’s WordPress install
– copy above code and paste it into that file
– save the file and purge all cache on site/server

and it should then work out of the box.

Kind regards,
Adam

Hi @jphdesigns

Thank you for response!

All right then – please update us once you’re done with the test and we’ll then see what to do next (if still necessary).

Best regards,
Adam

Hi @rjkothari2021

I hope you’re well today!

To start with, please remember that nothing is a one-hundred-percent efficient protection against such spam. There are things that can only limit/mitigate it to certain degree.

You mentioned that this started to happen mostly after you switched to another hosting and that’s also entirely possible. This is due to bots targeting some IP ranges more often than others and it may as well change on its own over time.

But getting back to possible protection:

Since you already have cpatcha added I would suggest some additional solution:

1. in form settings additionally enable “honeypot” option; it’s a very very basic protection against spam but still adds-up to it so as a supplementary precaution it’s worth a shot

2. add some anti-spam solution that directly integrates with Forminator; that could be CleanTalk Anti-Spam plugin or Akismet, take a look here, please:

https://wpmudev.com/docs/wpmu-dev-plugins/forminator/#other-integrations

3. it may be more efficient to use CloudFlare’s Turnstile instead of reCaptcha/hCaptcha but you’d need to test it, it’s different in different cases;

https://wpmudev.com/docs/wpmu-dev-plugins/forminator/#simple-cloudflare-turnstile

4. Since you are already using WordFence, make sure to keep an eye on logs and consider blocking IPs of the most active offenders; check with your host if you have server-level WAF/firewall and if so – better add such IPs to blocklists there rather than in the plugin

5. Consider adding CloudFlare to the site; even their free tier can significantly decrease bot traffic (hence the spam level too) and an additional benefit is usually also a better site performance.

Kind regards,
Adam

Hi @rana-rene

I hope you’re well today!

Before we go any further with this, could you, please check two simple things?

1. in the form “Behavior” settings in Forminator check the “Load form using AJAX” option and try switching it to opposite as it is now (disable if enabled, enable if disabled) and see if that changes anything

2. fully purge cache and temporarily – just for testing – disable any asset (JS/CSS) optimization in SG Optimizer plugin – see if that makes a different;

I’m asking this because I see certain JS related (specifically – jQuery not defined) errors in browser console on the page that you linked to and that is something that’s very often directly related to such issues.

Please test it and let us know about results, then we’ll see what to do next to address this.

Kind regards,
Adam

Hi @marcusabs

I hope you’re well today!

You should be able to move those buttons with a bit of additional CSS:

{
    display: flex;
    flex-wrap: wrap;
}
> * {
    width: 100%;
}
.forminator-pagination-footer {
    order: -1;
}
.forminator-pagination-steps {
    order: -2;
}

Please add it directly to the form via it’s Custom CSS option in form’s “Behavior” settings.

After updating the form, make sure to fully flush all cache (site, server).

Best regards,
Adam

Hi @thomastolkien

I hope you’re well today!

There is no any specific setting for that and it and the “Local (old)” engine doesn’t scan those. The “Cloud (new)” engine, however, works similarly to search engine crawlers and scans front-end of the site so if those descriptions are displayed on tag/category archive pages – it will check them.

Best regards,
Adam

Hi @leelalee

Thank you for response!

Actually, yes – what you described also seems to be in line with what I wrote previously. For now, I think we should still focus on the things that I asked back then:

1. What happens if you duplicate the form and then try to set those field mappings in MailChimp on that new copy of the form? Have you tried that? If not – please do and let us know.

2. Do you know if there is any kind of server-side cache (especially object cache) active and if yes, does purging it help?

but also

3. what happens if you completely remove MailChimp integration from both form itself and the plugin (“Forminator -> Integrations” page, if you see more than one MailChimp instances connected there, try removing all of them) and then connect and configure it again entirely from scratch?

Let’s start with that and see where it gets us next.

Kind regards,
Adam