franrival

It’s a plugin conflict. 

You’ll need to go to cPanel > File Manager > public_html > public_content > plugins

There you’ll find a list of plugins. To deactivate them, you need to rename them. 

The solution is to add “-off” to the plugin’s name. That will deactivate them. 

Do this for all of them, and then try accessing the site.

This should resolve the issue. 

Submitting a support ticket to WooCommerce is the best option.
But even after they resolve the issue for you,… you’ll still face the same problem with another customer.

For that reason, I think you should install the WP Mail SMTP plugin.

Then connect it to a real email provider:

Gmail
• Outlook
• SendGrid
• Mailgun

This ensures emails are actually delivered.

——————

I think the problem here is that the password recovery link option appears. 

The solution would be to take that link and send it to the customer yourself. But there isn’t a permanent link. 

That link is ONLY generated when the user requests a reset

and ONLY works for a limited time.

That’s why you can’t easily “create one manually.”

“The site can’t email them a link”

So, if you’re using WooCommerce, they should resolve the conflict in the code. And for now, it’s up to you to help the customer complete the purchase manually. 

It takes the server about 13–14 seconds to start responding.

The problem is the server.

Plugins like “wp-perf-analytics” and “session-manager” are commonly used as backdoors disguised as performance or session tools. They are not part of the official WordPress repository and are often injected after a site is already compromised.

In most cases, these plugins are:

• Dropped after an initial breach (not the root cause)

Used to:

*Maintain persistent access (backdoor)
*Inject spam or malicious scripts
*Create hidden admin users
*Reinfect the site if cleaned incorrectly

It sounds like there are two sets of code running at the same time…

1. The Solene theme

* Has its own JS for the mobile menu

* Listens for events (touchstart, click)

* May use preventDefault() or block events

2. Elementor (Header Builder)

* Also waits for those same events

* Needs the event to reach the button unimpeded

The theme’s JS “wins” and blocks Elementor’s. Or the other way around (I don’t think so…) 

Hi, adenby,

What you’re describing (a temporary fix after restarting PHP + the slowness returning) clearly points to resource exhaustion or a problem with the processes, not just a conflict between plugins.

Based on your setup, here’s how I would approach it step by step:

1. Most likely cause: PHP-FPM / resource saturation

If restarting PHP temporarily fixes it, that usually means:
• PHP workers are getting stuck or are overloaded
• There may be:
• Long-running queries
• Delays in external APIs
• Memory leaks
• Too many concurrent requests

Or it could be an issue with a plugin you’ve recently installed. You’ll need to go through them one by one and deactivate them to see if that works.

Note: For every plugin you deactivate, you’ll need to clear the cache. You can easily do this using LiteSpeedCache.