Updating Deprecated Functions

Beginners - Learning PHP
#1

My website (built by someone else - I know nothing about php) uses a lot of deprecated functions. My host is upgrading their mysql and it’s going to break my site. I’ve run all the code through a php code checker and know what the errors are, but I can’t figure out how to fix them.

These are all the deprecated functions used throughout my site:

mysql_fetch_object()
mysql_num_rows()
mysql_query()
mysql_result()
session_register()
session_is_registered()
mysql_fetch_array()
mysql_error()
mysql_insert_id()
mysql_connect()
mysql_pconnect()
mysql_real_escape_string()
mysql_select_db()
split()
mysql_data_seek()
mysql_escape_string()
mysql_fetch_assoc()
mysql_free_result()
mysql_close()

other than changing to mysqli - I’ve got no idea what else needs to be fixed. Please help!

#2

If your code is old enough to have session_register/session_is_registered, it is probably also dependent on register_globals. If so, this will require a significant amount of time to go through and find all references to external data and convert them to use the proper super global variables.

For old code, it is NOT worth going to all the effort and just convert it to use the mysqli extension. If you must go though all the database dependent code, you might as well future-proof the code and use the PDO extension, use prepared queries, and use exceptions for database errors. This will actually simplify the php code (you can remove a lot of it, rather than to convert it) and it will simplify the sql query syntax.

Next, code that is old enough to be using these functions is probably poorly organized and insecure. Reorganizing at least the database dependent code, at the same time as changing the database extension, would be a good idea. Any security holes, such as cross site scripting and email header injection would need to be corrected in any case.

Finally, approximately how much code is there. How many files make up the site and how many lines of code are in the largest files?

#3

Thanks for taking the time to reply. You are correct on the old code being poorly organized and (possibly) insecure. It was originally build by two different people, one who was new and just learning to code in php, and the other used Dreamweaver’s features to help build some of the site (he can’t code from scratch.) Neither work for us anymore.

The two sections that were built by the guy using Dreamweaver can be taken down “for maintenance” if necessary.

The remaining site I don’t believe (operative words) uses that much code. My goal is just to patch this for the next month or two, while I learn to use WordPress to redesign the site. People have told me WordPress is easy and I can have a site up in no time, but I want to take the time to do it right. Then, once that is done, I want to try (don’t know if I’ll be successful, but really interested) to learn PHP, since it seems to be the basis for most things on the web.

Again, thanks for taking the time to reply.

#4

Just so that you are aware, changing to the mysqli extension requires more than just adding an i to the function names. The statements that are dependent on the connection now require the connection as a parameter (mysql used the last connection by default) and the parameter order is different from the mysql statements. There is also no mysqli equivalent for mysql_result().

#5

In other words, it’s pretty much hopeless to get and quick fix until I can transition to WordPress.

I do thank you for your time.

#6

It all depends on how much code there is (see the reply from @JimL in your other thread.) Someone posted a thread in the not too distant past about updating old code and made it seem like it was a big project. It turned out there was only about 2-3 database queries and it probably took less than an hour to update the code.

#7

Will check it out, thanks.

#8

Here’s a boiled down example of PDO usage compared with mysql.

//// typical mysql code w/o any external data being put into the query

$sql = "SELECT ...";

$result = mysql_query($sql);

// note: this closely couples the database specific code, that knows how to query for and fetch the data, with the presentation code, that knows how to produce the output from the data
while($row = mysql_fetch_assoc($result))
{
	// use elements in $row
}

//// typical mysql code with external string data being put into the query (for non-string data, this provides no protection)

$var = mysql_real_escape_string($some_var); // attempt to prevent sql special characters in the data from breaking the sql query, which is how sql injection is accomplished

$sql = "SELECT ... '$var' ...";

$result = mysql_query($sql);

while($row = mysql_fetch_assoc($result))
{
	// use elements in $row
}


// equivalent using the PDO extension 

//// typical PDO code w/o any external data being put into the query

$sql = "SELECT ...";

$stmt = $pdo->query($sql);

// in order to separate the database specific code from the presentation code, fetch all the data into a php variable, then test/use that variable in the rest of the code
$result = $stmt->fetchAll();

foreach($result as $row)
{
	// use elements in $row
}

//// typical PDO code with external data being supplied to a prepared query when the query is executed (provides protection for all types of data)

// any _escape_string() statements are removed

// a simple ? place-holder is put into the sql query statement for each value. any single-quotes, {}, or concatenation dots to get the previous variables into the query are removed.
$sql = "SELECT ... ? ...";

$stmt = $pdo->prepare($sql);

// an array of the variables holding the data is supplied to the execute() call
$stmt->execute([$some_var]);

$result = $stmt->fetchAll();

foreach($result as $row)
{
	// use elements in $row
}

For the database statements that you listed, here is how you would handle them using the PDO extension -

  • mysql_fetch_object() - use one of the pdo fetch statements with an appropriate fetch type (PDO::FETCH_OBJ).
  • mysql_num_rows() - just test the fetched data. for a multi-row query, use php’s count() function on the fetched data to get the number of rows.
  • mysql_query() - use the ->query() method for a non-prepared query and use the ->prepare() and execute() methods for a prepared query
  • mysql_result() - code using this should be rewritten to just fetch the row(s) of data, then use the elements of the fetched data.
  • mysql_fetch_array() - use one of the pdo fetch statements with an appropriate fetch type.
  • mysql_error() - code shouldn’t be outputting database errors onto a web page. remove any existing error handling and use exceptions instead.
  • mysql_insert_id() - use the pdo lastInsertId() method.
  • mysql_connect() - make the connection using the PDO constructor. the connection should set the character set, set the error mode to exceptions, set emulated prepared queries to false, and set the default fetch mode to assoc.
  • mysql_pconnect() - code shouldn’t be using both the connect() and pconnect() functions. a pconnection only does anything in a very specific server configuration and shouldn’t be used unless you know what you are doing.
  • mysql_real_escape_string() - not used with prepared queries.
  • mysql_select_db() - the database is selected when the connection is made. If you have multiple databases, either execute a USE … query or specify the database name with the table name in the query.
  • mysql_data_seek() - well written code should not need to use this. For a multi-row query, just loop over the array of fetched data again or directly access elements in the array of fetched data.
  • mysql_escape_string() - not used with prepared queries (the existing code should not be using this anyways, see mysql_real_escape_string())
  • mysql_fetch_assoc() - use one of the pdo fetch statements with an appropriate fetch type. Since assoc data is probably (should be) used in most cases, set the default fetch mode to assoc when the connection is made.
  • mysql_free_result() - for most applications, you don’t need to free up results (if a typical application is using so many resources that this matters, you are probably doing something wrong.)
  • mysql_close() - php destroys all resources used on a page when the script ends, so in most cases, you don’t need to close connections or free up things.
Sponsor our Newsletter | Privacy Policy | Terms of Service