Upgrade script from PHP 5.6 to 7.2 appear error for Paypal

Hello

My website is about to people can buy some software from my website. There is one icon on site where user can see "buy now".When user click on that icon then he will be redirected to Paypal,and then make a payment.

Now the problem is when i was switch from PHP 5.6 to PHP 7.2 in Whm that action just give to me blank screen.So that mean that for 7.2 PHP version can't finish payment with Paypal.

Just to mention script work great with other functions as Home and contact page,and is full in function in PHP 7.2 but only payment on icon "Buy now" can't be finished.

How to fix that in some file?

Thanks

 

Anything in PHP's error logs?

 

No error at all. Just Paypal redirecting can't work with PHP 7.2. I must fix some file but i am confused how Paypal redirect from my website not work.

 

No code == this is why we can't help you.

 

Hello deathshadow here is a code https://files.fm/u/695gg3nu at line 66

 

deathshadow do you know how to fix that file? Thanks in advance

 

Unless you tell us the error you are getting, it will not be possible to fix it...
Check for error generated in the log file, or echo it to browser.

I too use paypal, had no problem in the switch from 5 to 7.

I am thinking that either you are using a depricated function before redirecting the user to paypal, or you forgot to upload some file when you switched server...

 

There is so much wrong with that entire codebase, being more PHP 4 than 5 in methodology, I would just toss the entire mess in the trash and start over.

Even the lines before you mentioned is 100% fifteen year out of date INSECURE garbage.

Though your real error should be line 61.

mysql_query($sql) or die(mysql_error());

Code (markup):

PHP 5.6/later would have been throwing warnings about the use of mysql_ functions, as they were deprecated. THEY NO LONGER EVEN EXIST in PHP 7. They are an oudated, outmoded, insecure way of doing things. Right before that:

$sql = "Insert into tblOrders(ProductID, ProductName, ProductPrice, FileName, OTO, CustomerID, Paid, Odate, OTOcode, coupon_code) 
		VALUES ({$info['ProductID']}, '{$info['ProductName']}', {$price}, '{$info['FileName']}', 'N', 0, $paid, $odate, '".$OTOcode."', '".$used_coupon."');";

Code (markup):

Derping variables into the query string is again something that really has zero business even being done in ANY version of PHP 5.x, much less PHP 7. It's called prepare/execute, use it.

NOT that it should ever even have gotten that far since the mysql_connect would have to happen first, and that too throws a big warning in 5.6 and doesn't exist in 7.

See the giant red warning box over the past DECADE about the mysql_ functions in the manual:

https://www.php.net/manual/en/function.mysql-connect.php

That entire codebase is simply too far out of date from an efficiency, standards, or security standpoint to ever be deployed as is. It requires a total and complete rewrite top to bottom to drag it into this decade -- hopefully that will be done before the decade runs out. There is nothing from that code in terms of methodology or functionality I would attempt to retain.

 

Thank you.

 

Thanks for answer.But now i am totally confused,because when i switch to 7.2 then script work as on 5.6 but then only Paypal redirecting not work. Any way if someone know how to fix this,please just leave code here, because if i hire some developer price for this modification will be so high.

 

@lapidus please do not share files like this using file hosting services. Upload here, or copy paste source code.

@deathshadow is right that your new host probably does not supports "MySQL" functions. You will need to change to "mysqli" functions instead.

 

Jeet you mean my host not support Mysqli instead you said Mysql ?

 

Problem solved, .I was just need to change in file from mysql to mysqli Thanks to Qwikad.com and deathshadow and Jeet too. Cheers people.

 

Yip, MySQL functions are gone in php7. Uses mysqli instead. Best practice is to write a mysqli query function of your own, which takes a query, executes it and sends the result to a resulting variable.
Then instead of using php's builtin mysqli functions on all script pages, just use your own function which calls php's builtin function.
Saves a lot of trouble during such upgrades.

 

I would suggest PDO instead, it's less obtuse, more consistent, easier to use, and doesn't go full pakled like mysqli does in allowing for outdated methodologies like the dumbass pointless "functional wrappers".

I also disagree on the "write your own functions" nonsense. Why introduce extra overhead for no good reason? Particularly since if you use the object model of either mysqli or PDO there's zero legitimate functionality that would add.

@lapidus, To clarify though, since the terms are being thrown around willy-nilly.

mysql -- the database engine, though you're probably using MariaDB and don't even know it.

mysql_ -- pay attention to that underscore, it refers to ALL the PHP functions that have the underscore to allow access to mysqli; such as mysql_connect, mysql_query, and so forth. STOP USING THOSE!

