Support

Home Forums Event Espresso Premium EE4 setting no-cache?

EE4 setting no-cache?

Posted: January 15, 2023 at 5:03 pm


Michael King

January 15, 2023 at 5:03 pm

Hi,
In the process of troubleshooting a different problem, my hosting company, DreamHost, noted that the Varnish cache they provide was not working. They suggested to me that the no-cache seemed to be coming from a plugin.

I spent some frustrating time this morning activating and deactivating all my plugins. Sometimes after deactivating EE4 and the Braintree gateway the no-cache situation would go away and all would be good, but sometimes that wasn’t the case. I never did find a combination of active and deactivated plugins that would work or not work all the time, so I went back to DreamHost and asked for further data. In response, they tell me they believe the problem comes from EE4. I’m going to paste their response below for your analysis, as this appears to be well beyond my capabilities as a user.

—–

Thank you for reaching back out to us. Sorry to hear you’re still having
problems with the server cache for the ninthdistrictpta.org site. I’ll be
happy to assist you further today!

And from what I found out, the Event Espresso plugin is the one creating
the cookie that’s conflicting with the server cache. For this case, I
would recommend disabling it to help get the server cache working and
speed up the site.

From there, you can also check its cookie with the plugin developer, so
they can update the Event Espresso plugin and make its cookie
cache-compatible. Once you also have the details from the plugin
developer, please let us know so we can check the changes or updates that
needs to be applied for the site or the plugin.

I would recommend having them check
the following plugin files, that’s creating a cookie:

$ cd
/home/wp_gddwn2/ninthdistrictpta.org/wp-content/plugins/event-espresso-core-reg
$ grep -Rilon -P -n
'(?:PHPSESSID|session_start|start_session|$cookie|setCookie)' .
./admin_pages/registrations/Registrations_Admin_Page.core.php
./admin_pages/transactions/Transactions_Admin_Page.core.php
./core/services/session/SessionStartHandler.php
./core/EE_Session.core.php
./vendor/phpcompatibility/php-compatibility/PHPCompatibility/Sniffs/FunctionUse/NewFunctionParametersSniff.php
./vendor/squizlabs/php_codesniffer/src/Standards/Generic/Sniffs/NamingConventions/CamelCapsFunctionNameSniff.php
./vendor/wp-coding-standards/wpcs/WordPress/Sniffs/WP/DeprecatedFunctionsSniff.php

When testing the site via SSH using the curl command while the plugin is
active, it is showing the following result:

$ curl -ILs https://www.ninthdistrictpta.org
HTTP/2 200
date: Sun, 15 Jan 2023 20:42:44 GMT
content-type: text/html; charset=UTF-8
content-length: 89557
server: Apache
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
link: <https://www.ninthdistrictpta.org/wp-json/>;
rel="https://api.w.org/"
set-cookie: PHPSESSID=3a9c4005816b4d0863e40471a53b4e2a; path=/
vary: User-Agent
x-cacheable: NO:Got Cookies
x-varnish: 2951754
age: 0
via: 1.1 varnish (Varnish/6.2)
x-cache: MISS
x-powered-by: DreamPress
accept-ranges: bytes
strict-transport-security: max-age=31536000

But when the plugin is deactivated, it shows the following result after
clearing the cache. The first curl command is expected to show a MISS
status, as the server cache was cleared in the test. The second curl
command now showed a HIT status, after the server cache was re-created
after the first curl command:

$ cd /home/wp_gddwn2/ninthdistrictpta.org/
$ wp plugin deactivate event-espresso-core-reg --skip-plugins
--skip-themes ; wp varnish purge
wp option get siteurl --skip-plugins
--skip-themes

 --wildcard --skip-themes
--skip-plugins=^'varnish-http-purge' ; wp cache flush --skip-themes
--skip-plugins ; curl -ILs
wp option get siteurl --skip-plugins
--skip-themes; curl -ILs
wp option get siteurl --skip-plugins
--skip-themes;

Plugin 'event-espresso-core-reg' deactivated.
Success: Deactivated 1 of 1 plugins.
Success: Proxy Cache Purge has flushed your cache.
Success: The cache was flushed.

HTTP/2 200
date: Sun, 15 Jan 2023 21:10:28 GMT
content-type: text/html; charset=UTF-8
server: Apache
link: <https://www.ninthdistrictpta.org/wp-json/>;
rel="https://api.w.org/"
x-cacheable: YES:Forced
cache-control: must-revalidate, public, max-age=300,
stale-while-revalidate=360, stale-if-error=43200
vary: Accept-Encoding
x-varnish: 3277300
age: 0
via: 1.1 varnish (Varnish/6.2)
x-cache: MISS
x-powered-by: DreamPress
accept-ranges: bytes
strict-transport-security: max-age=31536000

HTTP/2 200
date: Sun, 15 Jan 2023 21:10:29 GMT
content-type: text/html; charset=UTF-8
content-length: 84562
server: Apache
link: <https://www.ninthdistrictpta.org/wp-json/>;
rel="https://api.w.org/"
x-cacheable: YES:Forced
cache-control: must-revalidate, public, max-age=300,
stale-while-revalidate=360, stale-if-error=43200
vary: Accept-Encoding
x-varnish: 3277302 3277301
age: 0
via: 1.1 varnish (Varnish/6.2)
x-cache: HIT
x-powered-by: DreamPress
accept-ranges: bytes
strict-transport-security: max-age=31536000

Kindly provide them the details above, to help them check which cookie
created by the plugin is conflicting or disabling the server cache. If
you’d like to test it too, you can disable the Event Espresso plugin,
then clear the server cache using the steps from the link below:

https://help.dreamhost.com/hc/en-us/articles/215300647-Managing-the-DreamPress-cache#toc-heading7

Once cleared, you can then test the server cache by using the curl
command twice on the site via an online tool like the one from the
https://tools.keycdn.com/curl link, and check the x-cache status on the
second curl command results.

—-


Tony

  • Support Staff

January 17, 2023 at 5:49 am

Hi there,

Yes, we set a no-cache cookie when using Event Espresso.

Originally we tried to restrict that to only happen on specific pages, however, we ran into multiple issues where sessions were being wiped on X requests and breaking registrations.


Michael King

January 17, 2023 at 10:50 am

ummm….that’s stunning. So making our entire site never cached when EE4 is active is the best solution? I don’t recall that being disclosed anywhere – did I miss something? Seems like a situation that would make a lot of us admins unhappy.


Tony

  • Support Staff

January 18, 2023 at 6:03 am

So making our entire site never cached when EE4 is active is the best solution?

When Event Espresso shortcodes can be placed literally anywhere on the site and loaded in ways we can’t detect prior to the page loading, yes. It’s either that or the admin runs into issues with sessions breaking and registrations stop working with the current setup.

I don’t recall that being disclosed anywhere – did I miss something? Seems like a situation that would make a lot of us admins unhappy.

You can’t cache eCommerce requests so no, no disclosure as such. For Event Espresso to function the requests for each individual user can not be cached.

I’ll open a discussion to see if we have any plans to change this in the future.


Michael King

January 18, 2023 at 11:33 am

Ok, thanks. You can call this one closed.

You must be logged in to reply to this support post. Sign In or Register for an Account

Event Espresso