Jessie
Forum Replies Created
-
The issue isn’t the number of emails, it’s that the SMTP service I am using takes a few seconds to send an email, so when a user submits a contact form, they get antsy after a couple seconds and click “Send” again, or complain that it’s not working. I don’t want to change SMTP services because that would require me to log into 40+ websites and reconfigure each one with a new SMTP server hostname.
What I want is for Post SMTP to either natively queue emails or give developers the hooks needed to implement them themselves (well, just one hook really).
Personally I think the hook is a good idea regardless. Developers could use that to do any number of things, for instance spam filtering. I could submit a pull-request if you would like to add this hook to PostmanWpMailBinder.
I think the best way to handle code/issue discussion is via github. This is (I assume) the authors github project for this plugin: https://github.com/kodie/gravityforms-repeater
I forked it, but have not committed my changes since the master branch is ahead of the plugin release: https://github.com/jproffitt3ge/gravityforms-repeater/tree/enhancement-save-child-values
What I could do is rebase my branch off of the last release (1.0.9), then we could ignore the rest of the changes made after that. I can do that this weekend, and then you could post an issue there.
I also forgot that the base Gravity Forms plugin is public: https://github.com/wp-premium/gravityforms
So you can also probably cite the problematic code here, assuming it’s not making use of an add-on.
Ah, I am working with an older version of Gravity Forms, 1.9.17.5, so I cannot see what code is generating that notice.
I don’t imagine you are allowed to post the relevant snippet of the code raising the notice, so what I would suggest for finding its source is inserting a type check on the line before it for the variables that may be arrays. If one of them is an array, print it to log along with a backtrace. Like so:
if (is_array($myVar)) { error_log(print_r($myVar, 1)); error_log(print_r(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), 1)); }That’ll output extra information to either your-site/error_log or your-site/wp-admin/error_log (unless your server is configured to put them somewhere else).
I’m concerned about that notice because it usually means something is being passed in wrong and lost.
Sorry for the delay. I tried forking the git project, but the master branch was too out of sync with the distributed plugin for me to merge in my changes right now, so here is a straight zip of my modified version: https://www.dropbox.com/s/la5b001ao1rcpz1/repeater-add-on-for-gravity-forms.zip?dl=1
The only files I modified were class-gf-field-repeater.php and js/repeater.js / js/repeater.min.js, so you can inspect/copy just those files if you’re (rightfully) concerned about security. The gist of it is I modified the repeater field to store all the child values in its hidden field where it stores the number of children submitted. Then I modified the javascript to recognize this extra data and pull from the hidden field instead of the cookie or wherever it was getting the values from now.
Concerns:
– There is a lot of input name transformation going on back and forth between the php side and the html/javascript side. Theres a lot of room for error, particularly with compound fields like the address fields (I tested that successfully in this case).
– Tried to force it to handle child input through their actual respective fields, rather than grabbing / saving the posted data directly. Not sure if this is more or less reliable.It is possible to fix this. I overrode get_input_value_submission in GF_Field_Repeater and saved submitted child values in with the configuration information, then read the initial input values from there in repeater.js.
I can provide a zip or gist if anyone desires.
I investigated this and found that the repeater stores and loads its values from a cookie using this library: https://github.com/ssut/jQuery-PostCapture
There is no mechanism for saving the child field values on the server side so they get lost as soon as the cookie is reset.
To fix this, someone would need to rewrite the repeater field to get/ save the child field values along with its own configuration data. Then it could be persisted with the other fields, and the javascript could load the values from the repeater element itself.