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

Apache detection not always accurate #748

Closed
raamdev opened this Issue Apr 23, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@raamdev
Contributor

raamdev commented Apr 23, 2016

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

@raamdev raamdev added this to the Next Release milestone Apr 23, 2016

@jaswrks

This comment has been minimized.

Member

jaswrks commented Apr 23, 2016

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 raamdev changed the title from $is_apache and $is_nginx globals are not being set to Apache detection not always accurate Apr 23, 2016

@raamdev raamdev removed the high priority label Apr 23, 2016

@raamdev

This comment has been minimized.

Contributor

raamdev commented Apr 23, 2016

@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.

@raamdev raamdev modified the milestones: Next Release, Future Release May 11, 2016

@raamdev raamdev modified the milestones: Next Release, Future Release Jun 20, 2016

@raamdev raamdev modified the milestones: Next Release, Future Release Aug 24, 2016

@raamdev raamdev modified the milestones: Next Release, Future Release Oct 7, 2016

@raamdev raamdev modified the milestones: Next Release, Future Release Nov 22, 2016

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Jan 27, 2017

jaswsinc
- **Bug Fix:** Apache detection sometimes inaccurate. So instead of u…
…sing default WP core globals for server detection, Comet Cache now uses it's own set of Apache/Nginx/IIS detection functions. And, this release enhances our Apache and Nginx detection routines; making them smart enough to catch additional edge cases; i.e., to further reduce the likelihood of there being a false-positive. See [Issue #748](websharks/comet-cache#748).

- **Bug Fix:** Some Jetpack API calls were being cached inadvertently. See [Issue #855](websharks/comet-cache#855).
- **Bug Fix:** Some XML-RPC and REST API requests were being cached inadvertently. See [Issue #855](websharks/comet-cache#855).
- **Bug Fix:** Some REST requests were being redirected incorrectly whenever Apache Optimizations were enabled. See [Issue #855](websharks/comet-cache#855).
- **Bug Fix:** Broken textarea field due to `white-space:nowrap` in Firefox. See [Issue #866](websharks/comet-cache#866).
- **Enhancement:** Notes in HTML source now indicate fully functional on first load for improved clarity. See [Issue #860](websharks/comet-cache#860).

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Jan 27, 2017

jaswsinc

raamdev added a commit that referenced this issue Feb 1, 2017

Phing release of v170201-RC with the following changes:
- **New Feature:** Comet Cache can now be configured to automatically clear the cache for date-based archive views whenever any single post is cleared due to changes in content, title, etc. See: **Dashboard → Comet Cache → Plugin Options → Automatic Cache Clearing → Auto-Clear "Date-Based Archives" Too?**. See also: [Issue #724](#724).
- **New Pro Feature:** Apache Optimizations now include a new option that allows site owners to enforce an exact host name for all requests. See: **Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations → Enforce an Exact Host Name?**. See also: [Issue #101](#101).
- **Bug Fix:** Apache detection sometimes inaccurate. So instead of using default WP core globals for server detection, Comet Cache now uses it's own set of Apache/Nginx/IIS detection functions. And, this release enhances our Apache and Nginx detection routines; making them smart enough to catch additional edge cases; i.e., to further reduce the likelihood of there being a false-positive. See [Issue #748](#748).
- **Bug Fix:** Some XML-RPC and REST API requests were being cached inadvertently. See [Issue #855](#855).
- **Bug Fix:** Broken textarea field due to `white-space:nowrap` in Firefox. See [Issue #866](#866).
- **Bug Fix:** This release resolves empty directories being left in the cache folder, in some scenarios. See [Thread #866](https://forums.wpsharks.com/t/cache-folders-not-removed-during-clean-up-process/866).
- **Bug Fix** (Pro): Some REST requests were being redirected incorrectly whenever Apache Optimizations were enabled. See [Issue #855](#855).
- **Compatibility Bug Fix:** Some Jetpack API calls were being cached inadvertently. See [Issue #855](#855).
- **Enhancement:** Notes in HTML source now indicate fully functional on first load for improved clarity. See [Issue #860](#860).
- **Code Cleanup:** Enhancing security by removing `basename(__FILE__)` from direct access notices.
@renzms

This comment has been minimized.

renzms commented Feb 3, 2017

@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

screen shot 2017-02-03 at 8 31 02 pm

Same site using Comet Cache Pro v161227

Apache Panel is there

screen shot 2017-02-03 at 8 33 28 pm

screen shot 2017-02-03 at 8 33 37 pm

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

screen shot 2017-02-03 at 8 30 15 pm

Apache Panel is present

screen shot 2017-02-03 at 8 30 28 pm

jaswrks pushed a commit to websharks/comet-cache-pro that referenced this issue Feb 9, 2017

@jaswrks

This comment has been minimized.

Member

jaswrks commented Feb 9, 2017

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

This comment has been minimized.

renzms commented Feb 13, 2017

@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 added a commit that referenced this issue Feb 20, 2017

Phing release of v170220 with the following changes:
- **New Feature:** Comet Cache can now be configured to automatically clear the cache for date-based archive views whenever any single post is cleared due to changes in content, title, etc. See: **Dashboard → Comet Cache → Plugin Options → Automatic Cache Clearing → Auto-Clear "Date-Based Archives" Too?**. See also: [Issue #724](#724).
- **New Pro Feature:** Apache Optimizations now include a new option that allows site owners to enforce an exact host name for all requests. See: **Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations → Enforce an Exact Host Name?**. See also: [Issue #101](#101).
- **Bug Fix:** Apache detection sometimes inaccurate. So instead of using default WP core globals for server detection, Comet Cache now uses it's own set of Apache/Nginx/IIS detection functions. And, this release enhances our Apache and Nginx detection routines; making them smart enough to catch additional edge cases; i.e., to further reduce the likelihood of there being a false-positive. See [Issue #748](#748).
- **Bug Fix:** Some XML-RPC and REST API requests were being cached inadvertently. See [Issue #855](#855).
- **Bug Fix:** Broken textarea field due to `white-space:nowrap` in Firefox. See [Issue #866](#866).
- **Bug Fix:** This release resolves empty directories being left in the cache folder, in some scenarios. See [Thread #866](https://forums.wpsharks.com/t/cache-folders-not-removed-during-clean-up-process/866).
- **Bug Fix** (Pro): Some REST requests were being redirected incorrectly whenever Apache Optimizations were enabled. See [Issue #855](#855).
- **Compatibility Bug Fix:** Some Jetpack API calls were being cached inadvertently. See [Issue #855](#855).
- **Enhancement:** Notes in HTML source now indicate fully functional on first load for improved clarity. See [Issue #860](#860).
- **Enhancement:** Enhancing security by removing `basename(__FILE__)` from direct access notices.
@raamdev

This comment has been minimized.

Contributor

raamdev commented Feb 20, 2017

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).

@raamdev raamdev closed this Feb 20, 2017

@websharks websharks locked and limited conversation to collaborators Feb 20, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.