corytrevor
Forum Replies Created
-
Hi @alina98
Sure thing, here’s the Gravity Forms notification settings which work fine with a different SMTP plugin – https://imgur.com/a/JUhz5Kf
When using SMTP for Amazon SES the email is delivered to [email protected] but not [email protected].
Thanks
Hi
The Reply-To header worked for me but BCC didn’t work when I tested with Gravity Forms.
Perfect, thanks for passing that on for the dev team to take a look at. Hopefully they can also update it on the SmashBalloon Instagram feed plugin as it uses the same notification template which causes the same issue.
Cheers
Thanks @wfpeter, that’s good to know. When I first saw it I though it was weird that a test ajax request would be using CPU but if it’s connected to the scan running then that makes sense.
Cheers
Thanks @sasonikolov, that fixed the fatal error when running wp cron. It now comes up with this warning though:
Warning: Invalid argument supplied for foreach() in /home/customer/www/example.com/public_html/wp-content/plugins/event-tickets-with-ticket-scanner/sasoEventtickets_Core.php on line 470Thanks
You’re welcome. Perfect, thanks @elenachavdarova
Cheers
Thanks for including a fix for this in the 7.2.7 update!
However, there is an issue with the implementation that means that the file-based caching still caches pages when the no-cache response header is present.
On line 231 of sg-cachepress/core/helper/File_Cacher_Trait.php it uses the stripos() function:
stripos(?trim(?$value?),?$ignore_headers[?$lowercase_header?]?)
In the context that it’s being used it needs to return a value of true for the if statement to work, but if the header string contains the ignore header then stripos() returns an integer – https://www.php.net/manual/en/function.strpos.php
An easy work around is just to use an is_int() check so on line 231 it would have:
is_int(stripos( trim( $value ), $ignore_headers[ $lowercase_header ] ))
I’ve tried it out with that modification and it works when I test it.
Cheers
Hi @elenachavdarova)
Thanks for your reply.
I’m not sure if I’m following correctly. In my example, the response headers are being used to exclude a page from being cached by the file-based caching, which it does successfully.
If a page is excluded from file-based caching then there’s no issue with the response headers not being present in a cached hit because the page will not be cached in the first place so there will be no cached hits.
There is also no issue with the dynamic cache in this case as the dynamic caching respects cache-control: no-cache.
Cheers
Hi Elena
Thanks for getting back to me.
Are you able to clarify if the intended functionality of the file-based caching is to ignore cache-control response headers?
Cheers
Hi, I noticed that a fix for this wasn’t included in the recent update.
Here are the steps to recreate the bug.
Add this code to a child theme to set the ‘cache-control: no-cache’ response header:
add_filter( 'wp_headers', function( $headers ) { unset( $headers['cache-control'] ); $headers['cache-control'] = 'no-cache'; return $headers; } );
Enable file-based caching and purge cache.
Open the network tab of dev tools in an incognito window, make sure ‘disable cache’ is unchecked and visit a page on the site and note the ‘cache-control: no-cache’ response header for the HTML.
If hosted on SiteGround, purge the dynamic cache in Site Tools.
Refresh the page and note the ‘sg-f-cache: HIT’ response header.So the page was cached by the file-based caching even though the ‘cache-control: no-cache’ header was set.
Here’s how to fix that. On line 225 in sg-cachepress/core/helper/File_Cacher_Trait.php replace apache_request_headers() with apache_response_headers()
Repeat the steps above, note how this time it has the ‘sg-f-cache: BYPASS’ response header as it is correctly bypassing the cache due to the presence of the ‘cache-control: no-cache’ response header.
All good so far, however if more cache-control parameters are added then it prevents the cache bypass due to the way it’s been coded to check if the header value is an exact match. To verify this, update the child theme code to:
add_filter( 'wp_headers', function( $headers ) { return array_merge( $headers, wp_get_nocache_headers() ); } );
This changes the cache-control header to ‘no-cache, must-revalidate, max-age=0’ but the plugin only checks if it’s an exact match for ‘no-cache’ so it caches it even though no-cache is set in the cache-control header.
This can be fixed by replacing the foreach loop beginning on line 225 with this code which uses str_contains() to check if ‘no-cache’ is part of the cache-control header value.
foreach ( apache_response_headers() as $header => $value ) { $lowercase_header = strtolower( $header ); $header_value = trim( $value ); if (array_key_exists( $lowercase_header, $ignore_headers )) { $header_ignore_value = $ignore_headers[ $lowercase_header ]; } // Do not cache if any of the ignore headers exists and matches the ignore header value. if ( isset($header_ignore_value) && str_contains($header_value, $header_ignore_value) ) { return true; } }
Please can you make sure one of the senior plugin developers takes a look a this issue. Let me know if you have any questions.
Cheers
Hi Pavel
Thanks for the explanation, I can understand wanting to keep things simple and easy to understand for the documentation. Fortunately, in this case it should be possible to do that whilst also keeping it accurate.
The files are stored in the browser memory.
The files are stored in a cache directory on the hard drive.Our plugin will create a static HTML version of your website and store it in the browser memory, considerably boosting your load speed.
This option creates a static HTML version of each page that can be served directly to visitors, considerably boosting page load speed.Cheers
Hi Georgi
Thanks for getting back to me. I understand how browser caching works, but the file-based caching doesn’t affect browser caching at all as it doesn’t add cache-control, expires, last-modified or etag response headers to the HTML files that it serves.
Cheers
Excellent, thanks @gpetrova
That’s great, thanks @gpetrova
Yes, and each caching has level has different response headers i.e sg-f-cache for the file-based cache and x-proxy-cache for the dynamic cache.
Here is how to replicate the missing ‘sg-f-cache: MISS’ header issue. On an SG hosted site, enable file-based caching and leave the ‘Preheat cache’ option unchecked. Then Purge SG Cache.
Visit the site in an incognito window with the network tab open in dev tools. Inspect the response headers and note that there’s an ‘x-proxy-cache: MISS’ header but there’s no ‘sg-f-cache: MISS’ header which you would expect there to be as the cached as the cache has just been purged.
Open sg-cachepress/core/File_Cacher/Cache.php and comment out line 138:
// $should_send_miss = false;
Repeat the previous steps and note that this time it correctly returns the ‘sg-f-cache: MISS’ header for a cache miss as you would expect it to do.
Thanks