wpsharks / comet-cache

An advanced WordPress® caching plugin inspired by simplicity.
https://cometcache.com
GNU General Public License v3.0
77 stars 18 forks source link

Enhance Jetpack Compatibility #855

Closed jaswrks closed 7 years ago

jaswrks commented 7 years ago

Referencing Comet Cache mentioned here: https://wordpress.org/support/topic/extra-sidebar-widgets-not-working/#post-8493697

It seems there could be some WP REST API responses getting cached by Comet Cache and as a result, some Jetpack module activations are not possible when Comet Cache is running.

Further testing is required to confirm and identify the cause of this.

renzms commented 7 years ago

@jaswsinc

Unable to reproduce bug as experienced by customer

Are there any additional details or steps needed to test further?

WordPress Version: 4.6.1 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 Version 161119 | Jetpack Version 4.4.1 PHP Version: 7.0.10-2+deb.sury.org~xenial+1

Steps taken

There was no issue with loading any of the Sidebar Widgets, and they showed properly if configured with the right settings.

jeherve commented 7 years ago

Here are some extra details I could gather from the thread, as well as with some testing:

curl -I http://www.cookingwithpeachy.com/wordpress/wp-json/oembed/1.0
HTTP/1.1 301 Moved Permanently
Date: Thu, 01 Dec 2016 14:48:08 GMT
Server: Apache
Location: http://www.cookingwithpeachy.com/wp-json/oembed/1.0/
Cache-Control: max-age=2592000
Expires: Sat, 31 Dec 2016 14:48:08 GMT
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
raamdev commented 7 years ago

I also ran Comet Cache Pro v161119 + Jetpack v4.4.1 through some tests and I was unable to reproduce any problem when activating the Jetpack Extra Sidebar Widgets.

The only non-default Comet Cache options that I thought might be related to this are 404 Request caching, GET Request caching, and the HTML Compressor (which also compresses JSON; see https://github.com/websharks/comet-cache/issues/469 and https://github.com/websharks/html-compressor/issues/59). However, I wasn't able to reproduce any issue while testing with those features enabled.

jaswrks commented 7 years ago

Thanks for additional details! :-)

@jeherve writes...

Is there a specific Comet Cache setting that maybe @renzms and I didn't enable, and that could create this redirection when Comet Cache is active?

@renzms Please try running this on an Apache server with Comet Cache 'Pro' Apache Optimizations enabled. See: Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations

From that pane, note the setting for: Enforce Canonical URLs?

That setting could be forcing a redirect that is incompatible with REST API endpoints.

curl -I http://www.cookingwithpeachy.com/wordpress/wp-json/oembed/1.0
HTTP/1.1 301 Moved Permanently
Date: Thu, 01 Dec 2016 14:48:08 GMT
Server: Apache
Location: http://www.cookingwithpeachy.com/wp-json/oembed/1.0/

Note the trailing slash was forced in that test.

jaswrks commented 7 years ago

Comet Cache Pro zip file (latest bleeding edge) for developer testing: https://cdn.wpsharks.com/software/bleeding-edge/comet-cache-pro/02803a39253a658.zip

VR51 commented 7 years ago

Adding here because this may be related.

I had a site that has been incompatible with Jetpack since the 24th November, not that I noticed until my WP Stats vanished (Jeremy, this isn't the WPML site I contacted Jetpack support about last week -- different issue, different site). Attempts to reactivate WP Stats or many other Jetpack modules resulted in endpoint errors.

To fix the issue I had to remove the Comet Cache directives from .htaccess, activate Jetpack modules then resave the Comet Cache settings. That's the only change to the site's configuration that resolved the issue.

Before I edited .htaccess I tried (without good result),

Here are the Comet Cache directives I removed from .htaccess:

# BEGIN Comet Cache WmVuQ2FjaGU (the WmVuQ2FjaGU marker is required for Comet Cache; do not remove)

# Enable GZIP compression.
<IfModule deflate_module>
  <IfModule filter_module>
    AddOutputFilterByType DEFLATE text/plain text/html
    AddOutputFilterByType DEFLATE text/xml application/xml application/xhtml+xml application/xml-dtd
    AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml image/svg+xml
    AddOutputFilterByType DEFLATE text/css text/javascript application/javascript application/x-javascript
    AddOutputFilterByType DEFLATE font/opentype application/font-otf application/x-font-otf
    AddOutputFilterByType DEFLATE font/truetype application/font-ttf application/x-font-ttf
  </IfModule>
</IfModule>

# Enable browser caching.
FileETag mtime size

<IfModule expires_module>
  ExpiresActive on
  ExpiresDefault "access plus 1 week"
</IfModule>

# Force a trailing slash on all virtual requests (except WP admin area).
<IfModule rewrite_module>
  RewriteEngine On
  RewriteBase /

  # If not a real file or directory.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d

  # Not a part of the WP admin area.
  RewriteCond %{REQUEST_URI} !(?:^|/)wp\-admin(?:/|$)

  # If there is no trailing slash.
  RewriteCond %{REQUEST_URI} !/$

  # Force a trailing slash on all virtual requests.
  RewriteRule ^(.*)$ $1/ [QSA,L,R=301]
</IfModule>

# END Comet Cache WmVuQ2FjaGU

The above is identical to the new directives put into .htaccess when the Comet Cache options are resaved.

The End Point errors occur whenever those rules are in .htaccess so the above solution is temp.

Using Comet Cache Pro 161119 + Jetpack 4.4.1

The error displayed by Jetpack when attempts are made to reactive modules is:

"JSON API failed to activate. Error: No route was found matching the URL and request method"

raamdev commented 7 years ago

@VR51 Thanks so much for that report! That just pinpointed the issue.

As Jason suspected earlier, the Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations → Enforce Canonical URLs? is causing this problem.

To reproduce the issue, I simply enabled that option in Comet Cache Pro, saved the Comet Cache settings, then tried to enable Extra Sidebar Widgets inside Jetpack:

2016-12-04_19-39-03

If I disable the Apache Optimizations Enforce Canonical URLs? in Comet Cache Pro and then attempt to enable the Jetpack Extra Sidebar Widgets again, it works:

2016-12-04_19-43-58

VR51 commented 7 years ago

You are welcome!

renzms commented 7 years ago

Noting that testing will be continued once issue with Apache detection,(https://github.com/websharks/comet-cache/issues/748) is resolved

renzms commented 7 years ago

@raamdev @jaswsinc

Fix Confirmed Working

Tested Using:

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: Jetpack Version 4.6 / Comet Cache Pro Version 170209-RC PHP Version: 7.0.10 MySQL Version: 10.0.29-MariaDB-0ubuntu0.16.04.1 Apache Version: Apache/2.4.10 (Debian)

screen shot 2017-02-13 at 5 11 05 pm

screen shot 2017-02-13 at 5 06 31 pm

Enabling: Dashboard → Comet Cache Pro → Plugin Options → Apache Optimizations → Enforce Canonical URLs? no longer causes an issue with enabling Jetpack's Extra Sidebar Widgets.

Continued testing for other Apache Optimizations and other options in Jetpack's panel, as well as testing with Network Site options. Both plugins are confirmed working.

raamdev commented 7 years ago

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 (#855).