Jesse Owens

Hi @emilianomaina

With your current setting to Automatically Prime the Page Cache every 900 seconds, I’m guessing setting that to 86400 will likely resolve the issue. The settings as you have them now will flush and regenerate the cache for 10 pages every 15 minutes, so if you had around 40 total pages, you would expect an individual page to be “modified” about once per hour. Replace the value 900 with the new value.

You mentioned that you see Expires header lifetime as 31536000, but I do want to make sure that you check all three sections (CSS & JS, HTML & XML, and Other) in Browser Cache. Specifically, the HTML and XML is set to one hour (3600) by default. You’ll want to update that setting to match your 86400.

Finally, no you don’t need to pay any more for Pro Support, it’s simply a policy of the www.ads-software.com Forums that plugins cannot support paid-only features here in the public forums. You can use any of the free options in Performance > Support to reach us privately, or you can use our dedicated support forum on boldgrid.com.

Hi @emilianomaina

Thanks for the great and detailed question!

I can think of a couple more things to check.

First, check Performance > Page Cache and double-check that the setting Automatically Prime the Page Cache is not enabled, or at least has the same 86400 lifespan that you’re using for the settings you mentioned.

Next, check the Performance > Browser Cache section and double-check the lifetime of your expires headers. By default, these are set to 3600 (1 hour) so that could also account for the headers you’re seeing.

Finally, yes you can enable the Purge Cache logs in Performance > General > Debug. However, since that is a Pro feature, if you need help interpreting those logs please reach out in the Pro Support system, which you can access directly through Performance > Support— we’re not able to provide support for Pro features here on the www.ads-software.com repository, only free features.

Hello @likhonbd33

Thanks for reaching out, I understand it’s vital to know how those files are being created. If W3 Total Cache is not installed and active, it should not be possible for it to be making any changes on your website.

First, by default, W3 Total Cache creates a directory wp-content/cache (not in uploads) that stores your static assets and page cache.

Many other caching plugins share this same behavior, including WP Super Cache. It’s possible that if you switched to a different caching plugin, the same directory would be recreated after you delete it.

Are you currently using a different caching plugin, and if so, which one? We can double-check to see if that plugin might be recreating the directory.

Hello @cosuqar-

Thanks for reaching out, that’s definitely odd that the Admin bar is still showing with those settings.

Do you have any additional layers of caching in your hosting environment, such as an NGINX or Varnish proxy cache?

When Don't cache pages for logged in users is checked, the pages should be served with no-cache headers, which should be respected by any other caching layer. Can you verify that the following header is present when you view a page while logged-in?
cache-control: no-cache

You can check this using your browser’s developer console, in the Network tab.

If you can recreate the error, can you also check the W3 Total Cache comment near the bottom of your page source to verify that is says “User is logged in?” and double-check the headers on that request as well?

Hello @redelephantmarketing

Thanks for the question! You can find the widget’s background color in the Customize > Widgets > [Widget Area] section. You can also get to the same menu in the Footer Layout section by clicking the Edit Sidebar button within the widget area itself.

Check out these detailed instructions with screenshots.

Hello @goodvibesonlyb

Thanks for your patience, DreamHost has added our API addresses to their permanent “Allow List,” so this issue shouldn’t happen again. Please let us know if you have any more questions, we’re happy to help!

Hi Benjamin-

It’s been a couple of weeks since we’ve heard back, so I’m marking the issue as “resolved,” but please let us know if you’re still having trouble, we’re happy to help.

Hello @georgehm3

Thanks for reaching out, I’m sorry to hear about the trouble using Gravity Forms together with Crio.

This is a tough one to troubleshoot, because Gravity Forms is a commercial plugin without a free version we can download and test with. We are currently working on improving Crio’s performance with several other forms plugins that should help with this issue as well.

The biggest difference between the Name field and the others that aren’t behaving is that the Name is technically not a label, but a Legend, while the others are Labels. It’s also worth noting that the placeholder text for each field is identical to the label, missing the extra space in between the label and (required).

I do have a special snippet of JavaScript that you can add to Crio in the Customize > CSS/JS Editor that will remove all of Crio’s formatting classes from your form, but when I tested it on your site, it looks like it’s only half the battle, and you may need additional Custom CSS for your Gravity Form to make it look completely correct.

First, make sure that you have Output Default CSS enabled on your Gravity Forms Settings Page, then add this snippet to your custom JavaScript:
https://gist.github.com/jessecowens/aae7fe248d984fb541ef6bf4af5202aa

This code will remove all of the BoldGrid Theme Framework classes from your Gravity Forms.

Hello @goodvibesonlyb

Thanks for the report! This error is occurring because an internal firewall at DreamHost has blocked one of our API URL’s.

I’ve reported the error to DreamHost and they’re working on resolving it. This error shouldn’t affect any operations on your site, other than making the main dashboard page a little slower than normal when it tries to fetch the latest BoldGrid News articles for the widget on your dashboard.

Hello @hamer145 –

Thanks for reaching out! Please forgive me for the late reply.

The +Add only appears to you when you’re viewing the site logged-in, it will not be visible for your users. I recommend viewing your site in a Private Browsing or Incognito window when you want to see it the way that your visitors will see it.

Hello-

It’s been a few weeks since we heard back, so I’m marking this topic as resolved, but please let us know if you’re still having any trouble, we’re happy to help.

Hello-

It’s been a little over a week since we heard back, so I’m marking this thread as resolved, but please let us know if you’re still having trouble, we’re happy to help.

Hello-

It’s been a little over a week since we heard back from you, so I’m marking this thread as resolved, but please let us know if you’re still having trouble, we’re happy to help.

Hi Benjamin-

Thanks for your patience over the weekend. I was able to consult with our developers.

We couldn’t think of anything in the plugin itself that could cause a database connection error, and this is the first time we’ve heard of this problem.

You mentioned that the site does load after a few refreshes, so the connection issue is “intermittent.” If I’m right about that, it means we can rule out problems in your wp-config for sure, and we also know that it doesn’t happen every time that Total Upkeep is enabled.

One possibility is that your server might limit the number of active connections to the database, and Total Upkeep is the “straw that broke the camel’s back,” the last push over the edge for your site’s limit.

One way we could test that is to disable all of the other plugins in the site temporarily, and leave only Total Upkeep active. If that loads reliably, re-enable them one-by-one and see if problem re-occurs.

To get more information, I’d recommend contacting your host and ask them for the MySQL Errors pertaining to your site. If you have an approximate time that one of the errors happened, that will help them to locate any issues. Those error logs could also help us narrow down the cause of the problem.

Hi Benjamin-

On a shared server, you’re probably right that you don’t have much control over the MySQL server like that.

I’d like to speak with the developers when they get back on Monday to see if we can identify anything else we can troubleshoot. I’ll reply back here as soon as I have some more information.

• This reply was modified 3 years, 8 months ago by Jesse Owens. Reason: Spell name correctly