Hi, I just buit a local site using Flywheel. When I clicked on View Site tab MS Edge said the site could not be reached. I had to copy the url and paste it onto Chrome and Mozilla to access the local site. Any idea?
Then I built a home page using WP. I use simple html code to put in a logo, but the logo pic wouldn’t load. In fact, the computer could not find any pics I put in the \images\ folder. I then tried putting the pic in the local host folder, still no luck.
Please help.
Hi @belld001,
Please see [Windows] Why can't I access my site in Edge? regarding Microsoft Edge.
Are you still unable to see the site in Firefox?
As far as the image goes, try uploading it using the WordPress uploader under “Media” in the WordPress admin and then using the provided URL.
Hi clay, thank you for your reply.
I can see the page in Mozilla now. The only problem I have now is with the path. My local host is called kents-good-house. I uploaded a theme called fsy-test-theme. It is situated in kents-good-house\app\public\wp-content\themes\fsy-test-theme.
I then created a php page with pics. The pics are all in the \images folder and I copied the whole folder to kents-good-house\app\public\wp-content\themes\fsy-test-theme\images\
The problem I have is that the pics won’t show on the php page. I can see a logo text and when I copied the image location, it says it’s kents-good-house.dev/images/logo.png.
I tried the method you suggested using Media to upload the image. I could view the image. Wp told me the Permalink is http://kents-good-house.dev/logo/, and the file url is http://kents-good-house.dev/wp-content/uploads/2017/08/logo.png. I can see the logo in a funny web page if I clicked on the Permalink.
The problem is, I still can’t see it on my php page. This is really confusing. Please help.
No problem!
If you placed images into your theme folder then you’ll access them directly with something like http://kents-good-house.dev/wp-content/themes/fsy-test-themes/image/TEST-image.jpg
Or, if you’re using CSS to load the images then you can use relative paths accordingly.
Hi Clay,
Thank you for the replies. The path you gave me works. The php page now can load the images.
My next step is to use <?php echo get_stylesheet_directory_uri(); ?> to retrieve the URI, but somehow it is not working at all. Any idea why?
First of all, my apologies. It turned out I made a syntax mistake and that was why I was not seeing the images.
I am trying to use get stylesheet function like this,
<a href="index.html"><img src="<?php echo get_stylesheet_directory_uri(); ?>/images/logo.png" title="logo" /></a>
But it is not working at all. The logo image would not even load onto the page. What am I doing wrong?
Can you open the Developer Tools Console in your browser and see if there are any errors (such as 404s)?
If Local by Flywheel cannot show the site in Edge browser:
You need to include this info in all your docs that tell users how to setup Local by Flywheel. Also include this info in any doc that mentions the buttons for viewing the site, the php info, or the database.
You should provide a Local Flywheel setting to choose a default browser for use within the app: view site, php settings, adminer Buttons.
Please put a notice that “Local by Flywheel sites and pages cannot be viewed in Internet Edge browser” (and that links will always use the default browser associated with your OS preferred browser preferences) In a Prominent Location.
Indicate that if OS Browser default is set to Edge, you will need to manually type in the following links into a Chrome/Firefox/different browser to view the website/php info/database - and List those link URLs so the user can Copy Paste).
Perhaps read the user’s default browser setting, and if the .exe is Edge (or any known incompatible browser), then display the warning under the Links, within the Local by Flywheel app.
Requiring users to change their default browser SYSTEM WIDE because Local cannot use their chosen browser is poor practice, and some users may not even access to do so.
Instead, provide a Local by Flywheel setting that requires the user to choose their default browser (gray out Edge from the list, and/or put a short note “Local sites, databases, and php-info cannot be viewed in Edge browser”).
As is, your buttons are effectively broken, require a dependency that is outside Local by Flywheel, and is poorly documented. This is terrible UX.
Other people, may not have the Option to change an OS system wide browser default, especially if they are on a shared computer. Think School, and think Businesses. Even some families. Who knows maybe grandpa insists the default is Edge, and the family computer is the only one you have consistent access to. Or the boss has it setup this way, and he does not do web development.
It is standard for website creating software to include a setting/preference for user to choose a default browser for links/buttons within the app. Modern software does this, including my code editor, Sublime text. Even Notepad++ does this. I think Front Page did, and certainly Dreamweaver did. Large and small software products, free and paid, from decades ago to now, all do this as standard practice.
What is unusual and unexpected, is that the software only “works” if the OS Default browser is anything other than the OS Default value for the OS Default browser, Plus there is no notice within the app, Or in the basic “getting started” documents stating the conflict.
Add a simple line of info wherever “View in Browser” (php info, sql database) are talked about!.
Done.
Now its an easy fix for any new user.
It is an known workaround. Not a frustrating, puzzling issue, that’s a big deal to solve.
Simple things like this shape users and potential customers view of the company overall.
Good Communication, upfront easy to find relevant info: Good.
On the other hand, why would anyone trust premium services from a company that keeps so much info hidden? Whether it is purposeful, or sloppy, or just overlooked, it does not advertise well for being a mature company, ability to provide (much less prevent) tech support issues, meeting their customers needs, or follow through.
Again, there is a Breaking, Known Issue, that is both unexpected, and rather poorly documented. This leaves new users to re-do countless internet searches to figure out the cause and solution to an issue to that could easily be avoided in the first place with a tiny bit of communication - upfront “Need to Know” info.
Please consider putting this info in your Main guide on how to setup one’s first Local by Flywheel how to guide.
Viola! 99% of affected users will have fixed the issue before it even came up. They will also know the solution if they ever run across it in the future!
Completely avoidable.
This can be implemented immediately. Very little time or effort required on your end.
Immediate results:
Massive reduction of time and effort by every user who runs across this issue.
Also, tech support requests drop.
This simple sentence or two of text, in a prominent, relevant location, will save time and money within your company, as well as frustration, goodwill, and time of your users and potential customers.
Also, consider putting this info within the app in an appropriate location. This will capture anyone who did not read your online quick setup guide.
Info relevantly located right where it is needed:
Now 100% of people have the solution before it is a problem. (Advanced: only show this notice when the OS default browser exe file is for Edge (or any other known incompatible browser).
Finally, Please introduce a Preference/Setting where the User can choose their browser for Local by Flywheel development.
This is the most important, but also requires more work on your end.
Users that do not have access/permission to change the OS default browser, will otherwise never be able to use the links you provide. They must also memorize, and manually type in each of those links every time. Or go through the dance of opening the link in Edge, then copy the address bar url from Edge and paste it into their development browser. What a pain. There is a reason you included buttons!
Compassionately include those users.
Personally, I only use Firefox and Chrome for development and personal browsing. Sometimes 1 browser is for development, while the other is for anything non-development related. My development browser changes depending on the year.
However, I purposely set my “Default Browser” to Edge as the system wide Windows 10 default.
I do this to capture any window that some program decides to automatically open: so that when random 3rd party software (or Windows notice) takes it upon itself to reach out to the internet and open a window, often without my knowledge or desire for it to do so, they are all captured in one place: Edge.
This keeps my workflow is not interrupted, and windows remain organized.
While I can rearrange my life, my workflow, for Local by Flywheel, I likely will not. I will likely choose to painstakingly type urls into my browser. Every time. Because sequestering random, auto links into a sequestered browser has served me quite well over the years. Anytime I change this behavior I regret it. And I’m not yet a power user of Local by Flywheel. I’m still trying to get it working! (Hyper-V incompatibility was a show stopper for 8 months.)
However, while I have a choice, many do not.
The resulting UX is terrible.
But worse, is that you don’t just state the issue and solution upfront. In prominent locations. Nobody should ever be unexpectedly greeted with “Cannot Load Site” message. This is COMPLETE AVOIDABLE. And a terrible first impression.
Between Hyper-V issue and Edge issue, setting up a dev environment is no easier or faster for Many, than using Local by Flywheel, than any other method: XAMPP, MAMP, DesktopServer. It’s still probably easier than Docker though.
Fortunately, you can virtually dissolve the issues with well placed information. In the case of Hyper-V, a little explanation should be included (how to check your Hyper-V setting in windows (before you even download or try installing the software !!), common reasons why you might have Hyper-V enabled or disabled: Docker, VirtualBox). This way people who aren’t super knowledgeable with those technologies can quickly be up to speed with how to make their computer compatible, and know if it even is).
Software solutions are ultimately on the wish list.
Documentation, and upfront communication in all relevant locations is king, prevents bad karma, and needless frustration. Why make potential users re-invent the wheel. You already convinced them to try a product of yours. Don’t break their faith, trust, and hope in you in the very next step.
Good tech companies need to have a forward facing component. Marketing is not the only thing. Compassion, to the customer, and word of mouth by customers are more important in the long run.
People remember how you made them feel.
Consider hiring someone who can step up your documentation game. Who can locate pain points and identify neglected user groups. Who can forward face people, communicate, and drive development that address these sort of issues that are currently a neglected blind spot within the organization.