Jelena

Since we haven’t heard from you in over 4 days, I assume that it’s sorted out so I’ll go ahead and close this thread for now. If you need any further help, feel free to reopen the conversation.

You’re very welcome! 🙂 Glad it’s all resolved now.

And thank you as well for the thorough explanation and logs. These were incredibly helpful.

Cheers!

Hi,

You can whitelist an IP by following this guide here.
Section “How to add IP to the bypass/whitelist”
That guide walks you through the exact steps in the current Shield interface.

And if you ever need help with anything else, our Helpdesk has all the guides in one place, so you’ll always find what you need there.

Cheers!

Hi there,

I understand your frustration with encountering a block while saving a post, but let me explain what happened and why.

The Aggressive Block Data option is designed to detect potentially malicious requests, but it’s very strict and can cause false-positive blocks, which is why it is disabled by default and comes with a clear warning that it may cause false-positive blocks. The warning is indicated in the option description and in our help documentation. For example, in the option description:

By choosing to enable this option, normal actions — like saving a post — can trigger a block, which is what happened in your case. It’s important to note that Shield did not enable this option for you; it was a choice made in your site’s configuration.

The firewall block page clearly shows which firewall rule and request parameter were triggered. For example:

The same details can be found in the WP Activity Log too.

As the site admin, you have full control over your security configuration. In this case, you can disable the Aggressive Block Data option or whitelist the specific parameter to stop the block and solve the problem quickly. Detailed instructions and explanations for handling these blocks are also available in our documentation here and through the Help/Info links inside the plugin.

So Shield isn’t dictating which settings you can or cannot use. Site admins always control how Shield behaves, and you can decide how strict — or less strict — you want the firewall to be. The plugin just provides the tools, shows what was blocked and leaves the choice to you.

Also, if Shield ever blocks you,  WP Activity Log can be your best ally. It monitors and records your site in real-time and tracks specific actions. It will show you the exact type of block that was triggered so you can adjust Shield’s settings to prevent it from happening again.

I hope this clarifies things a little bit for you.

Regards,

Jelena

Hi Rob,

Sorry to hear about the troubles you’re having.

2FA Email is a free feature and yes, it should work for you without any restrictions.

Please see below answers to you questions.

1) This link is intentionally formatted as plain text to ensure maximum deliverability and avoid being flagged as spam. While many email clients automatically convert plain text URLs into clickable links, some don’t.

The email sending verification URL isn’t clickable because of how your email client is handling plain-text emails. Some email clients or specific account settings restrictions can prevent plain-text URLs from becoming clickable, even if other links in the same email appear clickable.

2) If you’ve confirmed that your site can send emails but emails are not being sent to users with the “subscriber” role (2FA not applied for them), this is because that role isn’t included in the ‘Enforce Email Authentication’ option list. We don’t list “subscriber” role by default, you’ll need to add it manually into the option field.

The ‘Enforce Email Authentication’ option is located under the main Security Zones navigation menu > click a gear icon next to Login zone > select 2FA: Email tab > Enforce-Email Authentication:

We also have a complete guide on this here.

Hope this helps.

Thanks.

Jelena

Shield leaves some database entries behind so if you ever reinstall it, your settings and data are still there. This happens particularly if you removed it without the “Delete on Deactivate” option enabled.

Many WordPress plugins (especially complex ones) keep database entries after uninstall. it’s a common way to make sure you don’t lose your setup by accident.

If you need to remove Shield entries, please check these discussions here and here.

You can find the list of Shield’s database tables here.

Hi,

Thanks so much for providing the problem details and your concerns here as well. Highlighting both the issues and solutions can be very helpful to the entire community.

Since we’ve been in direct contact through our support system and have been working closely with you and your hosting provider to investigate and resolve the situation, I’ll go ahead and close this thread now.

If anyone experiences a similar issue, here’s just a quick overview:

The site crashed because some files and database references from the Gutenverse child theme and Gutenverse Addons plugin were not fully removed. As a result, WordPress tried to load missing components, which caused the site crash.

During this, some Shield plugin files were also missing or not properly loaded, which led to Shield being referenced in the error logs. Shield wasn’t the cause of the crash — it was affected by the same file-related disruptions but did not trigger the failure itself.

The issue was resolved by fully cleaning up the leftover data, reinstalling Shield and switching to the Astra theme.

@hbk747 , thanks again for such great cooperation! 🙂

It looks like this issue might be resolved since we haven’t heard back in more than a week. We’re closing the thread, but you’re welcome to reopen it anytime for more help.