Archived from the Transloadit support forum. Originally posted on July 10, 2012; details may be outdated, see our docs for current behavior. Original thread
I’ve recently had plesk upgrade our server to latest php etc and now when I use transloadit the notification is failing at our server end of things (Assembly REDACTED)
If I use json_last_error() I get 4 = syntax error. Just wondering if this is something you have come across recently - couldnt’ see anything on your knowledgebase but I’ve come across some discussions elsewhere about new json_decode issues with PHP
This is my PHP code:
if (!empty($_POST[‘transloadit’]))
{
//----- GET THE TRANSLOADIT DATA -----
$json = $_POST['transloadit'];
if (ini_get(‘magic_quotes_gpc’) === ‘1’)
{
$json = stripslashes($json); //Also fails with this commented out
}
echo "json_last_error is: ".json_last_error()."\n"; //Gives '0'
echo "Doing json_decode";
$json = json_decode($json, true);
echo "json_last_error is: ".json_last_error()."\n"; //Gives '4'
No worries if not, just asking in case you’ve already had to deal with this
It turns out the json issue has come about because of a change to my template.
This is the php code I’m now using:
//----- CHECK TRANSLOADIT CALLED US ----- if (!empty($_POST[‘transloadit’]))
{
//----- GET THE TRANSLOADIT DATA -----
$json = $_POST['transloadit'];
if (ini_get(‘magic_quotes_gpc’) === ‘1’)
{
$json = stripslashes($json);
}
echo "json_last_error before start is: ".json_last_error()."\n"; //Output for debugging info when viewing an assembley in transloadit
echo "Doing json_decode now\n";
$json = json_decode($json, true);
echo "json_last_error is now: ".json_last_error()."\n"; //Output for debugging info when viewing an assembley in transloadit
echo "json size is is: ".count($json)."\n"; //Output for debugging info when viewing an assembley in transloadit
…
The assembly 937a42bb398c9c5 is using my original template, and it works fine with this php code. I’ve just changed back to it, uploaded a video and in the assembly notification you can see json_last_error is now: 0, so all good.
However assembly d985bdb0649764b is using the new template which is an update to the old with video resolution detection in it. This causes json_last_error is now: 4
after the line $json = json_decode($json, true);
Our server is running PHP5.3.2 . If I give http://jsonformatter.curiousconcept.com/ the url of the json I get from your assembly page link it says it is valid, however php5.3.2 is deciding it isn’t. for some reason I appreciate this may not be an issue at all with your end as it may be PHP, but if you have any ideas please let me know
Doesn’t the
echo $json; show that transloadit isn’t passing the json data it says it has? The echo is prior to the json_decode so doesn’t this indicate the cause of the issue?
Hi Tim
Thanks for your help this morning. The more I look at this the more convinced I am that the issue is to do with php5.3.x and the “<” character being sent in the POST. I can’t find a specific topic on this exact issue online but I’ve found many talking about changes in php5.3.x breaking previously working json. My suspicion is maybe this character isn’t being encoded before being sent or its something else that is only shown when sending to a current php version server. Woudl you be able to update your server to the current release to test this and turn off magic_quotes_gpc seeing as it is about to be removed anyway (I’ve put mine back to it being off as there is no point leaving it on going forward)?
OK many thanks for trying it. Very confusing if you also had magic quotes turned off. There doesn’t appear to be any solution for me other than accessing the json file via S3 then. Over the weekend I verified that there is nothing I can do in PHP as the $_POST is only passed up to the ‘<’ character so the issue must be occurring prior to the stage of the pages php file getting it. I’m assuming there is no alternate to the < and > characters in the transloadit templates (there isn’t a word based equivalent?)
Hi
Only the tinybutstrong template engine, but that isn’t really a php extension. I’ve been trying to see if it could be the cause but I’ve not managed to find anything so far…