I have been talking to site ground about the speed of my site and they noticed that within the headers there was the following added by WpForo:
cache-control: no-store, no-cache, must-revalidate pragma: no-cache
Which was causing issues to the dynamic caching of the website. Is there a way to prevent these headers so it doesn't interfere with the dynamic cache?
I am using the siteground SG Optimiser plugin for my cache.
Extra info, disabling WpForo take 2 seconds off my site loading time in GTmetrix.
Nothing like that is added by wpForo, not in my sites.
As for the extra 2 seconds added, what exactly is the question?
Also no caching works right with wpForo, this has been talked and even pinned here. Exclude wpForo from any caching and/or optimizer. At least until you have a need for them. When that time arrives, there is also plenty of info posted here.
I have excluded WpForo from the cache. When I disable WpForo the issue goes away so it is caused by the plug in.
Ok, we've sleuthed and solved this problem, at least for ourselves.
The issue is that when session_start() is called, PHP does whatever session_cache_limiter() is set for it to do. And, by default, it's set to nocache which, as you might now guess, yields:
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
In and of itself, this is fine. The problem is that wpForo is calling session_start() for ALL requests, including those that aren't logged in. Why, of course, is something perhaps the admins here might be able to answer.
But we can get around it. I'll add the caveat that what we've done works on our server with our setup. It probably will work for many others, but I can't guarantee that, of course.
We fixed it by editing wp-content/plugins/wpforo/wpf-includes/class-notices.php and adding the (current as of the date of this post) line 16 session_cache_limiter('');. Essentially replacing the three-line function that's there with this four-line one, adding the bolded/red line:
private function init(){
session_cache_limiter('');
if( !wpforo_is_session_started() && ( !is_admin() || (!empty($_GET['page']) && strpos($_GET['page'], 'wpforo-') !== false ) || (wpforo_is_ajax() && !empty($_POST['action']) && false !== strpos($_POST['action'], 'wpforo')) )) session_start();
}
wpForo is still starting its session on non-logged-in users, but now it's not causing the no-cache headers to be sent. The good news is that when a Wordpress user is logged in, that causes Wordpress's no-cache headers to be sent, accomplishing pretty much the same goal.
This seems to affect every single site upon which wpForo runs, including this site and the entire gVectors.com site, too.
I'll be curious to hear what the wpForo authors think about all this.