kmarusek
Forum Replies Created
-
Hey there,
Thanks for your patience while we got this sorted out. I can confirm that the issue with Notification Center settings not saving correctly has been resolved in the latest release — Solid Security 9.3.9.
If you’re still seeing problems after updating, try clearing any site/server cache and give it another go. But this fix should take care of things.
Appreciate everyone who reported this and helped us track it down!
Best,
Kevin
SolidWP SupportHey there,
Thanks so much for reviewing this request — I’ve gone ahead and submitted it here for visibility and tracking:
🔗 Optional Reply-To override in Solid Mail to prevent fallback From address injectionReally appreciate the detailed use case and your kind words about Solid Mail. If others are running into a similar scenario, I’d encourage upvoting or adding comments there — it helps our product team prioritize!
Thanks again for taking the time to share this.
Best,
Kevin
SolidWP SupportHi @lohanelbt ,
The “invalid JSON” error paired with a 524 timeout usually points to a conflict with caching or scheduled tasks timing out. While a previous issue on our end did cause this for some users, that has since been resolved — and based on current support volume, it appears the issue is now limited to isolated cases.
Here’s what I recommend:
- Clear all plugin, server, and CDN-level caches, including page caching and your browser cache.
- Clear all site transients — you can use a plugin like WP Optimize, or run
wp transient delete --allvia WP-CLI if you’re comfortable with the command line. - In Solid Security, go to Security > Debug, then click the Schedule tab and use the Reset button to refresh all scheduled tasks.
- Double-check your Google Analytics code, if present. We’ve had one report where a malformed GA script was interfering with scan completion and returning invalid JSON.
After running through these steps, please give the system 1–2 days to complete a new scan. Let us know how it goes — happy to dig in further if the error persists.
Best,
Kevin
SolidWP SupportHey @n3wmod3l ,
It looks like you’re currently running the free version of Solid Security in the video you provided, but I noticed you mentioned switching back to the paid version. Just to clarify, do you have both Solid Security Free and Solid Security Pro installed and active at the same time?
If so, that can cause issues. I recommend deactivating the free version from your WordPress Plugins screen and keeping only the Pro version active. Then try running the setup wizard again.
Also, if the wizard still doesn’t move past that step, the browser console may show an error that could help pinpoint the issue. If possible, please right-click the page, choose Inspect, click the Console tab, and share any red error messages that appear after trying to move forward in the wizard.
Let me know what you find and we’ll get this sorted out!
Great question @davidefiorio !
The “Disable PHP in Plugins” and “Disable PHP in Themes” settings in Solid Security block direct access to PHP files inside those folders. This helps prevent malicious scripts from running if one were ever uploaded — it’s a useful hardening step.
That said, some themes and plugins need PHP files to be directly accessible. If you notice missing images or broken functionality when these settings are enabled, it’s often because of this block. Disabling the setting lifts that restriction, allowing your trusted plugins and themes to work normally again.
You can read more in our official documentation here:
👉 System Tweaks – PHP Execution settingsIf everything is working properly after adjusting the settings, I’ll go ahead and mark this thread as resolved in a day or two — just reply back if you still have questions!
Best,
Kevin
SolidWP SupportThanks @nlpro for contributing here!
Since it looks like the community helped resolve the issue and there’s been no further activity, I’ll go ahead and mark this as resolved. If anything else comes up, feel free to open a new thread and we’ll be glad to assist.
Kevin
SolidWP SupportHi there,
Thanks for reaching out!
Currently, there isn’t a filter or setting available to extend the expiration time of 2FA email codes. If the emails are arriving too late to be usable, it likely points to a delay on the mail server or email provider’s side.
You might want to look into your SMTP service or contact your email provider to check for delays or throttling. Alternatively, we recommend switching to a more reliable method like mobile-based 2FA (using an authenticator app), which doesn’t depend on email delivery and tends to be faster and more secure.
Let me know if you need help switching 2FA methods. Be sure to follow the document on 2FA here:
https://solidwp.com/documentation/security/how-it-works/solid-security-two-factor-authentication-2fa-settings-guide/
Best,
Kevin
SolidWP SupportHey DavidJS,
I’d like to get a clearer picture of what exactly broke so we can track down the cause.
To help narrow this down, could you let me know:
- What site this happened on?
- Which pages or sections had images that weren’t loading?
- Did the missing images share anything in common? For example:
– Were they background images (set via a block or customizer)?
– Standard Media Library images?
– Part of a slider, animation, or third-party block? - Do you remember which Solid Performance features were enabled at the time — like Lazy Load, Cloudflare Image Transformation, or your Page Cache method (PHP or NGINX)?
Once I’ve got those details, I’ll take a closer look and see what might have gone wrong — I definitely want to get to the bottom of this with you.
Looking forward to your reply!
Hi there,
Thanks for your question!
Unfortunately, Solid Security doesn’t currently offer a way to allow only specific plugins or endpoints to access the REST API — it’s either restricted or open across the board. The “Restricted Access” setting limits access to logged-in users only, but it doesn’t allow for granular whitelisting by plugin or request type.
If Yoast SEO relies on the REST API to fetch category data, the best option for compatibility is to leave REST API access open or use the “Default Access” option, as you’ve discovered.
We definitely understand the desire for tighter control, and I’ll flag this with the team as a feature request for more granular REST API controls.
Best,
KevinHi there,
Thanks for reaching out, and I understand how urgent deliverability issues like this can be.
That specific error usually indicates the email was rejected because it failed the recipient server’s spam checks. One common cause is a mismatch between the “From” address you’ve configured in Solid Email and the domain you’re actually sending from.
To help resolve this, here are some steps you can take:
- Make sure the “From” email address matches your site’s domain — for example, use
[email protected]instead of a Gmail or third-party address like[email protected]. - Check that your domain has valid SPF and DKIM records set up with your SMTP provider. If you’re using a service like SendGrid, Mailgun, or SMTP.com, they’ll usually provide specific DNS records to add to your domain.
- Avoid using Gmail or free email addresses as the “From” address — these are often rejected or marked as spoofing attempts.
If you’d like, I can help review the SMTP configuration and DNS setup you’re using — just let me know what mail service you’re sending through (e.g. Gmail SMTP, SendGrid, etc.).
Let me know how it goes.
Best,
Kevin
SolidWP SupportHi there,
You’re right — this does sound like the same
.htaccessoverwrite issue discussed in the thread you linked. This usually happens when multiple plugins or tools are writing to.htaccess, and the Solid Security rules get overwritten.To resolve this going forward:
- Restore a clean
.htaccessby going to WP Admin > Settings > Permalinks and clicking “Save.” - Manually re-add any missing Solid Security rules if needed. You can regenerate them by toggling the related features off and on, or copy them directly from this guide:
👉 What rules are enforced by the .htaccess file in Solid Security Pro? - If you’re using a tool like cPanel, LiteSpeed, or a redirect plugin, double-check for any automatic
.htaccesschanges that might be overwriting rules. - To avoid repeat issues, try to limit how many tools or plugins are modifying
.htaccessdynamically.
That should give you everything you need to bypass and prevent this in the future.
I know this issue is still elusive and we’ve yet to replicate it on our side, but I’ll go ahead and flag it with the team tomorrow so we can take another look internally.Hi there,
Happy to help here.
Solid Security won’t lock users out arbitrarily — lockouts only happen when specific security rules are triggered (like too many failed logins, suspicious behavior, or triggering brute force protection). That said, it’s definitely frustrating when you’re locked out unintentionally.
Here’s a guide to safely regain access without needing to rename plugin folders:
👉 Help! I’ve locked myself out of my siteIt allows you the ability to disabling lockouts without fully disabling the plugin. Once you’ve regained access to your site, be sure to clear your IP from the Ban/Lockout tabs ( Security > Firewall > IP Managment ) and be sure you add your IP to the Authorized list to prevent this from happening again in the future.
Best,
Kevin
SolidWP SupportHi there,
Thanks for reaching out!
If you’re looking to offer your customers the ability to set up two-factor authentication (2FA), this can absolutely be done. In the free version of Solid Security, you can enable 2FA by going to Security > Settings > Features > Login Security > Two-Factor.
Once enabled, users will see the option to set up their own 2FA under WP Admin > Users > Profile.
If you’re looking for more advanced control — such as enforcing 2FA for specific user roles, customizing methods, or managing enforcement policies — these options are available in Solid Security Pro.
Let us know if you’d like guidance on enabling it or directing users to their setup page.
Hi @iliafrescocom,
Thanks again for your patience and for working through these steps with us.
To recap, Shane has already suggested several troubleshooting actions, and from what you’ve shared, you’ve confirmed trying some key ones like disabling Solid Security temporarily and adding the
ITSEC_NOTIFY_USE_CRONconstant in yourwp-config.php. That’s great progress!At this point, to help isolate and resolve the issue further, could you please confirm whether you’ve tried these next steps?
- Contact your hosting provider or email service to check if the notification emails are getting stuck or queued on their server.
- Create a staging copy of your site and test disabling caching plugins or other plugins one by one to rule out conflicts.
- Clear any leftover cache or database entries related to Solid Security that might cause stale or repeated notifications.
As a final step, you might also try the troubleshooting sequence that has recently resolved similar issues for others:
- Clear all plugin and server-level caches — including browser, page, and CDN caches where applicable.
- Clear all site transients using a plugin or with WP-CLI (
wp transient delete --all). - Reset Solid Security’s scheduler by enabling Debug mode (in Security > Debug > Schedule tab), then click “Reset”.
Testing in a staging environment especially can help narrow down whether this is caused by plugin conflicts, caching, or server settings.
Please let us know how these go or if you need help with any of them. We’re here to assist!
Thanks again for hanging in there with us.
Hi there,
Thanks for the info, and good catch on that notice!
The fix for this issue was included in version 9.3.5 (released November 19, 2024), so it should have resolved the PHP notice about translations loading too early.
Since you’re already on the latest version and still seeing the notice, it might be caused by a conflict with another plugin or your theme loading the plugin’s textdomain too early.
Here are a couple of things you can try:
- Temporarily switch to a default theme (like Twenty Twenty-Five) to see if the notice persists.
- Disable other plugins one by one to rule out conflicts.
- Make sure no custom code is calling translation functions before the
inithook.
If none of that helps, please share your full debug.log entry and your plugin version again so we can investigate further.
Thanks for your patience!