Apache detection not always accurate

[raamdev]

As of v160417, Comet Cache is not properly setting the $is_apache and $is_nginx globals, which means the routines that rely on checking the values of those globals are not behaving as expected.

As Jason mentions below, those globals are set by WordPress, so the fact that we have a report indicating that Apache-only routines ran when Nginx was being used indicates that there must be a failure occurring with the detection.

For example, if WordPress incorrectly reports that the web server is Apache, then Comet Cache will attempt to add or remove from the .htaccess file, which in certain scenarios results in site owners who are running Nginx seeing an annoying message about Comet Cache being unable to add/remove from the .htaccess file (which isn't even applicable in their case).

Failed to update your /.htaccess file automatically. Most likely a permissions error. Please make sure it has permissions 644 or higher (perhaps 666). Once you've done this, please try saving the Comet Cache options again.

While we have a utility to check if the web server is Apache or Nginx, we're not actually using those utilities at the moment.

We might also be able to improve the Dashboard messages that are web-server specific. For example, we might add a link to the message that says "Not using Apache?" that dismisses the notice and sets an option key so as to prevent Apache-related errors from appearing.

---

Originally reported in this private ticket: https://websharks.zendesk.com/agent/tickets/12292

[jaswrks]

While we have a utility to check if the web server is Apache or Nginx, we're not actually using those utilities to set the $is_apache and $is_nginx globals.

Just wanted to mention that we shouldn't set those globals in the CC plugin. Those are WordPress core globals. See: https://github.com/WordPress/WordPress/blob/703d5bdc8deb17781e9c6d8f0dd7e2c6b6353885/wp-includes/vars.php#L100

I can't be sure until I look closer, but those isApache(), isNginx() methods may have been introduced by me at some point in order to make it possible for us to run those checks in the early phase of WordPress; i.e., before the globals are available maybe.

[raamdev]

@jaswsinc Thanks. I didn't realize those were set by WordPress. I've updated my original issue above to clarify the problem and I've removed the high priority label, as it sounds like this is not as widespread as I thought it might be.

[renzms]

@raamdev @jaswsinc

Possible bug regarding server detection

APACHE

WordPress Version: 4.7.2
Current WordPress Theme: Twenty Sixteen version 1.3
Theme Author: the WordPress team - https://wordpress.org/
Theme URI: https://wordpress.org/themes/twentysixteen/
Active Plugins: Comet Cache Pro v170201-RC
PHP Version: 7.0.10
MySQL Version: 10.0.29-MariaDB-0ubuntu0.16.04.1
Apache Version: Apache/2.4.10 (Debian)

Comet Cache Pro v170201-RC

Apache Panel Seems to be missing

Same site using Comet Cache Pro v161227

Apache Panel is there

NGINX

WordPress Version: 4.7.2
Current WordPress Theme: Twenty Seventeen version 1.1
Theme Author: the WordPress team - https://wordpress.org/
Theme URI: https://wordpress.org/themes/twentyseventeen/
Active Plugins:
PHP Version: 7.0.10-2+deb.sury.org~xenial+1
MySQL Version: 10.0.29-MariaDB-0ubuntu0.16.04.1
Apache Version: This information is not available.

Comet Cache detects NGINX and prompts user

Apache Panel is present

[jaswrks]

Apache Panel is present
... on Nginx but not the other way around.

---

@renzms Great catch. I left a ! behind in the code following tests of my own. Thanks for spotting this and helping us avoid this going out in a release that way.

Fixed in last commit.

[renzms]

@raamdev @jaswsinc

Fix Confirmed Working

This is now working correctly for Comet Cache Pro v170209-RC , the options show in the appropriate user case for the appropriate server.

Apache Optimizations also working properly when enabled.

[raamdev]

Comet Cache v170220 has been released and includes changes from this GitHub Issue. See the v170220 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#748).