Kilgore

I’m having the same problem on WP-Engine with WP v5.6.1.

WPE support sez they can exclude specific pages from their caching but I’d have to send them a regex dump of the specific pages to exclude (and I assume I’d have to resend that to them if I change the page code even a little).

They also said that their Legacy Staging sites do not implement their caching. I’m gonna try that for development but still ‘no good solution for their production sites. BTW, this does not appear to be a problem with the plugin – it was happening for me before (only on WP-Engine), and I was hoping this plugin would fix it…

Any help is welcome, and I’ll post a solution here if/when I find it.

Cheers

So far the client has requested 3 of the ~240 pages to not be Pardot-tracked. I expect there may be a few more, but I mainly needed to exclude a few and include the rest.

Since were only using the plugin to add the page tracking code, I ended up just removing the plugin and selectively enqueuing a .js containing the tracking code via the child-theme’s functions.php and that appears to be working fine.

I’ll keep the plugin in-mind if we get deeper into Pardot integration now that I know it’s clearly and ongoing effort — and thank you for your quick and thoughtful reply!

• This reply was modified 7 years, 3 months ago by Kilgore. Reason: Forgot to mark it as "resolved" ;o)

Yes, this is a problem for me as well.

Please advise.

Yes, the steps in my #2 — that’s exactly how I recovered from situation #1 — completely removed not only the plugin directory, but also the /wp-content/advanced-cache.php file (and probably any other files that the plugin puts in your /wp-content/ directory depending on your w3tc settings, like db.php).

Also note that after getting that all straightened out for v4.7, I was able to upgrade to today’s v4.7.1 by simply copying the new version files to the webroot and wp-admin and wp-includes directories as-ususal, without having to mess with the w3-total-cache plugin files (but beware, I don’t know if that is true when upgrading from 4.6.1 directly to v4.7.1 or not).

‘hope this info helps!

AFter a bunch of trial-and-error (in a staging environment), I’ve concluded that:

1) Trying to upgrade to 4.7 with W3 Total Cache installed does not work, and renders both the front-end and wp-admin inaccessible. And it’s not enough to disable it first or even delete the plugin folder alone.

2) BEFORE upgrading to v4.7: Deactivate and remove the w3-total-cache plugin directory AND it’s /wp-content/advanced-cache.php file. After that I was able to put the w3-total-cache plugin back in-place and re-activate it, and it appears to work with WP v4.7 with no problems.

‘Hope this helps.

Regarding your questions about validation, I’d recommend/expect at least the same basic level of server-side validation that is (or should be) typical on non-WP PHP forms. My projects are increasingly subject to 3rd-party security assessment and penetration scans prior to deployment, which is why I may be a bit hypersensitive on this issue– seeing my javascript make it from the form into a SF campaign (although granted, it appears to be entity-escaped thus not excutable) was a bit of a shocker when coming from a Contact Us form, where there should be no reason to retain <script> tags (even this coder-oriented forum requires special handling to retain escaped code snippets in posts).
Anyway, basics would include:
– min/max character length allowed in textfield entries
– numeric-only, min/max value, auto-strip commas/dollar signs
– currency/decimal-place enforcement
– a North American phone number format (XXX) XXX-XXXX would at least cover the largest % of uses

The ability to use custom regular expressions for validation would go a long way for serious coders (although not very comprehensible for typical WP users).

Regarding methods of implementing server-side form field validation in WP — without having peeked ‘under the skirt to see how the current plugin actually works, I’d probably do the initial POST back to my script where all necessary validation can be performed, and re-display the form with error messages and sanitized field contents on-error. If the POST passes validation I’d RESTfully POST the validated content to SalesForce using cURL, HTTP_Request2/GetURL2 (the guts of which I’ve found can be fairly easily integrated into projects used without having to be installed as PEAR extensions in the hosting environment).
Or, server-side validation can be performed quite elegantly without a POST/page refresh via AJAX (jQuery’s AJAX methods make that a lot less of a challenge than it used to be).
Client-side validation is less-risky if WP’s nonce feature is implemented to prevent forged POSTs that would otherwise bypass any client-side validation, but I’d still consider client-side validation as pre-validation to reduce network traffic/server-load — not as a replacement for server-side validation.
Anyway, Nick, thanks for providing me with this soapbox (‘probably sounds like I’m on step 14 of a 12-step program ;o)

Thank you Nick, your response certainly sheds some light on the situation. With such a huge and growing market of businesses using WP and SF, I’d clearly assumed that this plugin was core to SF’s strategy, and thus my ‘ire. As a contract developer myself, I appreciate (and empathize) with your situation, and applaude you for continuing to assist users a’gratis. Based on other user’s comments, you are going way ‘above and beyond to assist.
I will certainly communicate directly with SF on their apparent and baffling disinterest in hopes that they might stop counting their money long enough to give you the resources and attention you need and deserve.
Although I stand by my statements regarding the serious deficiencies in validation, I apologize that they were not directed to party who should care the most about providing their client-base with secure and best-of-breed add-ons to their pricey offerings. Cheers.

Also looking for answers to this question. Thx!

I concur — PII encryption is fast becoming a requirement, both within enterprises and by-law/regulation, and it would be best to provide such functionality within the core codebase rather than via a plugin.

Thanks carpe, ‘glad this was helpful.

Actually, BlueHost is your hosting provider. The “app server” is the Linux or Windows machine on which your website resides. Similar to the term “web server”, but “app server” usually means a web server with the ability to support real web applications like WordPress/Drupal/Jooma, rather than just serving up static web pages.

Sometimes being behind the times is not a bad thing — always upgrading to the latest release of anything without careful testing can be a real disaster, especially in an environment with so many “moving parts” as WordPress. PHP 5.2 is a nice stable release, so I’d be fine with that (hopefully your hosting provider will give ample warning before doing any major version upgrades).

Good luck, and always keep asking questions — it won’t be long before you’ll be providing answers ;0)

The problem I mentioned is with the plugin on PHP v5.4 and above, not a specific WordPress version (although we were using it on WP v3.3.3, so I can’t say from experience that it’s problem-free on WP v3.4 with < PHP v5.4, but I would not expect to see any problems).

If your app server is running PHP v5.4 or higher, then definitely wait for the fix. If you are running < PHP v5.4, I know of no reason to wait.

How to find your PHP version? Write a one-line php file, info.php:
`<?php phpinfo();?>
put it on your website and hit it with your browser, and it will display just about everything about your PHP install, including the version. Just be sure to promptly delete the file when you are done so nobody else can see your ‘digital underwear’ ;o)