Forum Replies Created
- AuthorPosts
- Marko VasiljevicKeymaster
Hello Nicola,
Thank you for your patience.
As it appears you are correct. The delete_option is not running due to the $extras parameter being empty.
I’ve opened a GitHub issue on your behalf in our Github repository. Please make sure to check the progress of the issue regularly and add more information if needed.
Thank you!Marko VasiljevicKeymasterHello Nicola,
Thank you for providing the info and detailed explanation.
Let me test this and get back to you to see if I can replicate this and if the provided code works without any issues.
Once again thank you for provided details and your patience.Marko VasiljevicKeymasterHello Franko,
Thank you for your inquiry and I am happy to answer.
The Pro license unlocks the additional W3 Total Cache features like Eliminate render-blocking CSS by moving it to HTML body, REST API Caching, FSD CDN, etc. The Plugin Configuration solution or Performance Audit does not include the Pro license, so the Pro license needs to be acquired separately.
To check the prices, please go to Performance>Support in your wp-admin dashboard (check the screenshot below)
Thank you!Marko VasiljevicKeymasterHello Nicola,
I am sorry about the issue you are experiencing with clearing the w3tc_minify option from the database.
I need to check this and try to replicate and I’ll get back to you as soon as investigate this more.
Thank you for your patience.Marko VasiljevicKeymasterHello Nicola,
Thank you for your inquiry and I am happy to assist you with this.
Browsers that support brotli send br along with gzip in the accept-encoding request header. If brotli is enabled on your web server, you will get a response in brotli compressed format.
This means to me that if the client supports both, brotli is preferred over gzip.
At the moment I can see that all minified files are “brotlied”
If convenient, can you please share the exact changes you made inMinify_Environment.php
and also, are both brotli and gzip enabled in Performance>Browser Cache>CSS&JS and if so, you should disable gzip if you are using brotli for those files.
Thank you!January 19, 2021 at 11:46 am in reply to: [Resolved] JS error Cannot read property ‘concat’ making crashing my Divi blog #33072Marko VasiljevicKeymasterHello Dominique
Thank you for the information.
It seems that jquery-migrate is necessary and custom.unified.js?ver=4.8.1:51 is dependable on it so you should keep that option disabled.
I am glad to know the issue is resolved!
Thanks!January 19, 2021 at 8:54 am in reply to: [Resolved] JS error Cannot read property ‘concat’ making crashing my Divi blog #33060Marko VasiljevicKeymasterHello Dominique,
As Jesse stated we are unable to replicate the issue on WP 5.6 Divi 4.8.1 and W3TC 2.0.1.
Can you please disable the settings one by one in Performance>General Settings, save all settings and purge the cache after each setting is disabled, and see which one might be causing the issue.
Please let us know the results so we can assist you more with this.
Thanks!Marko VasiljevicKeymasterHello Chris,
Thank you for the information provided.
As I’ve already answered you in wp.org and this a duplicate post please make sure to check the wp.org topic:
https://wordpress.org/support/topic/prevent-caching-with-gravityforms/#post-13868293For your convenience this was my reply:
You should use the correct groups and each group should specify
{key}={value}
Depending on what key you are using, that should look like{key}='{“strict”:”1″,”thirdparty”:”0″,”advanced”:”0″}’
So you should replace {key} with the actual cookie name.And don’t forget to enable all the checkboxes (enable and cache)
Once again as the cookies are cached and may change depending on a value, you should exclude those pages from being cached to avoid this.
This is simply how cache works. I hope this helps!
Thanks!Marko VasiljevicKeymasterHello Gregorio,
Thank you for your inquiry.
There is no known incompatibility with JWT authentication and since the Page Cache should always be disabled for logged in users REST API caching will not be performed in this case.
The_embed
parameter indicates to the server that the response should include these embedded resources.
So for example, /wp/v2/posts?_embed=author,wp:term will only embed the post’s author and the lists of terms associated with the post and it will be cached if REST API cache is enabled.
For more details on what is actually cached, you can use Statistic in Performance>Statistic and Under the PHP requests section, you should see the Cache Fill option which you can then open to see /wp-json.
Thanks!Marko VasiljevicKeymasterHello Svyatoslav,
Thank you for your inquiry about the caching statistics feature.
The improved Statistics page allows you to check the Hit rates and overall effectiveness of every configuration enabled in your General settings.
You can use Statistics to check the following:- Page Cache (Disk, Disk-Enhanced, Redis, Memcached)
- Minify
- Object Caching
- Database Caching
- Fragment Cache
- System info (PHP Memory, CPU Info)
- Cache storage size used (Redis, Memcached)
Enabling the Debug mode for each setting in Performance > General Settings > Debug gives you more detailed information by clicking on a link of the desired setting in the Statistics Page.
If for example, Object Cache is disabled, it won’t be available in Statistics
In Performance > General Settings > Statistics, you can enable Statistics and customize your desired settings.
Please check this screenshot
You can check more detailed information in our documentation.
Thanks!Marko VasiljevicKeymasterHello Steven,
As per our conversation in the support channel, W3 Total Cache does not support push-type FSD so in this case, we cannot help with this. You should reach out to AWS directly for assistance for your use-case.
Thanks!
September 2, 2020 at 12:55 pm in reply to: Does W3 Total Cache work with a “Force Login” Plugin #26377Marko VasiljevicKeymasterHello Michael,
Thank you for the clarification.
In this case, you can use W3 Total Cache for caching. However, once the user is logged in if the option in W3 Total Cache “Don’t cache pages for logged in users” is enabled, then the user will not receive cached pages. In case you want a logged in users to see cached pages, you should disable that option.
Again it’s not recommended to serve cached pages to logged-in users.
If you by any chance run into any kind of issue, please make sure to drop us a note so we can assist you with this.
Thanks!
September 2, 2020 at 10:09 am in reply to: Does W3 Total Cache work with a “Force Login” Plugin #26358Marko VasiljevicKeymasterHello Michael,
I’ve checked the Force Login plugin and it appears that it may be adding no-cache headers to prevent caching.
It is not advisable to cache pages to logged-in users. The reason for this is because some secure content may be displayed to the other users that should not have access to this.
Also, please share some more information on what you want to achieve, what do you expect to be cached, and do you want pages also cached for logged in users?
Thanks!
- AuthorPosts