Plugin development has been stalled for quite a bit now (6 months+) due to a situation outside my control that has only recently (literally yesterday) been resolved.
“SF’s answers I see in the support forum”
I’m not a SalesForce employee, I’m a freelance developer helping users for free*. SF does not read these reviews or support threads. You’re welcome to submit your feedback to them directly.
I’ve tried to help as much I can in the forums, hence the recommendation of 3rd party solutions like jQuery validate.
The sanitization issue is a serious one, but this is the first report of it. I’ll put that at the top of my list.
If you want to fund the development of certain features you need/want to speed their inclusion, I’m happy to discuss options with you.
Pull requests are always welcome as well:
https://github.com/nciske/salesforce-wordpress-to-lead
* SalesForce funded the v2.0 upgrade, but is not longer funding development or support.
And javascript tags and other code can be happily sumbmitted and appear in the SF campaign entries.
HTML tags are stripped out as are script tags (the code remains but is not executed). What are you seeing and what were you expecting?
Why can’t you include simple server-side field validation in this plugin (and maybe a decent phone number field)? ‘Not rocket-science.
Can you elaborate on what you think “simple server-side field validation” would encompass? Required fields and an email field are included — what’s missing?
What would a “decent phone number field” look like, keeping in mind that this plugin is used worldwide so it’d have to handle numerous phone formats including extensions (or only support validation for some phone numbers).
Have you had users enter invalid phone numbers? Would a hook for you to add your own validation to each field suffice?
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.
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)
FYI- v2.2 which was just released has a filter allowing you to add your own validation logic to each field, as well as customize the error message output.
It’s not a silver bullet but does allow you to tweak things to your needs beyond what was previously possible.
