Thank you.

I understand your concern here, especially seeing the Stripe developer widget visible to logged out users while in sandbox mode, and how that could feel like something that should be restricted to admins only. I appreciate you flagging this.

From what you’re describing and the screenshot shared, this widget is coming directly from Stripe’s developer tooling and is automatically enabled when using Stripe Elements in sandbox mode. It is intended for testing and debugging, and as noted in their documentation, it should only appear in development environments and not in production.

A couple of things to check on your end:

1. Confirm that your site is not publicly running in test mode: If Stripe is set to “Test” mode in WooCommerce, the widget can appear for all users. You can verify this under WooCommerce → Settings → Payments → Stripe.
2. Switch to Live mode when not actively testing: Once live keys are in use, this widget should no longer appear to customers.
3. Check for caching or environment setup: If your site is intended to be live but still shows sandbox behavior, there could be caching or environment configuration causing test mode assets to persist.

For more details on configuring Stripe in WooCommerce, you can review: https://woocommerce.com/document/stripe/

At the moment, the plugin itself does not provide a dedicated toggle to control this Stripe developer widget, as it is controlled by Stripe’s own scripts. That said, your suggestion about adding an admin-level toggle makes sense, and it is valuable feedback.

If you can confirm whether this is happening while the site is in Live mode, that will help narrow this down further and guide the next steps.

I can see you’ve taken the right steps already, especially testing with plugins and themes disabled, and that helps narrow things down quite a bit. The 403 response you’re seeing when WP-Cron tries to run is a key clue here, and it points to something on the server blocking those requests rather than an issue within WooCommerce itself.

When WP-Cron attempts to trigger, it makes a loopback request to your own site. A 403 response typically means that request is being blocked by the server, firewall, or security layer. This would also explain why your daily cron is not scheduled and why Action Scheduler tasks are piling up.

Here are the next steps I’d recommend:

1. Check with your hosting provider: Ask them to verify that loopback requests to your site are allowed and not blocked by a firewall, ModSecurity, or other security rules. You can mention that WP-Cron is returning a 403 error.
2. Review security configurations: If your host uses tools like ModSecurity, Cloudflare, or server-level firewalls, these can sometimes block internal requests. Your host can whitelist these requests if needed.
3. Consider a real server cron job: Once the blocking issue is resolved, setting up a real cron job is still the most reliable approach. Your host can help configure this to replace WP-Cron entirely.

Once those loopback requests are allowed again, WP-Cron should start working properly, your daily cron should schedule correctly, and the pending actions should begin processing.

Let me know how it goes after checking with your host, happy to continue from there 🙂

I would like to ask whether the Dictionary plugin is still actively maintained or if it has been discontinued.

I noticed that the Pro version has not been updated for more than a year, and the free version also seems not to have received any attention for about half a year. Because of this, I am unsure whether the plugin is still being developed and supported.

Could you please clarify its current status and whether future updates are planned?

Thank you in advance for your reply.

Best regards

Yes, I know: it is not a solution. But it does point to the cause of the issue. I think your earlier (deleted?) thought about the script not being able to find the matching attribute taxonomy, is correct.

The script probably assumes the tax slug based on the name, but fails in cases where there are special characters or when the slug or name was edited after the attribute was created.