Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: improve web host detection in System Info #3356

Closed
2 tasks
Benunc opened this issue Jun 12, 2018 · 10 comments
Closed
2 tasks

fix: improve web host detection in System Info #3356

Benunc opened this issue Jun 12, 2018 · 10 comments
Assignees

Comments

@Benunc
Copy link
Member

Benunc commented Jun 12, 2018

User Story

As a support technician, I want to know at a glance what web host a customer is using so that I can tailor my responses to their specific needs.

The system info at Tools > System Info is notoriously unreliable, and almost never returns the name of a web host.

Current Behavior

I currently have to guess from context clues what the host is, or ask the customer, creating more back-and-forth.

Expected Behavior

I expect to be able to read it in the system info.

Possible Solution

According to Dwayne at Pantheon:

"Just curl -I the site and read the headers"
X-Pantheon-Environment: live should be in the header on any Pantheon site

Steps to Reproduce

  1. Check the system info from an install on a live server.
  2. There will likely be no host listed.

Tasks

  • create a method for reliably getting the web host information
  • ensure that the fix works on all major WordPress web hosts
@kevinwhoffman
Copy link
Contributor

We'll look into this further, but there's not a foolproof method for host detection.

Tricky stuff:

  • Not all hosts provide a host-specific header like the Pantheon example.
  • If the site is served through a CDN, then the server can be detected as the CDN's server and not the original host. For example, you might see Securi as the host instead of the actual hosting provider.

@Benunc Can you provide examples of what you typically see that is unhelpful so I can get a better idea of what is being detected?

@Benunc
Copy link
Member Author

Benunc commented Jun 13, 2018

Usually, we see things like Hosting Provider: DBH: sql23.cpt1.host-h.net, or just an IP address, or Hosting Provider: DBH: localhost, SRV: example.com

I've learned to spot the hostingresources.com sites as Godaddy. The only one that routinely gets it right is WP Engine

@mathetos
Copy link
Member

@kevinwhoffman I asked several popular hosts and they all said essentially what Dwayne said above. While it's not perfect, it's better than:
A) What we currently have
B) Having to ask the customer that in the Support form.

@kevinwhoffman
Copy link
Contributor

There's not a consistently reliable way to do this across hosts based on headers. The examples you've provided for Pantheon and Siteground do not show those headers when I actually curl websites that I know are hosted by those companies. Also any use of a CDN will disguise the host.

The existing functionality was forked from Woo and is based on detecting constants specific to hosting providers. The constants may be outdated and/or not in use anymore, but IMO this would be a more reliable solution because it's checking based on the server of the WordPress site that the user is logged into rather than headers based on a remote request.

All of that aside, my recommended solution is to put a field in the support form and let the customer tell us where they are hosted when requesting support.

@Benunc
Copy link
Member Author

Benunc commented Jun 13, 2018

I can go either way. I don't love the idea of more friction on the support form, and I don't think that having the host info will help enough to warrant adding a field there. I defer to @mathetos on this, but my opinion is to see if we can make those constants more reliable, and if not, just leave it alone. This has been a helpful discussion.

@kevinwhoffman
Copy link
Contributor

@mathetos Let's discuss this on next Product Management call if you have a better approach to try.

@mathetos
Copy link
Member

@kevinwhoffman Sounds good. In advance of that meeting, feel free to review this:
https://github.com/mathetos/Whos-My-Host

I did a bunch of user testing with a lot of different WPers I know who use different popular WordPress hosts with that functionality plugin in order to generate this research on this:
https://docs.google.com/document/d/1Go5xB88JrC7hYBgO_vBptt3ysFu-LFdwDyZxtk-na0A/edit?usp=sharing

Additionally, this is the resulting function I created based on all of the above:
https://github.com/impress-org/wp-business-reviews/blob/3a73d0c235e7a874209888c488a7aaafa3101309/includes/admin/class-system-info.php#L151-L178

It's unclear to me whether that was ever integrated into WPBR's final System Info host check or not, but I do know based on all the above that it does provide much more accurate and current Hostname data.

@kevinwhoffman
Copy link
Contributor

Yes we discussed this when adding System Info to WPBR. The issue I brought up then was that the approach you shared is based on string detection from the returned value of gethostname(). If that string is not matched, then System Info will display We cannot determine your web host. Please mention it in your support ticket.

When I tested with Pagely, for example, that string was not found. So rather than take a chance in checking for a few hosts based on strings that may or may not be present today, I just returned the raw value of gethostname() so that System Info always always shows something.

The downside is that the returned value does not always clearly indicate the host. The upside is we don't "miss" on the host detection and return nothing of use.

If we really wanted to nail this, I think we need to reach out to the major hosts and get an up-to-date answer on how to detect their host. This may be in the form of string detection, headers, or a server variable. Based on my experience the first time around, there was not a one-size-fits-all solution.

@mathetos
Copy link
Member

I did reach out to hosts and String detection was the only way to get accurate info, but I TOTALLY agree that the fallback should instead just output that string instead of the generic message.

There is not a one-size-fits-all solution at all. So this will most likely need to be updated maybe annually. But I think this is FAR more informative and helpful than the current function. I believe Pagely's output is very obvious so the function can easily be updated to reflect that.

@kevinwhoffman
Copy link
Contributor

@DevinWalker Use the logic from https://github.com/mathetos/Whos-My-Host/blob/master/whos-my-host.php#L210-L220 and return the raw value of gethostname() if there is not a match.

@kevinwhoffman kevinwhoffman changed the title fix(system-info): make the web host line on the system info more reliable and actionable fix: improve web host detection in System Info Feb 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants