Closed universalhandle closed 8 years ago
The JSON encoding that happens before the request is made to SparkPost uses a PHP constant JSON_UNESCAPED_SLASHES
that was not introduced until PHP 5.4, resulting in
json_encode() expects parameter 2 to be long, string given
errors if run in an earlier version.
The extension documentation indicates that PHP 5.4 or greater is required, for which the web server was configured. The code in question runs in the context of a cron job, which isn't using the web server's PHP configuration but the shell's. In this environment, the shell was defaulting to PHP 5.3.
I'm still having issues with sends of more than 100 recipients, but I'm suspecting (different) environment issues at this time. I'm closing this issue accordingly.
Thank you, GinkgoFJG, as I just discovered this problem on my own installation.
My original cron job was:
/usr/local/bin/php /home/sitename/public_html/administrator/components/com_civicrm/civicrm/bin/cli.php -s sitename -u user -p password -e Job -a execute
I changed it to:
/usr/local/php56/bin/php-cli /home/sitename/public_html/administrator/components/com_civicrm/civicrm/bin/cli.php -s sitename -u user -p password -e Job -a execute
The original code defaulted to PHP 5.3, as you said before.
My website is hosted in SiteGround.
The log contains this:
The problem presented during a 30K send. I was unable to reproduce it in a sandbox using the same message and a much smaller list of recipients. Code 1300 is described as "invalid data format/type/length."
Current theory is that the request fails because the payload is too big. Or it could be that the content gets truncated because of its length, resulting in invalid JSON.
SparkPost recommends transmissions with 10K or fewer recipients. (I didn't get a rationale for why.) SparkPost also pointed me to a thread in which another developer encountered a problem because "transmission-level substitution data must be less than 100,000 bytes," or 100 kilobytes. We're not using substitution data, but we might want a sanity check on the size of the request before we make it.
I'll do a little more digging and see if I can validate/invalidate the working hypothesis.
I can't assign issues in this project, but you're welcome to assign this to me... unless you've seen something like this before, in which case I'd be happy to pair up.