We have a custom theme built with the Page Builder theme. Since the update to Gutenberg, even when using the the Classic Editor, we experience high volatility in the editing process.
Our main page is designed as a single-column with multiple sections. Editing results in unpredictable behaviour and often data loss, to the point where our main page is uneditable. Editing seems to work fine for posts and our other custom content types.
There seems to be a difference between our live and testing environments as our host is shared. Even attempting to access the main page on the live host results in a Fatal out of memory error. Editing locally, I’m able to access the main page but the editing experience is basically unusable. On the live site the errors seems to be with the meta.php and db.php scripts, but it’s above my chops to hunt the error down more than this.
Anyone experiencing similar? and or solutions?
Hi Nicholas
Thanks for reaching out.
Please, try enabling WP_DEBUG in your wp-config.php, let us know the details if any errors are printing.
While editing the page concerned, please check the browser console and check for errors there. Please, send the details if any are present.
Hi Andrew thanks for your response and apologies for the late reply. After your post I checked the php and js error logs, and I noticed a bunch of js errors. Some research pointed me to these errors being related to Advance Custom Fields update, which we weren’t getting since we didn’t have a license for ourselves. Upgrading to a license has fixed the stability issues, but now we have serious performance issues. It takes multiple minutes to update our main page in a local development environment. On a test server the application crashes with a fatal memory timeout due to the db.php or the meta.php scripts. I’ll research this more and comeback with a more concrete question.
Glad to hear you’re making progress :)
Good luck with resolving the performance problem. There are many ways you could go about finding the problem. The simplest would be to deactivate all plugins and revert to a default theme. Assuming you can find a working baseline, add the theme and then plugins back until the issue re-occurs. If finding the problem isn’t that easy, you can use Chrome developer tools to analyze requests: https://developers.google.com/web/tools/chrome-devtools/network-performance/
Hi again, Andrew,
The debugging I’m doing is on a custom theme implementation that I (obviously) didn’t code, so I haven’t at all played with alternative theme options since a lot of the functionality is in custom content types in the theme’s functions.php file (I think).
I also suspect that my working environment maybe a factor as I’m working in the Windows Subsystem for Linux, which has pretty bad performance on file writing operations, but this is the currently the only environment where I can fully use the site. I was able to overcome some of the memory issues we were having earlier by giving PHP a lot more memory, but minutes to update the main page is pretty frustrating, but at least it’s stable.
My research suggests that this a memory leak, but I’m not sure which script is choking on which function or script. From what I’ve read gutenberg doesn’t play well with the Metaboxes, which I suspect is why the test and live environments are dying on that script sometimes. The main problem I have now is that there are no errors, so I don’t know where to begin poking around.
Try the network performance link I sent above, you might be able to see where the delay is.
Thanks again, I followed your advice and the lag seems to be coming from scripts titled “admin-ajax.php” and “load-scripts.php.” It takes about a little more than 350,000 MS for the page to load fully.
For sure :)
Those are core files, a wide range of things could be the cause. You’d need to dig a bit deeper. There are some posts on this, for example https://kinsta.com/blog/admin-ajax/.