#51207 closed defect (bug) (worksforme)
wpdb query returns incorrect value for update ( using mysql )
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.5 |
Component: | Database | Keywords: | |
Focuses: | Cc: |
Description
According to the docblock for query() function in wp-db.php , the expected return value should be...
@return int|bool Boolean true for CREATE, ALTER, TRUNCATE and DROP queries. Number of rows affected/selected for all other queries. Boolean false on error.
However, when evaluating the code for actual behavior, the wpdb->query function returns -1 during an UPDATE, if no rows are updated, even if there is no error.
One way to replicate this is, using a fully featured modern IDE:
1) set a conditional break-point on the first line of wpdb->query function, to catch any update operation. I used the condition below:
(strpos($query, 'UPDATE') === 0)
2) With live-debugging enabled for your WordPress website, visit the edit page for any post and save/publish without making any changes.
3) Step through the code to reach the line where the return value is set.( line 1978-1984 on Worpdress 5.5 )
// Return number of rows affected. $return_val = $this->rows_affected;
4) note the value ( for me it's consistently -1, provided that the update is performed without altering any data.
This bug makes it difficulty to rely on the returned value of the wpdb function on update operations, if we want to apply any error messaging or handling logic.
Solution is to use a PHP version >7.4. See best anwer on https://stackoverflow.com/questions/53813908/print-rmysqli-1-changes-mysqli-affected-rows
There is a bug of sorts affecting use of mysqli within a live xdebug debugging session. This makes it so that the value of mysqli::affected_rows is always -1.
See: https://bugs.php.net/bug.php?id=67348
I was able to get the expected values for mysqli::affected_rows, by using var_dump() in lieu of live-inspecting the value.