apticknor

Thanks for the followup @611shabnam

I got it to work by reviewing the plugin code and armed with the knowledge of how it works under the hood I decided the simplest path forward was to modify to the database values so the system no longer recognized the page as a rewrite and the original page is no longer associated with the post.

I found the issue. ACF Better Search modifies WordPress core search and has an option to select if you’re on MySQL 8.x to use the new REGEX syntax. Selecting that option made things start working again.

Thanks for the fast response and for making a great plugin!

WordPress version is 6.3.

I’ll see if I can setup a reduced test case to rule out other plugins / themes.

For anyone else experiencing this take the following steps to confirm:

1. Enable debugging in the plugin settings
2. Go to your WooCommerce Status page
3. Download a System report
4. Look for errors in the Klarna Payments Request Log

I have provided the debug log privately to @boozebrorsan for review and resolution.

I am getting the exact same error on our website when i updated from 2.12.1 to 3.0.3. I rolled back to 2.12.1 and the error went away.

It happens specifically when coupons are applied on the checkout page. After the coupon is applied successfully there is an ajax call to update_order_review that returns the error message “Bad value: order_amount”

I have a log file but it’d loaded sensitive PII data so I can’t share it here.

@pixelyoursite the console is free from errors (both on load and when I click the button). I checked the markup and everything looks like a normal dismissable notice (the div has the class is-dismissible).

I also looked around to find notices from other plugins and they work as expected, even when both are on the page.

Did you find anything out? I’ve been watching the last couple of days. It seems that usually around 4a-5a a bunch of cached memory clears out. What causes that? Is there anyway to make that happen more frequently?

Thanks for taking a look!

I switched it back to regular CGI and not FastCGI. Things appear to be stabilizing again. I’ll need at least a few hours to get some accurate data.

Here’s an update on memory usage -> https://witanddelight.com/stats.png

You can see where I switched to FastCGI… The memory usage appears much more volatile and up and down. Prior to that it would slowly ramp up over time but the graph is more all over the place now this morning.

I can’t remember where but I previously read about not using FastiCGI due to this. Perhaps I’m incorrect. When I read this I stopped using FastCGI and things level out.

I switched over to PHP 5.3 FastCGI, turned on PageSpeed and removed my .htaccess rule for WWW removal (and set it up via the dreamhost panel). I set Jabber & ftp to inactive on the configure server page.

I prefer to run wordpress in a subfolder with the core and content folders clearly separated so it’s easier to update and more importantly gives me the ability to keep core in an external so I can drop in a boilerplate of sorts into content with a nice skeleton theme to start from. I haven’t had issues with this on other wordpress sites I’ve done, even ones currently residing on dreamhost.

I did however look closely at my htaccess rules and found a duplicate rule. One in the site root and one in the subfolder .htaccess. The one in core had been added by something in wordpress to handle permalinks. Now that I’ve removed one of the duplicate rules, the LimitInternalRecursion error hasn’t showed up in my log in the last 12 hours (was previously happy much more frequently).

I’ve made a lot of changes so I’m going to monitor for a few days and see what comes of it. Thanks for your help!

Yup, Super Cache was off as I was doing some testing. It’s back on now.

I agree the RAM should probably be increased but I’m also working for a customer with a set budget.

We tried this at first – Memory was bumped up to 4GB and I watched memory usage climb slowly over 2 weeks to or so to using 4GB and then requiring a reboot. That’s what lead me to suspect memory leak.

For the most part, with Super Cache on it’s happening less but it’s still requiring too frequent of reboots.

I’m currently trying to get the apache error to trigger. But even when combining the access.log details with the error.log I can’t find a URL to hit that will trigger the apache error. There is also no referrer for the apache error. If I could find a URL to trigger the error, I could adjust the .htaccess accordingly and see if anything in there is causing it.

I was just checking the error logs and found this repeatedly. Maybe this is related?

[Wed Feb 20 01:59:56 2013] [error] [client 54.234.71.89] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.