DB_escape_string

[icedlava]

Hi Phil,

Well maybe we could do this inside the DB_query function - just sending an array parameter to DB_query and mysql_real_escape each parameter inside it.

The bind parameter method is just one option and it is a big job. I set up a new function eg DB_bindquery in my example because of that. It allows one to got through each script one by one, leaving the rest of the codebase in place while each script is addressed.

With bind variables and an array, there needs to be different processing than in DB_query. A rough example of one way of handling for webERP :

Code:

function DB_bindquery($query,
                    &$Conn,
                    $bindvars = null,
                    $ErrorMessage='',
                    $DebugMessage= '',
                    $Transaction=false,
                    $TrapErrors=true)
{

    global $debug;
    global $PathPref;
    global $db;

    $query = filter_var($query, FILTER_SANITIZE_STRING); //sanitize the string
    $stmt = $Conn->prepare($query);

    if (is_array($bindvars) === true) {
        $params = array(''); // Create the empty 0 index
        foreach ($bindvars as $prop => $val) {

            switch (gettype($val)) {
                case 'NULL':
                case 'string':
                    $params[0] .= 's';
                    break;

                case 'integer':
                    $params[0] .= 'i';
                    break;

                case 'blob':
                    $params[0] .= 'b';
                    break;

                case 'double':
                    $params[0] .= 'd';
                    break;
            }

            array_push($params, $bindvars[$prop]);
        }
        call_user_func_array(array($stmt, 'bind_param'), refValues($params));
    }

    $stmt->execute();
    $result = bindResults($stmt);

$stmt->close();
    return $result;

That is not doing the error handling yet and please excuse any errors in above but it's the idea of it.
[edit - added] Some small functions refValues and bindResults called also not posted here.

It is a MASSIVE job - but between us we could break it down into bite size chunks?

I've done similar before in other projects some years back, and at some point I think it has to be done for webERP - this method or another - and better now than later.

It isn't --that-- much work once you have a few people get into it.
If you can have the old DB_query still functioning while you update to whatever the new function name is in scripts, it enables you to have them both working concurrently until the whole code base is processed.

Because it is massive, other areas of the code like the audit trail would need to be considered at the same time.

Also, you still need to look at display of variables -will you use an api to process get/post/session vars or will you treat each variable individually? Sometimes this type of work is best done at the same time as other massive jobs as we have to go through a script anyway.

---

Forgot to mention - this is where it gets difficult with PHP compatibilities.

Some decision would also need to be taken here about how to handle differences eg php >= PHP 5.3 and whether to continue to support a php 5.2 branch. What would be minimum PHP level (php 5.3 is no longer supported) given php 5.5.10 is the current release and php 5.6 alpha is out, or will we have a maintenance branch for older PHPs?