Enhance Jetpack Compatibility

[jaswrks]

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]

@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

• tested using WP REST API, and WordPress.com App to update settings and Page/Posts on site
• Enabled Comet Cache Pro to cache pages
• Configured Jetpack Plugin and added Extra Sidebar Widgets, configured Sidebar Widgets and viewed on front end

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

[jeherve]

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

• WordPress is installed in a subdirectory on the user's site: both home and siteurl are set to domain.com/wordpress
• They run WordPress 4.6.1.
• One can access the list of available routes on the site without any issues, at domain.com/wordpress/wp-json
• All the routes, including WordPress' only enabled route so far, oembed/1.0, redirect to the version of the site without /wordpress, thus returning a 404.

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

• I wasn't able to reproduce the issue on a test site of mine, even after enabling Comet Cache and enabling it.
• Apparently, disabling Comet Cache helped the user.
• 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?

[raamdev]

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 #469 and wpsharks/html-compressor#59). However, I wasn't able to reproduce any issue while testing with those features enabled.

[jaswrks]

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]

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

[VR51]

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

• Disabling/Enabling plugins,
• Clearing the browser cache,
• Clearing the Comet Cache (manual delete too),
• Purging Cloudflare,
• Placing Cloudflare into development mode,
• Reauthorising Jetpack to connect with wordpress.com,
• Resaving permalinks,
• Checking/reconfiguring PHP modules
• ...

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]

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

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:

[VR51]

You are welcome!