Closed jaswrks closed 7 years ago
@jaswsinc
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
There was no issue with loading any of the Sidebar Widgets, and they showed properly if configured with the right settings.
Here are some extra details I could gather from the thread, as well as with some testing:
home
and siteurl
are set to domain.com/wordpress
domain.com/wordpress/wp-json
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 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.
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.
Comet Cache Pro zip file (latest bleeding edge) for developer testing: https://cdn.wpsharks.com/software/bleeding-edge/comet-cache-pro/02803a39253a658.zip
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"
@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:
You are welcome!
Noting that testing will be continued once issue with Apache detection,(https://github.com/websharks/comet-cache/issues/748) is resolved
@raamdev @jaswsinc
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)
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.
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).
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.