mysqli -- another interface to allow mysql access from PHP. I dislike this one because how it handles prepare/execute is a pain in the arse, it has functions to wrap the object model preventing people from modernizing fully and introducing overhead for no good reason, etc, etc.

PDO -- yet ANOTHER interface to allow database access from PHP. Designed for use with almost any SQL engine, it opens the door to more than just mysql for more versatility.

Regardless of if you choose mysqli or PDO, you still should rewrite how all your queries are handled to the prepare/execute model. It's NOT as simple as search/replace to change mysql_ to mysqli_ in your code, a common misconception. Even if you get it to work without significant changes, all you're doing is leaving the security holes in place, and defeating the entire reason the mysql_ functions were ditched in the first place!

Another reason I suggest PDO over mysqli -- it makes you think a bit more about the changes needed and has no real way to even try and search-replace your way out of the problem.

Just thought that needed a bit of explanation just to be sure we're all on the same page.

 

@deathshadow
First of all sending direct user input to database, without verifying it, that is the only way to open vulnerabilities, not the coding language or functions it provides.
As long as you are yourself verifying the data you are sending to database, you can use anything you want.
A query which expects a numeric input, "must" go through a check of at least "is_numeric" first, etc.
This is our responsibility as coders, not of coding language designers.

Secondly, writing your own function is not overload. Its like writing a "class", which can be reused in different projects over and over again.
Think about it like this:
You got a website, loading 20 different kind of pages, each page sending 4-5 query requests.
That is about 100 query function appearances in "one" script you wrote.
Lets say you got 5 websites, 500 query function calls.

Now when your webhost switches PHP version etc, will you keep using search and replace functionality of your php editor to edit all these 5 scripts, with a total of 500 appearances?

Isn't it better to update one class/function file instead?

I wrote a function file for myself many years ago, has a lot of major functions, some minor too, and when PHP decided to remove mysql_query, all I needed to do was change the code of my "myQuery" function, which is in this file.
Then uploaded this new function file to all my projects.
Problem solved!

 

Not when you have fundamental changes, like the transition from full Pakled derping variables into query strings to using PDO with prepare/execute, unless you're wasting a ton of memory making copies of values for nothing and shoving them around on the stack by passing them to your functions and/or methods.

Generally when there are changes that radical, having some sloppy garbage sitting in-between as yet another layer of abstraction atop the existing layer upon layer upon layer is not an improvement. Particularly when a lot of those 'checks' are no longer relevant -- have proper types for your field, trap the error code... or not even get that far and spit the form back at the user LONG before you should even be thinking about database interaction.

These endless garbage wrappers just add more code for nothing, OPEN security holes through letting the developer get lazy, and on the whole are a waste of time, effort, and money.

Particularly now that there's little excuse not to use PDO... another reason I favor it over the mentally enfeebled TRASH that is mysqli... which can't even be bothered to use the same bloody object interface for ->query and ->exec that it does for ->prepare. Screw that.

Though that's where I think most people screw up -- using mysqli when it's just as outmoded and half-assed as mysql_ functions were. OF COURSE you need extra validation garbage given how borderline broken it is, and the agonizing way in which prepare/execute is implemented.

 

Even when switching to PDO from mysqli, it would still be easy to just change one class file, instead of changing 500 instances of mysqli all over the script.
Thats not being lazy, its being efficient.

And frankly speaking, I don't see how PDO increases security.
Both PDO and mysqli "need" the coder to follow best practices, like escaping strings.
A bad coder who ignores that step, PDO cannot hhelp him...
And as long as you are escaping input, you need not worry about security holes.

Can you show me one example where escaping string is not enough?
Just one example where PDO helps and mysqli does not, even after escaping?
All I need is one example.


Right now, the only reason to switch to PDO is the multiple database engines it can connect to, 12 I think as of now.
What good is that ability if CPANEL offers "only" MYSQL engine by default?

Performance of PDO is slower than mysqli. You will notice this with larger tables.
So if you already know that you need drivers to connect to mysql only, it does not makes much sense to choose a slower driver, with same security abilities.

I am not against switching to PDO. You want it, then you should.
I don't see the need right now.

 

Given the fundemental changes in methodology between mysql_ and PDO/mySQLI, that is unlikely to ever be practical and/or possible. As when you say:

I've never seen it done in a manner I would call efficient, at least not from a runtime/speed/code size point of view. That's why I use the word lazy. I've seen FAR too many such wrappers converted from the mysql_ days that are utter and complete incompetent GARBAGE when made to work with mysqli or PDO. They almost made sense in the mysql_ days as ways to fill in gaps in functionality or automate escaping -- but as of PDO I no longer see such gaps existing and with prepare, escaping values should be a thing of the past since you should no longer be just derping variables into your query strings unless it's table names or field names -- two things that should NEVER never come from client side in the first damned place!

