Cornerstone Plugin Compatibility

[jaswrks]

A customer writes...

Cornerstone is a page editor that comes with the X Theme by Themeco it basically allows more functionality to design how posts and pages are laid out, however for some reason Comet Cache prevents Cornerstone from loading, and am forced to disable the plugin when ever i need to make changes

Referencing internal/private ticket: https://secure.helpscout.net/conversation/351920691/922/?folderId=1246818

[andysallis]

As Requested here is the theme I am using that Comet Cache does not work with. x.zip

[monokee]

I just ran into this. Utilizing a URI exclusion pattern (/x/**) in the pro version of Comet Cache also does not help. Any insights into where I can start looking for a fix @jaswrks ?

[renzms]

Reported in Support

Referencing internal ticket here

[raamdev]

@renzms If you could attempt to reproduce this for us and include a detailed report of the issue, that would be great.

[monokee]

Even though I'm a pro customer, I'm not neccessarily expecting a perfect quick fix here. But if you have any pointers as to where I might start looking for the issue myself I'd really appreciate it. There have been some forum posts on themeco support about this but no public fix or workaround has been proposed from either side. I'd need some input from someone who knows the codebase to start looking into it though.

[renzms]

Unable to reproduce issue

Comet Cache Pro and Cornerstone confirmed working while both are active and enabled.

@raamdev

---

Tested Using the following:

WordPress Version: 4.8.1 Current WordPress Theme: Twenty Seventeen version 1.3

Active Plugins: Comet Cache™ Pro v170220 / Comet Cache™ Pro v170808-RC | Cornerstone Version 2.0.6 MySQL Version: 10.0.31-MariaDB-0ubuntu0.16.04.2

---

After activating/enabling Comet Cache Pro and installing Cornerstone, I was able to launch Cornerstone successfully from the plugin itself.

The Cornerstone plugin was able to load and initialize properly.

There was also no issue clicking and editing from a Page/Post itself.

I was able to edit/update/save/and add elements to Pages/Posts using Cornerstone without issue:

The following HTML notes show that Comet Cache is not caching when Cornerstone is active

<!-- Comet Cache is NOT caching this page, because `$_SERVER['REQUEST_METHOD']` is `POST`, `PUT`, `DELETE`, `HEAD`, `OPTIONS`, `TRACE` or `CONNECT`. These request methods should never (ever) be cached in any way. -->

---

Additional Testing with HTML Compressor Active:

No issues found with both plugins active, Cornerstone loaded successfully and I was able to update elements using Cornerstone.

On the front end, the Comet Cache Pro plugin works normally and caches for non-logged in users.

[raamdev]

@monokee @andysallis Please see @renzms's testing report above. He wasn't able to reproduce any issue with the Cornerstone plugin.

I'm going to close this issue, but if you can update us with a few steps to reproduce the issue in a clean WordPress installation, I can reopen this for further testing.

[Pixel8rx]

I still have a problem with launching Cornerstone while Comet Cache is active.

I am using X v 5.2.2 & Cornerstone v2.1.3, when I try to start Cornerstone to edit a page when Comet Cache is active it won't start. If I then dectivate Comet Cache it loads just fine.

Prehaps you could test this using the X theme, which is the theme that Cornerstone is supplied with, rather than the Twenty Seventeen one.

[monokee]

When bundled with Themeco's X and Pro themes, Cornerstone is not installed to the wordpress plugin directory but integrated into the theme codebase and likely configured differently than a separate plugin installation - which absolutely won't make this any simpler to debug. :/

[dtwist]

I encountered this issue on one of the sites we manage (we host dozens of x/pro sites, and most of them use Comet cache without issue.)

I tracked the problem down to Comet Cache's setting "Apache optimizations » Enforce Canonical URLs", which adds the following to the site's .htaccess file:

# 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(?:/|$)

  # Not a REST request, which never redirects.
  RewriteCond %{REQUEST_URI} !(?:^|/)wp-json(?:/|$)

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

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

Cornerstone POSTs JSON payloads to the URI "/cornerstone-endpoint", and expects a JSON response. With the Comet Cache setting enabled, these POSTs are being 301 redirected to a GET at the canonicalized URI "/cornerstone-endpoint/" (adds the trailing slash).

Modifying the .htaccess code manually to include a condition requiring the request be a GET if it is to be rewritten solves the problem:

  # Only capture GET requests
  RewriteCond %{REQUEST_METHOD}  =GET

(The full rules then look as follows)

# 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(?:/|$)

  # Not a REST request, which never redirects.
  RewriteCond %{REQUEST_URI} !(?:^|/)wp-json(?:/|$)

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

  # Only capture GET requests
  RewriteCond %{REQUEST_METHOD}  =GET

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