forge12marc

Hi Ralf, thanks for the detailed description — it helped a lot!

This isn’t caused by the captcha or JavaScript, but by the plugin’s IP protection / rate-limiting feature. Due to a bug in the timing calculation, from the 3rd submission on it incorrectly detects “submitting too fast” and blocks it — regardless of browser, because they all share the same IP.

Immediate workaround: Plugin settings → IP protection. Either turn it off briefly, or set “Period between submits” to a small value (e.g. 5 sec) and raise “Max retries”. That makes the problem go away right away.

We’ll fix the underlying bug in the next update. If an IP has already been banned in the IP settings, you can clear it via “Reset IP logs/bans”.

Thanks for reporting it — we’ll get it sorted!

Best Regards
Marc

Hello @postcd,

could you please provide the link to the exact page that was crawled? This will allow us to investigate the issue and assist you more effectively.

Best Regards
Marc

Hi @revilo2020de,

Apologies for the delayed reply! Glad to hear you were able to resolve the issue. If anything else comes up, feel free to open a new thread anytime.

Just a quick heads-up: we’re working on a major update for the plugin that will be released soon. It introduces new features, improves the UX, and addresses a number of known issues.

Best regards,
Marc

Hi @bboehm33 ,
Thanks for the detailed report. I’ve reviewed our REST code for v3.7.2 and it looks correct on both sides (the PUT route is registered properly, the admin permission check is standard
manage_options, and the editor sends the X-WP-Nonce header on save). The 401 rest_forbidden response means WordPress itself sees the request as not authenticated when processing the PUT — even
though GET from the same page works. That almost always points to something in the environment, not the plugin.

Could you run these checks for me so we can narrow it down?

Open DevTools → Network tab, reproduce the error, click the failed PUT request, and check the Request Headers:

• Is there a Cookie: header, and does it include a value starting with wordpress_logged_in_…?
• Is there an X-WP-Nonce: header with a value (not empty)?

Please send me a screenshot of the Request Headers section (you can redact the cookie values). This is the single most important piece of information.

Timing test:

• Open the email editor and immediately (within a few seconds) click Save. Does it still fail?
• If it only fails after the editor has been open for a while → expired nonce.
• If it fails immediately on a fresh load → something is stripping auth on PUT.

Check for MU-plugins / security plugins that stay active even when “all plugins are deactivated”:

• Look in wp-content/mu-plugins/ — is there anything in there?
• Are Wordfence, iThemes/Solid Security, NinjaFirewall, WP Cerber, or similar installed (even if deactivated in the plugin list)? Some register as must-use plugins and keep running.

Enable WP debug logging:

In wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); 

Reproduce the error once, then send me the last ~50 lines of wp-content/debug.log.

Host / WAF question (please ask your host specifically this, not just “do you block PUT”):

Does your WAF, ModSecurity, or reverse proxy strip or modify Cookie or X-WP-Nonce headers on PUT requests to /wp-json/*? And do preflight OPTIONS requests pass through with credentials?

“We don’t block PUT” is not the same as “we pass PUT headers through unchanged” — this wording forces a precise answer.

Are you behind Cloudflare or another CDN?

If yes, try temporarily pausing Cloudflare (Overview → Pause on Site) and retry. Bot Fight Mode and some security rules strip auth on non-GET requests.

Quick isolation test: open the editor in a private/incognito window, log in fresh as administrator, edit a template, save immediately. Does it still fail?

Once I have the answers (especially #1 and the debug log from #4), I can tell you exactly what’s happening. Based on what you’ve described so far, my best guesses are an expired nonce from a
long editor session, or a host-side WAF rule stripping cookies on PUT — but I need the headers to confirm.

Thanks,
Marc

It seems someone changed the translation from “Avada” to “Optionen”. To use Avada enable the “Optionen” that should fix your issue. We will update the Plugin soon providing a fix for the naming issue.

Let me know if that solved your issue or if you need further assistance.

Best Regards
Marc

Hello @bonaldi ,

unfortunatelly we did not receive any mail. Can you send us the data using wetransfer to [email protected] ?

Best Regards
Marc

Bonjour nathanstaing,

Merci pour votre message !

Pourriez-vous nous préciser les points suivants afin que nous puissions vous aider au mieux :

1. Quelle version du plugin SilentShield utilisez-vous actuellement ?
2. Quel est exactement le problème – la collecte de données s’est-elle complètement arrêtée, ou les données sont-elles simplement incomplètes ?
3. Y a-t-il des messages d’erreur qui s’affichent dans votre tableau de bord ?

Avec ces informations, nous pourrons trouver une solution rapidement.

Cordialement

Hello @bonaldi,

thank you for your feedback. Would it be possible to send us a copy using duplicator of the page via mail to [email protected] ?

Best Regards
Marc