Caching Compatibility

If you have a caching plugin (please only use one at a time) or any sort of system caching on your website or may notice Groundhogg not quite working as well and as quickly as you had hoped. There are some things you can do to get Groundhogg to be much quicker.

Browser Caching

Some caching plugins or systems will cache the website on the visitor’s computer so that when the visitor comes back it is much faster for them and the site doesn’t have to get a brand new copy just for that visitor. Most visitors won’t know that they have a cached version as it doesn’t make any difference for them.

It does make it difficult sometimes to help your customers who may be having an older version of your website cached on their computer as you won’t be able to see what it looks like to them. There are ways to ensure your customer has the latest version of your website when needed. Some of this you can tweak in your caching plugin or system (some solutions are available near the bottom of this page), and some you may need to talk to your hosting company or get an outside expert (like one of our certified partners) involved.

Expires: this will set when it does expire, and when it expires it will get a new one when the customer visits your website again. Most caching will have this set by default and most of time you won’t need to change it unless you know your website is going to be updated sooner. SEOquake has a great blog post on this if you want to read more.

Cache-control: this will control what individual pages will be cached. Most caching will have this set up or will allow you the option to control it on an individual basis. Some of the options for this include: no-cache (which means the browser will check to see if the cache it has is still current, if not then get a new one), public (meaning a CDN or other party can cache the website), private (meaning only the browser can cache), no-store (telling the browser not to cache anything). Cloudflare has more of an explanation if you are interested.

Last-modified: this says when the last time the content was modified. It will store the date and
time. An example would be Expires: Wed, 14 June 2011 10:30:07 GMT. LogicBig has moredetails that explain this if you are interested in it.

You can get the visitor to clear the cache from their system, or you can force the system to get a new copy. This will get the visitor’s system to load each page on your website like it’s the first time they have visited that page, it does lead to a bit slower loading times but it is almost a sure fire way to make sure someone sees the latest version of your website. If you want to tell your visitors to do this then you should point them to a guide on how to do it, like the one that Kinsta made.

Page Caching

Caching means putting all the pages in cache. There are positives and negatives to this, the main positive is that pages load quickly for someone who visits the page. The main drawback is that if you change the page often then the cache either shows an old copy or has to cache a copy of the new page before it is shown.

Most caching plugins do this by default, and they clear the cache for that page when it is updated. There is the option to turn the page caching off but we suggest you leave it on, and only turn it off if you are experiencing problems with it.

Groundhogg should work without any problems if you just cache pages, you most likely will have to read more of this document to know certain things to exclude. But otherwise it should work without any problems. If-so has a detailed blog post on this if you want to learn more.

Object Caching

With Groundhogg your customers will have personalized content (which will always show on the managed Groundhogg pages). That content depends on what you use Groundhogg for. If you use page caching then that personalized content may show a different customer from the one that clicked the link to that personalized content. You don’t want that, so that is where object caching comes into play.

Object caching stores part of a page and saves that for the future. An example would be if your customer is logged in and they go to a page that has a form for them to fill in. Object caching can know that the website has the details for the customer and you can get it to be autofilled.WordPress does have object caching built-in, which stores database queries in memory, as without it will result in an increase in load time and make the database be used more (which may result in you needing a more powerful database).

Your hosting company may use Redis, Memcached or something similar, both of which you can install yourself if your hosting company lets you. If you are unsure if your hosting company offers this then look in your control panel or contact them.

Hosting Company Caching

Your hosting company may cache things using a method.

Most of the time you can search online for the name of your hosting company and cdn or caching, to see what help documents come up that may help to guide you.

Many of these caches only cache the page so you may only have to exclude the Groundhogg
managed page. Some companies may cache more, so we suggest you contact your hosting
company if you have any questions about the caching they do and how to exclude what you
need.

Database Caching

