iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 It appears not to like the data that it is receiving. Do you agree. If yes, do you have any ideas. If not, I have no idea. Roddy Quote Link to post Share on other sites
Funce 42 Posted January 6, 2020 Report Share Posted January 6, 2020 Because you're parsing the JSON data from the server, if JSON.parse is failing it means that the PHP file may be incorrectly outputting the JSON. This may come about as a PHP error(ending execution before output) or maybe its just malformed. Check your Network tab of your webconsole, and see if you can find the call to the Captcha file. You'll be able to see what the server responded with. Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 Before I do anything more I have a question. Is it not likely that PHP had upgraded its json_encode() function, and that the JSON.parse function is no longer necessary as PHP has already performed the same action? Roddy Quote Link to post Share on other sites
Funce 42 Posted January 6, 2020 Report Share Posted January 6, 2020 Regardless of what PHP does, all the JavaScript receives is a string(in this case) so processing still happens. But... I just had a thought. the jQuery ajax success method takes an "intelligent guess" on what data is being received and parses accordingly. (I just looked it up because I wasn't sure) It could be that you're attempting to JSON.parse a JSON object.... Try taking it out and seeing what happens. Or you can console.log it and see if its an object or a string to be parsed. Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 Before I try that I would like to bring your attention to a very important point: your prior instruction was quite good. It alerted me to the fact that I had failed to remove a var_dump of what was being received by the reset_captcha.php file. Your not gonna like what follows though. The reset_captcha.php file is once again reporting a 500 error. I am absolutely amazed, but somehow feel that we are coming closer. Please do not leave. Roddy Quote Link to post Share on other sites
Funce 42 Posted January 6, 2020 Report Share Posted January 6, 2020 15 minutes ago, iwato said: Before I try that I would like to bring your attention to a very important point: your prior instruction was quite good. It alerted me to the fact that I had failed to remove a var_dump of what was being received by the reset_captcha.php file. Your not gonna like what follows though. The reset_captcha.php file is once again reporting a 500 error. I am absolutely amazed, but somehow feel that we are coming closer. Please do not leave. Roddy I can stick around for a while Roddy. Just grabbed lunch(Oh New Zealand time) so I'm quite clear for the next few hours. 1 Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 (edited) OK. I have found a real error. Not only does it appear that I have not been keeping current, (If only you knew how difficult it hsa been.) but also the originator of the software that I am using. I now have what I believe to be a bug. Any ideas on how to fix it. [05-Jan-2020 23:08:20 UTC] PHP Parse error: syntax error, unexpected 'const' (T_CONST), expecting variable (T_VARIABLE) in /home/.../vendor/villfa/invert-color/src/Color.php on line 16 Here is the relevant link: https://github.com/villfa/php-invert-color In my code the error occurs here: $color_pair = select_color_pair(true); $ictext_color = $color_pair['text_color']; Edited January 6, 2020 by iwato Add my code and point out where the failure in the developers code becomes an error for me. Quote Link to post Share on other sites
Ingolme 1,034 Posted January 6, 2020 Report Share Posted January 6, 2020 Your server has to be running PHP 7.1 or higher to allow the public modifier on the const keyword. Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 Even more precisely: https://github.com/villfa/php-invert-color/blob/master/src/Color.php Roddy Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 (edited) The furtive fox has returned. Please note, Ingolme, the following from cPanel. dev...rs.grammarcaptive.com PHP 7.2 (ea-php72) Edited January 6, 2020 by iwato Quote Link to post Share on other sites
Ingolme 1,034 Posted January 6, 2020 Report Share Posted January 6, 2020 The error message you are getting indicates that the PHP version is most likely the issue. Make an empty PHP file and run the phpversion() function to verify that the version is what you need it to be. 1 Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 The phpversion() function is not available to me, but the phpinfo() function is. It yielded PHP Version 7.0.33 when I ran it. I am beginning to feel the need to dump cPanel. This is the second major problem that I have had with it, and CENTOS WHM appears to handle everything that cPanel does and more without all of the frustration. CPanel was useful while I was on a shared server, but I now have my own. I will return later with the outcome. Roddy Quote Link to post Share on other sites
iwato 19 Posted January 6, 2020 Author Report Share Posted January 6, 2020 Thank you, Funci, for your very hard effort. Together we nailed the source of the problem. And, thank you, Ingolme, for providing the solution. Once again, I wish Ingolme, Funci, Dsonesuk, and everyone else at W3Schools a very Happy New Year! Roddy 1 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.