It is not so much about increasing security as it is encouraging people to use best practices sooner -- because as object model based ONLY it basically forces people to relearn how to do things. Again I've seen far too many cases of developers being lazy either out of ignorance or willful incompetence where they try to simply replace mysql_ with mysqli_, make just enough modifications to make it run, and in the process completely missing the WHY of how mysql_ functions went the way of the dod.

Again something that if you're using either mysqli or PDO shouldn't ever be a thing you need to do! That's what prepare/bind/execute is for! Let the engine do the work and keep anything that needs to be escaped the blazes out of the query! What you are saying shouldn't even be a thing anymore!

Why the blazes would you even be doing that anymore?

Again it's not so much about specific usage cases, as it is the crutches the dumbass functional version of mysqli hobbling the learning process by allowing people to sleaze by on bad practices. I'm not saying that it can't be as secure, so much as it allows and in some ways encourages people to not bother making essential changes. Technically PDO has the same flaw as you can still ->query with variables in the query string and trying to derp around that with the real_escape_string bullshit, but it is less likely as you have to learn the entirely new object method in the process, encouraging the discovery of things like prepare/execute using a cleaner and simpler model of doing so.

Since mysqli's prepare/execute model is painfully obtuse (particularly the binding of results) guaranteed to send users running and screaming back to mysqli_query and dicking around with manual escaping in a way PDO does not.

The possibility that Oracle might f*** up MySQL on purpose? That you might not always be hosted on the overpriced train wreck of how not to manage websites that is CPANEL? The ability to make systems more likely to be able to be hosted on multiple engines so as to have a larger target audience?

That's where extending the PDO object and using things like "named queries" comes into play. I'd sooner see PDO extended than some pointless separate wrapping object.

Back in your face, do you have an example of this? Since most of the load should be on the engine itself and not the interface, this really sets off my BS alarm unless you're doing something completely flawed... like derping variables into the query string, or failing to leverage POEM, of trying to pull the complete result set instead of working one record at a time, or some other broken methodology/bad practice.

PDO has a cleaner syntax, forces you to relearn how to do things properly without the stupid functional wrappers, is far less obtuse on using prepare/execute, and provides all the functionality you should need meaning there is no legitimate reason to wrap it with anything. It sure as shine-ola doesn't seem any slower unless the way you're doing things is completely wrong and/or outdated/outmoded.

Which is another problem with how mysqli prevents people from having to relearn to do things... JUST like how the wrappers you describe prevents people from having to relearn how to do things when the methodology is radically different from what came before it.

Hence why if I see one more case of people recreating the same query for each iteration of multiple results, or derping variables into their query strings I'm going on a face-punching spree.

... and seriously, bind_result and not returning the same object for ->prepare as it does ->query/exec is a stunning example of why mysqli can go plow itself and why I don't suggest anyone waste time learning it. It's GARBAGE! Probably why people keep throwing pointless "wrapping" objects or functions around it.

-- edit -- also we've had only three interfaces in closing on two decades, with not even six months between PDO vs. mysqli a decade ago. It's not like this is something that changes every year, and when changes come most of the time some silly self-built wrapper isn't going to cut it unless you hold on to those outdated methods and bad practices... which seems to be the ONLY thing these frameworks/wrappers are built for. Same as how on the HTML/CSS side of things halfwitted mentally enfeebled stupidity like bootcrap let's people still pretend it's 1997 slopping presentation into their markup in complete ignorance of two decades of progress.

That's how mind-numbingly dumbass such "wrappers" end up feeling to me. I've cleaned up too many broken bloated websites the past decade that were pissing their own pants with that type of nonsense. I've never seen it done in a manner I would let a client deploy; but I've seen a lot of useless trash where people completely missed the point of mysqli and PDO even whilst attempting to use them.

 

Hello folks is me again

After 2 years i am facing with the same problem about switching to PHP 8.0.

Previous problem was solved to work in 7.2 PHP version, but now i want to switch to 8.0. When i switch to 8.0 from WHM site work normal, but when i press "buy" button and then is not redirect me to Paypal, i only see message about : Fatal error: Uncaught Error: Call to undefined function mysqli_connect() in .... (i did not copy whole error message) So, from previous solved problem to work in PHP 7.2 that is ok, and now i want to switch to PHP 8.0 but got that error.

What i must do again to solve a problem now to work Paypal payment redirection with PHP 8.0 ?

Thanks again in advance about help

Notice: I did not open new thread here at forum, because to we can discuss and to know here about previous problem, which was solved.