hotzeplotz

having the same issue (Firefox 44, Debian), also on Chromium (49, Debian) – in my case this seems due to the Do Not Track flag being turned on. if i turn DNT off, the form works fine.

the issue here (apologies if i am hijacking the thread with something that ends up being unrelated – i hope i am not) is not only that the recaptcha is not loaded, but that the error message that appears (There was an error trying to send your message. Please try again later. – orange border) is confusing, since the visitor never gets to see the recaptcha at all.

I am guessing that the recaptcha does not appear because Google operates some kind of tracking when processing recaptchas (https://www.businessinsider.com.au/google-no-captcha-adtruth-privacy-research-2015-2), and it therefore (rightfully) refuses to run the recaptcha JS code when DNT is on.

i am not sure what a sensible behaviour for CF7 would be when this happens – i don’t think falling back to no recaptcha would be sensible, but perhaps the error message could be made more clear, if the scenario can be detected via JS.

Is there a way to choose which of the ACT fields enabled as Admin Table Columns is used for the default sorting in the admin UI, and whether to sort ASC or DESC? by default, Name is used for sorting.

the closest thing i see is picking a different field as ‘Title Field’ under ‘Advanced Options’, but i’m not sure if this has other implications, and i think the default is to sort ASCending and there is no way to make DESCending the default.

i could use pods_ui_manage() for this, but i wonder if i’m missing something obvious for this in the admin interface.

just adding to the above – if i untick the box ‘Cache front page’ from W3TC’s Page Cache settings page, the front page is not cached, as expected, which kinda works around the issue but i still can’t figure out from docs whether w3tc_pgcache_flush_url() is supposed to be working with URIs which are not generated from WordPress Posts or Pages, and what is the $url parameter format supposed to be.

in my case, it seems that the major issue on this upgrade was lack of clarity on the admin interface changes: i only realised after a good deal of tests that W3TC now defaults to applying the same settings across a whole WordPress network, so it is “normal” that most of the W3TC admin pages don’t appear in the control panel of individual sites: once this default is overridden in the W3TC configuration at network level, any enabled admin pages will be available on each site.

i guess that the message appearing on each site’s W3TC Dashboard page (“The plugin is currently enabled in community mode.”) doesn’t really mean much (what is ‘community mode’? a link to an explanation would be helpful), whereas a message on this page informing admins that W3TC configuration is being applied from network-wide settings would clearly help, especially as this behaviour seems to be a radical departure from older versions of W3TC (once i realised how this works, this is great, but i wasted a couple of days just trying to figure out what was wrong with this plugin’s upgrade).

changed my vote for 0.9.2.8 on 3.5.1 to say ‘works’ – but clearer notes on upgrade and on each site’s W3TC dashboard would really help.

same here (permissions error for URI /wp-admin/admin.php?page=w3tc_general) after upgrade to 0.9.2.8 on a network.

w3tc was activated only on a site within the network, and after the upgrade i do not see it anymore in the site’s admin interface: i can only enable or disable it for the whole network, and yet when i do this, only a subset of the admin pages for the plugin appear in the admin navmenu: Dashboard, FAQ, Support, About. if i enter <base_URI>/wp-admin/admin.php?page=w3tc_general manually i get the above mentioned permissions error – yet i’m logged in as administrator.

tried deleting the configuration file for this site, but this didn’t solve the issue. i get the w3tc comment at the bottom of each page’s source, but e.g. CDN serving which was enabled before the upgrade is not active (media library items URIs are not rewritten to go through the CDN servers).

@shackep it was quite some time ago so i don’t remember how i got to the patch i created, but you can see the diff here – i’m not sure it’s kosher but it’s been working fine until now:

https://github.com/hotzeplotz/usernoise-lsecities/commit/38a14cbfe2cb4f93052c4da7408d5bd366bed58e