Lyk

Thank you for the verification.

Will do, thank you!

Thank you for the info!

Thank you for the link.

When the WPFC_CACHE_QUERYSTRING is enabled, how exactly does it work?
e.g. example.com/?param=low and example.com/?param=high will create 2 different cached pages that will be served accordingly?

Assuming a blog with many pages or an eshop with a few thousands of products, I guess it is not reasonable to prime/preload the cache every 10h.

You are absolutely right.

So I guess the best way to proceed in such cases is either create the cache when needed and have it expire regularly (10hours) or verify that there are no nonces in features of the pages you try to cache and cache them without worrying about nonces (did a quick check and it seems that some of the basic form plugins do not use nonces by default)

Are they safe to (page) cache, assuming that after we make changes to a form, we always clear all caches?

Do they use any nonces or anything that needs them to always be on dynamically generated pages?

Thank you!

• This reply was modified 3 weeks, 6 days ago by Lyk. Reason: typo

Hello Daan,

Sorry for the super late verification, thought I had replied in the thread.
That seems correct and the gcs changes as needed. The only thing a bit weird is that I couldn’t find any official google documentation on these parameters, only unofficial references from articles/blogs.

If you have any official sources feel free to share them, I believe others would be interested too.
Other than that, thank you very much for you help! (maybe add a reference to your FAQ regading gcs and gcd parameters)

Cheers!

Ok, thanks for letting me know!

Hello!

Ok, I just sent you an email via the form. Will update this thread when we reach some conclusion.

Thank you!

Hello Daan,

I have noticed that you always answer promptly and guessed you would have probably been extra busy. Sorry to hear that, hope everything/everyone is well now!

With the method you suggested, I can see some requests to google-analytics.com/g/collect? but cannot differentiate pingless from consented requests. Also (I think) there is no way to tell whether the different consent parameters are passed correctly, e.g. analytics: granted, etc.

Thank you!

I see, that seems proper.

The function w3tc_pgcache_flush_post is valid and provided from the plugin, correct?

Ok, thank you for letting us know!

Is the mentioned solution the only one?
Or someone can also just use something like w3tc_pgcache_flush_post($post_id); in order to flush only the one product with the change?

Moreover, do we have any rough timeline on these releases? (Since the issue seems to be active for more than 1 year)

Thank you!

@arndtk Try excluding the WP Armour .js (/wp-content/plugins/honeypot/includes/js/wpa.js) from the delayed execution.

True, there is nothing wrong with that.

But since there is an ongoing debate on jQuery and way to avoid it when not necessary, maybe it would be a nice upgrade for WP Armour to use vanilla JS.

Cheers and thank you for the good work!

Hello,

we faced the exact same issue with one site. Cleared the cache of W3Total Cache and even disabled the plugin but the problem remained.

With a quick look, it seems that the hidden field (.wpa_hidden_field class) is not in the form at all. (!)

EDIT: upon further investigation, we found the issue. It seems that removing jQuery was causing the issue. WPArmour relies on jQuery in order to add the extra field.

By the way, maybe this is a good excuse to avoid using jQuery in the WPArmour JS?
Seem to be just a few lines of code and the result will be more robust and even improve the JS perfomance of the code.

Thank you!

• This reply was modified 7 months, 3 weeks ago by Lyk.
• This reply was modified 7 months, 3 weeks ago by Lyk.
• This reply was modified 7 months, 3 weeks ago by Lyk.
• This reply was modified 7 months, 3 weeks ago by Lyk.