Installed Local on my Windows 10 machine to test MySQL 8 compatibility (at WPEngine’s direction), but I’m having multiple problems with the installation:
Site loads extremely slowly (30-45s TTFB)
When trying to render SVGs, it can’t handle file_get_contents or CURL requests.
Undefined PHP array in header.php.
What might cause these errors and how can I adjust the configuration to reproduce the WPE production environment more closely?
What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc
Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.
Have you checked out our Performance Help Doc here? There are a couple of Windows-specific items in there as well that might help, but after running through this if you’re still having trouble let us know!
Yes, unfortunately I’m still having problems. But it does seem to be site-specific. I imported a much smaller site and it ran without issues. But I really need to get this bigger site up and running without errors. Xdebug shows a list of 4 PHP files (2 WordPress default, 2 Theme), but no other info about them. Also not sure why file_get_contents wouldn’t work in this scenario. This site runs locally with Valet without any issues. Can you offer any other suggestions? Thanks for the help.
The site still takes 30-45 seconds to load a page.
The site still doesn’t load SVG icons (using file_get_contents or CURL requests)
And Xdebug gives these errors – this is all I have to go on, but I’m not sure what to make of it. The site works fine on WPE, and locally in Valet.
I will also mention that I have tried changing the folder, and changing the domain extension. Neither worked. I’m currently trying to change the domain extension back to “local” but it has been provisioning for over an hour. That doesn’t seem normal either(?). Thanks for the help.
Regarding performance, you said you checked out the performance guide did you test out anything from in there? Like raising resources, disabling Xdebug, etc?
Are you running other developer applications simultaneously? Apps like MAMP, XAMPP, or Docker for example.
As a workaround, if you aren’t able to get things stable in Local could you utilize a Staging or Dev environment at WPE for this specific site since it seems something on this one in particular is contributing to the load issues?
I’m not sure that Reddit post is relevant – not sure how to use that to my advantage here?
I have doubled the performance specs and tried running without Xdebug.
WPEngine directed us to the Local app, rather than their Staging or Dev environments, because we’re not able to change their server environments to MySQL8, to test future compatibility. There’s nothing specific about the problems we’re seeing in Local that makes me think they’re related to a DB compatibility issue, but I’d sure like to see this running error-free before we give the client the thumbs-up.
Since attempting to change the domain extension back to “local”, it has been provisioning for 3-4 hours. If I close and restart the app, the new setting is NOT in place. But…how long should I let it run?
Any further tips or advice you can provide would be much appreciated. Thanks again.
The Reddit thread was specifically related to the Warning you shared Warning: Undefined array key “body_classes” which I don’t think is related to your performance issues but just in case you needed help debugging that.
Understood about the MySQL8 testing, I neglected to think that might be the case here.
Provisioning for 3-4 hours definitely is not normal. Since this is a rather large install, can you check and see if your machine has adequate storage capacity? How large exactly is the site and the DB?
Do you have any antivirus, security, or firewall applications that could be blocking Local from updating files or syncing?
I don’t think you mentioned but are you running any other developer programs side by side? This could be causing hangups as well.
Lastly could you navigate to your Help Center in the Local App, scroll down to where it says Download Local Log then click and share that log? This should give us a more comprehensive log in zip form that includes enhaned details that might help.
The site is 20.6GB on disk. I still have 38GB free on that disk. So the disk is full, but should have enough room to operate. And I still have about 16GB of free memory (50%).
I have tried disabling Norton360, but it had no effect.
I have Valet installed, but I have stopped that service – Local won’t run at the same time as Valet, presumably because they both use port 80.
Hi @steve501! Thank you for your patience and communication. The team has been looking into this but is requesting some further data. Could you manually navigate to where your Local Logs are stored on your machine, bundle up all of your Verbose logs specifically and share those?
I was able to sort out the undefined array key message. I guess it’s just a warning that Local is showing that is not visible on the live site. But I would still like to solve the performance issue, and find a way to render the SVGs, because Local looks like a great tool.
Can you provide a bit more detail on how you are fetching the SVGs? More specifically, can you provide an example of how you are using the file_get_contents function to fetch the SVG? If the request is going over the network it’s possible that may be contributing to the slow loading times you are experiencing.
I have tried using
echo file_get_contents($icon1);" (after fetching the URL from ACF).
That works in Valet, but it doesn’t work in Local.
On the live site, we’ve had to switch to CURL:
$handle = curl_init();
curl_setopt($handle, CURLOPT_URL, $icon1);
curl_setopt($handle, CURLOPT_USERAGENT, ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1’);
curl_exec($handle);
curl_close($handle);
That doesn’t seem to work in Local, either.
It sounds like maybe the way the ACF field is set is forcing you to get the attachment using a network request.
If you can, I’d recommend having ACF return either the ID, or an array of data so that you can have more flexibility in how the image is output. Here’s a screenshot to help clarify things:
Overall, it seems like the problem has more to do with making a network request which almost always introduces slowness. I think if you try and remove that network call, the site in general will be more flexible and faster. Hope that helps guide you in the right direction!
I guess I shouldn’t get too hung up on the SVGs. They’re working on the production server and in Valet. It’s not worth it to me to change literally hundreds of instances just to get this running on Local.
Beyond that, even if I completely remove all SVG instances from the homepage (including in the header) there’s still about a 10s TTFT for this site. So there’s something more to this.
This is a very large and complex site. The smaller site that I imported seems to run in Local without any problems. So I’m wondering if this might just be more than Local can handle?
It’s probably more that because Local is a development environment, there isn’t any caching in place. I would imagine that on the production site, all these requests for SVGs over the network are less of an issue because they are all cached at very fast locations within in the WPE remote infrastructure.
In Local, each of those network requests are full requests that are handled by the nginx process.