I’m currently using the Blocksy Pro theme, and Live Link works perfectly on all devices except for my iPhone. No matter which browser I use on my iPhone, the page never finishes loading. This issue only occurs when the Blocksy Companion (Premium) plugin is active.
I need to use Local for development with this the Blocky Pro theme.
I would greatly appreciate any solutions or suggestions to resolve this issue!
After spending many hours testing, I’ve identified the issue:
When I use custom local fonts as part of the Blocksy “extensions” or even just custom local fonts configured in Elementor, the absolute URLs for those fonts aren’t being rewritten by your “Live Link” tunnel.
As a result, the remote browser tries to load the fonts from a “.local” URL, which will naturally fail. This causes different behaviors across browsers—iOS browsers never finish loading, some desktop browsers overlook the issue but end up missing the fonts.
A solution may be to use a separate custom local font plugin that uses relative font paths instead of absolute font paths. Blocksy and Elementor apparently both use absolute font paths.
I’m glad you were able to narrow this down @Mike92! Thank you for following up here and sharing those details for us and other users who may run into this issue. We’ve been considering some changes to Live Links, including even alternatives. So this may be something that will be impacted in the future if we go down that road.
It seems like the PHP code might have free rein over my entire hard drive, not just the WordPress directory. If that’s the case, it could open up my system to all sorts of nasties—malicious scripts accessing sensitive files, installing malware, you name it.
Any idea if this is true? And if so, how can we lock down PHP to just the site folder to keep things secure?
I’m using macOS Sequoia. Maybe your questions are going a different direction than what I intended. Let me explain:
When you rent a web server, the server ensures that the website’s PHP code doesn’t have write access to any server system files or to other users’ sites if it’s a shared server. PHP will only have rights to write files within the website’s folder.
Here’s what happened to me with Local: I use the popular backup plugin “All-in-One WP Migration”. I decided to clone my site “dev01.local” to “dev02.local” within Local. Naturally, this process also copied all the backup files that the plugin stores under […]/dev01/app/public/wp-content/ai1wm-backups/. However, the cloning process didn’t update the path to the backup files in the plugin’s configuration. As a result, when I accessed the backup list in the admin console of the “dev02” site, I was actually seeing the backup files from the “dev01” site. I didn’t realize this immediately because both sites looked identical right after cloning. Then, I deleted a backup, only to later discover that it had removed a backup file from the other site (“dev01”) instead of from “dev02,” the site I was managing in the admin console. While it’s possible to manually adjust the backup file path after cloning (and this needs to be done manually after every cloning), this experience highlighted a significant issue.
This situation shows that the PHP code of one Local site can access all the files of a completely separate site, which led to the unintended deletion of backup files in my case. My untested assumption is that any PHP code could potentially access the entire file system on my Mac desktop computer, which would allow for compromising the host computer in various ways.
Basically, the PHP code running in a Local site shouldn’t be able to access any files on my host computer outside of the current site’s folder.
Thanks for asking about this. You’re correct - Local runs binaries like PHP natively without containers or virtualisation to give you good performance and an easier setup than Docker or virtual machines.
WordPress plugins have the same system access as other native applications running under your user account, which is low-risk for plugins from trusted sources since these undergo security vetting.
Local’s approach is the same as other native PHP environments such as Laravel valet as well as local development tools like those based on Node.js, which also have user-level access when you serve PHP files or do node script.js.
If you work with code from untrusted sources — such as performing security research or analysing suspicious plugins — then Docker or virtual machines offer stronger isolation than native environments like Local and valet and you’re right to consider them. You might also consider additional precautions like running development tasks that use Node/npm or PHP/composer in the container or VM too. Running Local inside of a VM would address the root concern as you’ve stated it.