Most likely your hosting company will manage your website’s database but you may have other
circumstances that require you to have a separate database. Since we can’t tell exactly what
powers your database we can’t give specifics on how to exclude the caching that the database
may do.

The database could cache anything, but most likely will cache the REST API, the Groundhogg
managed page, and potentially cron jobs. If you know you have a separate database and know
how to exclude what you need then go ahead and do that. If you have someone who runs your
website you can ask them if your website has a separate database and if so then do the
exclusion. Your hosting company could also have a separate database for your website, and if
that is the case then when you do the exclusion within your control panel.

If you are unsure then contact your hosting company who should be able to guide you through
any caching problems or understand what you may need.

Cloudflare (or any similar CDN)

If you use any sort of content delivery network (CDN) then this section is for you (like Cloudflare,
Amazon CloudFront, Fastly, Incapsula, or StackPath for example). If you don’t think you do then
skip this section or ask your hosting company if you use a CDN on your website.

A majority of Groundhogg will work without any problems, but you will need to exclude cookies,
exclude the REST API, exclude the managed page, and exclude the cron jobs (all of which is
explained more on this page). Each CDN company has their own way to exclude and some may
have plan limitations on the number of exclusions or bypasses you can do. Some may also see
that you are using WordPress so they may exclude certain things automatically without really
knowing about it.

Since each CDN company is slightly different in the way they do things, we would encourage
you to read the forum that the CDN company has, search online, and see what other customers
have done to set things up.

Exclude Cookies

Caching plugins or systems will sometimes cache cookies.For example, it could mean that your
customer could see that they haven’t completed a course, when in fact they completed the
course weeks ago. Because the cookie is holding the old data and keeping it for a certain period
of time, it is preventing the customer from moving onto the next level.

In order for everything to stay current you will need to exclude certain cookies that Groundhogg
creates. The cookies that Groundhogg currently uses can be found at the help doc on what cookies does Groundhogg create.

Exclude REST API

WordPress has an API it calls the REST API, in short it allows applications (like Groundhogg) to
interact with the rest of your Wordpress website.

WordPress has a whole REST API handbook if you are interested in reading more on it

Groundhogg uses this REST API for many things, and in future versions it will be used more. As
such, it’s important that the results from the API are not cached.

Right now please exclude the following route’s:

	/wp-json/gh/v3/.*
	/wp-json/gh/v4/.*

If you want to ensure that future versions of Groundhogg don’t get cached then you can exclude:

	/wp-json/gh/.*

Exclude The Managed Page

Groundhogg has what we call a “Managed Page” which is to show any contact areas of
Groundhogg that you can’t edit.

There are many of these pages, including but not limited to:

• Hosted form page (any forms you have, they can be shown anywhere on your
  WordPress site or on another website)
• Page to show email address has been confirmed
• Tracking links (any links that are in your emails, they are tracked so you can know what
  links your email subscribers click on)
• Page to show email preferences (allow someone to customize how many emails they get
  or don’t get)
• Page to allow the person to unsubscribe
• Page to show that the person has confirmed their email address
• Allow the person to view the email that you sent in their browser (that little view in
  browser link at the top of the email)

	https://yoursite.com/gh/*
	

	/gh/(.*)
	/gh-cron.php
	/aws-cron.php
	

	^/gh/
	^/gh-cron.php
	^/aws-cron.php
	

	/gh*
	/aws*
	

	/gh/*
	/gh*
	/aws*
	

	/gh
	/gh-cron.php
	/aws-cron.php
	

	gh/(.*)
	gh-cron.php
	aws-cron.php
	

	^/gh/
	/gh-cron.php
	/aws-cron.php
	

	/gh*
	/aws*
	

	/gh.*
	/aws.*
	

Known Redis Conflict

If you are on GridPane or any other server that implements Redis Caching, you may need to request that this caching protocol be turned off on your server. A known compatibility issue will cause the gh-cron.php to fire but have no trigger action, causing your funnel steps to remain in the "running now" status.