Skip to content

Loading…

Update ADOdb to 5.19 release + oci8 / pgsql bug fixes #181

Merged
merged 6 commits into from

5 participants

@dregad
Mantis Bug Tracker member

This covers the following

  • update of ADOdb library submodule to v5.19 (we were using a development release until now)
  • Fix for regression issue introduced by ADOdb 5.19 (in fact caused by us not defaulting a db_query_bound() parameter to the same value as the underlying ADOdb function)
  • Permanent fix for http://www.mantisbt.org/bugs/view.php?id=15426 (revert the implemented workaround)

EDIT: The fixes below were part of the originally submitted pull request, but were later split out and committed separately

  • Fix regression in logging API introduced by 2d0df25

==> See c2513b1

==> See f0c040e

@grangeway

bed3064: can you provide a diff that includes what changes in this

977a7aa: -1 - Can we do this within db_query()/_bound(). It makes more sense to pass 'null' into the function when there are no parameters, and makes it easier to merge in future. In terms of the code change for this commit, the mapping between "null"/"false" can be handled within the function as easily as outside. Given we document the function as taking an array, I'd consider in most languages 'null' to not fall under the documentation definition of 'array'. In the case of using boolean's, we'd need to document the function as taking bool|array, which is more confusing. Moving forwards, I'd:
a) be more inclined to keep it as a choice of null|array
b) by handling the difference between false|null within db_query_bound, it avoids breaking plugins.

407756b: +1 I think - although shouldn't the $s_msg I originally added be $t_msg ? (don't we use s_ for static variables elsewhere in the source). (Looking the original code I ported this from, this looks like a porting issue in the first place - sorry about that, and good spot.)

+1 to the other 2 bits for now

-1 to 0b7e9c0 in it's current form. Let me think about 0b7e9c0 a bit - I currently believe that both the existing behaviour and your fix are incorrect. The existing behaviour is broken for both the new db layer and the existing DB Layer - and whilst changing it to true/false 'fixes' the DB part, I think this is just moving the problem elsewhere.

@grangeway

Right, now I've had some food - 0b7e9c0

There's 3 things to consider with the VERSION_FUTURE constants

Currently these are defined as an INT. Your patch currently changes these to a BOOL.

For the DB Layer, both in your ADODB stuff and even more so in the new DB Layer, we need the version type to be handled as a BOOL. I need to check what I've done here so far as i'm fairly certain I've not changed the data type (yet), and the new db layer is stricter in terms of data type checking as you are aware.

However,

a) Within the Soap API, it looks like we treat it as a BOOL (presumably as the WSDL is stricter about types
b) Within the custom functions API we treat it as an INT (P.S. this needs fixing)
c) Within print_version_option_list we treat it as an INT.

d)

Versions

define( 'VERSION_ALL', null );
define( 'VERSION_FUTURE', 0 );
define( 'VERSION_RELEASED', 1 );

I'm looking at that in it's current form and thinking - else where in the code, we normally treat ALL as being 0 e.g. ALL_USERS, ALL_PROJECTS, REVISION_ANY.

I could see a valid case when defining versions for want to allow a greater array of project versions. For instance, ALPHA / BETA / OBSOLETE / RELEASE / SERVICE PACK etc spring to mind.

In an ideal world, I'd probably be inclined to say that the version table should be able to represent these, and wonder if we would be better serviced by changing the database to an integer type to support this concept.

@vboctor vboctor commented on an outdated diff
core/project_hierarchy_api.php
@@ -172,7 +172,7 @@ function project_hierarchy_cache( $p_show_disabled = false ) {
WHERE $t_enabled_clause
ORDER BY p.name";
- $t_result = db_query_bound( $query, ( $p_show_disabled ? null : array( true ) ) );
+ $t_result = db_query_bound( $query, ( $p_show_disabled ? false : array( true ) ) );
@vboctor Mantis Bug Tracker member
vboctor added a note

Maybe add a comment why we have "false" vs. "array( true )".. Why not both arrays for example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@vboctor
Mantis Bug Tracker member

0 - I'll pass on this review. But good to see us upgrade to the release version of ADODB instead of a private one. Thanks for pushing this along.

@grangeway

Where are we on this?

in terms of victor's comment, i'm wondering if array() i.e. empty array is better then null.

@dregad
Mantis Bug Tracker member

As I told you this week-end haven't had time to go into details of your feedback.

@dregad
Mantis Bug Tracker member

bed3064: can you provide a diff that includes what changes in this

ADOdb submodule is a git repository in itself. Since I don't know what you want to compare against, I invite you to to the diff yourself, e.g. mantisbt/ADOdb@ADOdb:v5.11...mantis-1.3 (v5.11 is what was in master before I started working on it) or on command-line

$ git diff bed3064^..bed3064 -- library/adodb/
diff --git a/library/adodb b/library/adodb
index c1abd33..9346d28 160000
--- a/library/adodb
+++ b/library/adodb
@@ -1 +1 @@
-Subproject commit c1abd33cf8f4c67a98f559a0028f39d8194b21f0
+Subproject commit 9346d288a1b7f7a50cc35b6a0e56d29e9d000ecf
$ cd library/adodb/
$ git diff c1abd33c..9346d28

977a7aa: -1 - Can we do this within db_query()/_bound(). It makes more sense to pass 'null' into the function when there are no parameters, and makes it easier to merge in future.

I disagree. It makes perfect sense to align the default param to what ADOdb expects as it allows a very minimalistic and low impact change in the code. On the other hand, keeping null as the default implies adding an is_array() check within db_query_bound() to transform non-null scalar values to arrays before calling $g_db->Execute(), which I consider unnecessary overhead.

407756b: +1 I think - although shouldn't the $s_msg I originally added be $t_msg

I didn't think about it, but probably yes. Will fix.

-1 to 0b7e9c0 in it's current form.
[...]
I could see a valid case when defining versions for want to allow a greater array of project versions. For instance, ALPHA / BETA / OBSOLETE / RELEASE / SERVICE PACK etc spring to mind.
[...]
we would be better serviced by changing the database to an integer type

I'm don't think that is necessary today - I would rather manage this with a proper version numbering scheme rather than relying on external fields.

Considering that these flags are currently used to control where the versions are shown (changelog, roadmap, and in the selection lists when editing the version fields in bugs, e.g. only devs can see non-released versions), unless these are changed (e.g. if we had a revamped changelog allowing users to filter versions by type), it makes sense to keep boolean.

If you think that's something worth doing in the future, then I suggest you log a separate issue for this feature in the tracker. And try to get the foundation of that change (i.e. schema change, revert constants to numeric and update manage_proj_ver_edit_page.php) in before 1.3.0a1 release so that we have one less bool->int column conversion to worry about later on.

For now, this commit should go in as-is.

@grangeway

977a7aa : -1 - Can we do this within db_query()/_bound(). It makes more sense to pass 'null' into
the function when there are no parameters, and makes it easier to merge in future.
I disagree. It makes perfect sense to align the default param to what ADOdb expects as it allows a
very minimalistic and low impact change in the code. On the other hand, keeping null as the default
implies adding an is_array() check within db_query_bound() to transform non-null scalar values to
arrays before calling $g_db->Execute(), which I consider unnecessary overhead.

Changing the default to what adodb has changed to, when we've used the current behaviour for the last 10 years, and when we plan to drop adodb shortly after the 1.3 release - and potentially then changing back to what we have now, doesn't really make sense to align.

In fact, it generates work for anyone using the code to change to match the new default, then change it back.

In any case, when thinking about this, what you seem to have missed is my reference to Victors comment: "in terms of victor's comment, i'm wondering if array() i.e. empty array is better then null." -i.e. should we not use array() instead of either null or false.

@grangeway

"For now, this commit should go in as-is." - actually, we should fix the code first. I know I've gone off on a tangent talking about the future, but in any case - the types need to match:

a) Within the Soap API, it looks like we treat it as a BOOL (presumably as the WSDL is stricter about types
b) Within the custom functions API we treat it as an INT (P.S. this needs fixing)
c) Within print_version_option_list we treat it as an INT.
d)Versions - define( 'VERSION_ALL', null ); define( 'VERSION_FUTURE', 0 ); define( 'VERSION_RELEASED', 1 );

If we change to BOOL, we need to fix B+C
if we keep as INT, we need to do a schema update and fix A
My comment about D and about future version types is more a case of, where we have half the code expecting an int and half expecting a Boolean, changing the #define from int to a bool, still leaves the code broken.

As it stands, this is currently only a partial fix for "moving to bool". The reason I said about let me have a think and about this in the first place is we need to do further work to make this patch good, so it's worth spending a few minutes to think about what we actually want to be doing here.

On a serious note, " ALPHA / BETA / OBSOLETE / RELEASE / SERVICE PACK " and "And try to get the foundation of that change (i.e. schema change, revert constants to numeric and update manage_proj_ver_edit_page.php) in before 1.3.0a1 " - if people think that's a good idea and would be useful, I could probably get that implemented during the day tomorrow. At least it'll beat spending the 4 hours today with a work colleague working out why IE11 wasn't rendering a web page in the way i'd expect to find out that IE11 kicks into non-standards mode in an intranet zone :)

@grangeway

@atrol @rombert thoughts?

And would you say if converting this to support multiple things, we convert obsolete+released columns to a single 'status' column?

@dregad
Mantis Bug Tracker member

Changing the default to what adodb has changed to

ADOdb did not change anything it always used 'false' - the only thing that changed is that it's now doing a strict type check, and null !== false.

it generates work for anyone using the code to change to match the new default

All changes in MantisBT code base are done in the commit. Only people calling db_query_bound() with null as second parameter would be impacted, the probability of which is actually quite low.

then change it back.

I don't see the need of changing back at all actually.

i'm wondering if array() i.e. empty array is better then null.

Now that's a different story, and actually it would make sense. We'd still need to add a check to convert any scalar value received in $arr_parms to an array, but then that could break existing calls, e.g. with db_query_bound($sql, null) it would become array(null) but it should probably be array() so we're basically hitting the same issue of "generat[ing] work for anyone using the code to change to match the new default"

@dregad
Mantis Bug Tracker member

Regarding your other comment, even though I agree it's not a complete fix, I'm still saying that my commit is an improvement over the current state, and therefore a change worth making.

The fact that additional fixes are required is not a reason to hold this. They can easily be implemented afterwards.

With regards to converting to an int, providing additional statuses and now even converting released + obsolete as a single status column, I am not opposed to the idea but that is in fact a new feature, and is therefore off-topic in this pull request which focuses on fixing issues related to oracle and pgsql support. Please open a new issue in the tracker for that, and let's discuss it separately.

@atrol
Mantis Bug Tracker member

@atrol @rombert thoughts?

Sorry, not enough time to have a deeper look at it

@grangeway

Reading atrol's comment and Damien's, I'll start work on how easy it is to convert to an int format and add the additional feature off the current master.

@dregad
Mantis Bug Tracker member

@grangeway I'll take your last comment as a green light to merge this, will proceed later tonight or tomorrow as time allows.

Feel free to implement incremental fixes for the bool->int thing at your convenience.

@grangeway

erm, no - my point was a -1 to this as it's breaks other things (which we need to fix) and I've already started work on a patch to convert to int's based on current master.

So until we either fix this properly, it's still a -1 for me

@grangeway

Btw, would love to know you you translate "i''ll start work on converting to an int format (due to the issues I've been mentioning off the current master" as a green light to merge something that's broken.

@grangeway

Damien, as a sensible way forward, I'd recommend splitting this into separate commits for the completely different things it fixes (i.e. changing db_query_bound format which both victor/myself had concerns about, changing bool<>int (which currently breaks other parts of the code that currently work) and logging api improvements, and adodb upgrade

we can then get the logging/adodb upgrade merged, and worry about the best format for the other functions.

@grangeway

PR 209 generated for the version enhancements

@grangeway

For clarify,

-1 to merging this PR - the logging API change in this pull request also is incorrect. Apologies for not spotting this before.

I suggest we split this out, so we can get the bits that don't need refining merged.

@dregad
Mantis Bug Tracker member

the logging API change in this pull request also is incorrect

Excuse me ??? If you ignore the variable name, the fix is identical... please explain in what way it is incorrect.

With regards to splitting, sorry but I have other things to do with my time. This would have been merged weeks ago without your blocking it. Feel free to cherry-pick the changes if you need them in one of your branches.

@grangeway

Actually, it's not the same - there's a subtle difference in the fact that for the firebug call we don't change the variable.

In any case, this branch isn't yet in a state where it's ready to merge.

@dregad
Mantis Bug Tracker member

@grangeway wrote in #208 (comment)

I suggest we split out #181 into it's different components.

Details please

@grangeway

and with regards to the ADODB pull request, I've already said several times, the pull requests covers 4 unique changes (I mean, it's pretty hard to argue that the logging API fix is part of an adodb update)

I've already said i'm fine with updating adodb (1 change - although, personally, i'd like to see us move to the new db layer as opposed to spending time changing adodb)

Victor/myself both raised concerns about the change to db_query_bound - personally, having thought about it more, I consider our current implement of db_query_bound to be incorrect (which iirc I wrote. I consider the change you are making to be pointless as it generates more work for end users updating their code. I think that Victor's feedback on the code is probably the correct implementation to use long term.

If we really want to use one implementation in 1.2, a different one in 1.3 and a 3rd implementation when we replace the db layer (which will involve work by plugin authors) then fine, but that seems like us being awkward to the end user as we could implement the db_query_bound change without changing the API.

The version stuff as I've said already in the other thread takes mantis from a broken state, moves it to a different broken state, hence me spending my time to look at converting it to use INT's in the DB so it will work in all cases. The attempt to fix it as a complete fix, you would have already been able to review tonight, if it wasn't for the fact i've managed to push the wrong branch later last night.

Part of our review goal should be to get quality fixes/code in - I'm not arguing the current code works - it's currently broken. What I am arguing is if we are going to take the time to review code, we should really be going for a complete fix, otherwise we may as well not bother with delaying stuff by reviewing in Pull Requests.

For instance, I was a bit surprised Victor merged his timeline code the other day as I thought he was still looking into improving it - I know from my point of view, I'd like to have seen phpdoc comments in the code before it was merged. However, I didn't pick up that victor had made commits following my initial comments on how it works - I don't recall getting an email from github, but i'm guessing that's due to it only being a commit and not a new comment, and I didn't go into phpdoc/code standards on my initial review as I wanted to talk about the implementation itself. It would have been nice if victor had taken the time to add phpdoc etc and fix "if (" -> if(, but equally, there's no point making an issue over that as until we get some php codesniffer rules finalised (which as you know i've said i've been starting to look at) it's not easy for others to ensure they don't miss a standard, or even miss a phpdoc comment. I'll probably do a commit/PR to add phpdoc comments to victors code at some point to keep the code base tidy. If I'd have known it was going to get merged as was, I would probably have said "please add phpdoc" so as not to have to generate a follow up commit...

@grangeway
@rombert
Mantis Bug Tracker member
@dregad
Mantis Bug Tracker member

@grangeway when we spoke on IRC end of last week, I gave you until Sunday to act on this as you said you'd be spending the week-end working on Mantis. It's now Monday afternoon and still nothing...

This is your last chance to propose a better fix before I merge this PR.

@dregad
Mantis Bug Tracker member

I extracted (and pushed to master) the commits that were not related to the ADOdb update, then rebased the branch on top of master.

Following @grangeway's recent commit 5458f70 which changed the signature of db_query_bound(), I need to rework 002fbc1e802dbfbb692a4ce530667bd4b3596861 because my original fix is no longer valid.

dregad added some commits
@dregad dregad Update ADOdb to 5.19 b7ebffd
@dregad dregad oci8 no longer needs special fetch mode with ADOdb 5.19
Fixes #15426
84d21a6
@dregad dregad Use ADODB-specific constant instead of 'false' f9c2aec
@dregad dregad Coding guidelines 83e1cfd
@dregad dregad Fix db_query_bound() to work with ADOdb::Execute()
In ADOdb v5.19 the Execute() method was modified to perform a strict
type check on the $inputarr parameter. Since that param defaults to
'false', database errors are triggered when the method receives 'null'
and there are no parameters to the query being executed.

Since db_query_bound() $p_arr_parms defaults to null, the problem occurs
almost everywhere. To fix this, we can either:

  1. set $p_arr_parms to array() when it is null
  2. defaut $p_arr_parms to array()

The 2nd option would cause errors with db_query_bound($sql, null)
calls, so we implement the first one as it offers better backwards
compatibility.

Function can be called like this (the first 3 methods being equivalent):
- db_query_bound($sql)
- db_query_bound($sql, null)
- db_query_bound($sql, array())
- db_query_bound($sql, array(1,2))
fbf016c
@dregad dregad Call db_query_bound() with array() instead of null
This is not strictly necessary right now, but replacing known occurences
avoids future refactoring should we decide to change the default value
for $p_arr_parms to array() later on.
c726ff7
@dregad
Mantis Bug Tracker member

OK I rebased the branch, fixing the ADOdb::Execute() problem by updating db_query_bound() to set $p_arr_parms to array() when it is null. This offers the best backwards-compatibility, at the expense of slighly more complex code (extra if statement).

The alternative of defaulting $p_arr_parms to array() in the function signature would have been cleaner, but would cause errors with db_query_bound($sql, null) calls.

Function can now be called like this (the first 3 methods being equivalent):

  • db_query_bound($sql)
  • db_query_bound($sql, null)
  • db_query_bound($sql, array())
  • db_query_bound($sql, array(1,2))

@grangeway let me know if you're OK with that

@dregad dregad merged commit c726ff7 into mantisbt:master

1 check passed

Details continuous-integration/travis-ci The Travis CI build passed
@dregad dregad added a commit that referenced this pull request
@dregad dregad Update ADOdb to 5.19
- update the submodule
- back to ADODB_FETCH_ASSOC for oci8
- fix db_query_bound() $p_arr_parms null default issue

Fixes pull request #181
a2b23b3
@dregad dregad deleted the dregad:adodb branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 7, 2014
  1. @dregad

    Update ADOdb to 5.19

    dregad committed
  2. @dregad
  3. @dregad
  4. @dregad

    Coding guidelines

    dregad committed
  5. @dregad

    Fix db_query_bound() to work with ADOdb::Execute()

    dregad committed
    In ADOdb v5.19 the Execute() method was modified to perform a strict
    type check on the $inputarr parameter. Since that param defaults to
    'false', database errors are triggered when the method receives 'null'
    and there are no parameters to the query being executed.
    
    Since db_query_bound() $p_arr_parms defaults to null, the problem occurs
    almost everywhere. To fix this, we can either:
    
      1. set $p_arr_parms to array() when it is null
      2. defaut $p_arr_parms to array()
    
    The 2nd option would cause errors with db_query_bound($sql, null)
    calls, so we implement the first one as it offers better backwards
    compatibility.
    
    Function can be called like this (the first 3 methods being equivalent):
    - db_query_bound($sql)
    - db_query_bound($sql, null)
    - db_query_bound($sql, array())
    - db_query_bound($sql, array(1,2))
  6. @dregad

    Call db_query_bound() with array() instead of null

    dregad committed
    This is not strictly necessary right now, but replacing known occurences
    avoids future refactoring should we decide to change the default value
    for $p_arr_parms to array() later on.
Showing with 19 additions and 21 deletions.
  1. +1 −1 core/constant_inc.php
  2. +12 −14 core/database_api.php
  3. +1 −1 core/project_hierarchy_api.php
  4. +1 −1 core/summary_api.php
  5. +1 −1 core/user_api.php
  6. +1 −1 library/README.libs
  7. +1 −1 library/adodb
  8. +1 −1 manage_user_page.php
View
2 core/constant_inc.php
@@ -39,7 +39,7 @@
# installation
define( 'CONFIGURED_PASSWORD', "______" );
-define( 'DB_MIN_VERSION_ADODB', '5.19dev' ); # For mssql, oracle and pgsql
+define( 'DB_MIN_VERSION_ADODB', '5.19' ); # For mssql, oracle and pgsql
define( 'DB_MIN_VERSION_MSSQL', '9.0.0' );
define( 'DB_MIN_VERSION_MYSQL', '5.0.8' ); # See #16584
define( 'DB_MIN_VERSION_PGSQL', '8.4' ); # Earliest supported version as of Jan 2014
View
26 core/database_api.php
@@ -53,18 +53,9 @@
# @global bool $g_db_log_queries
$g_db_log_queries = ( 0 != ( config_get_global( 'log_level' ) & LOG_DATABASE ) );
-
# set adodb fetch mode
# @global bool $ADODB_FETCH_MODE
-if( db_is_oracle() ) {
- # Due to oci8 returning column names in uppercase, the MantisBT
- # default fetch mode (ADODB_FETCH_ASSOC) does not work properly
- # in the current version of ADOdb (5.18) so we override it.
- # See #15426
- $ADODB_FETCH_MODE = ADODB_FETCH_NUM;
-} else {
- $ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
-}
+$ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
/**
* Mantis Database Parameters Count class
@@ -337,12 +328,19 @@ function db_query_bound( $p_query, array $p_arr_parms = null, $p_limit = -1, $p_
static $s_check_params;
if( $s_check_params === null ) {
- $s_check_params = ( db_is_pgsql() || $t_db_type == 'odbc_mssql' || $t_db_type == 'mssqlnative');
+ $s_check_params = ( db_is_pgsql() || $t_db_type == 'odbc_mssql' || $t_db_type == 'mssqlnative' );
}
$t_start = microtime( true );
- if( $p_arr_parms != null && $s_check_params ) {
+ # This ensures that we don't get an error from ADOdb if $p_arr_parms == null,
+ # as Execute() expects either an array or false if there are no parameters -
+ # null actually gets treated as array( 0 => null )
+ if( is_null( $p_arr_parms ) ) {
+ $p_arr_parms = array();
+ }
+
+ if( !empty( $p_arr_parms ) && $s_check_params ) {
$t_params = count( $p_arr_parms );
for( $i = 0;$i < $t_params;$i++ ) {
if( $p_arr_parms[$i] === false ) {
@@ -369,7 +367,7 @@ function db_query_bound( $p_query, array $p_arr_parms = null, $p_limit = -1, $p_
if( ON == $g_db_log_queries ) {
$t_lastoffset = 0;
$i = 0;
- if( !( is_null( $p_arr_parms ) || empty( $p_arr_parms ) ) ) {
+ if( !empty( $p_arr_parms ) ) {
while( preg_match( '/\?/', $p_query, $t_matches, PREG_OFFSET_CAPTURE, $t_lastoffset ) ) {
$t_matches = $t_matches[0];
# Realign the offset returned by preg_match as it is byte-based,
@@ -481,7 +479,7 @@ function db_fetch_array( IteratorAggregate &$p_result ) {
$p_result->MoveNext();
return $t_array;
} else {
- $t_row = $p_result->GetRowAssoc( false );
+ $t_row = $p_result->GetRowAssoc( ADODB_ASSOC_CASE_LOWER );
static $s_array_result;
static $s_array_fields;
View
2 core/project_hierarchy_api.php
@@ -172,7 +172,7 @@ function project_hierarchy_cache( $p_show_disabled = false ) {
WHERE $t_enabled_clause
ORDER BY p.name";
- $t_result = db_query_bound( $t_query, ( $p_show_disabled ? null : array( true ) ) );
+ $t_result = db_query_bound( $t_query, ( $p_show_disabled ? array() : array( true ) ) );
$g_cache_project_hierarchy = array();
$g_cache_project_inheritance = array();
View
2 core/summary_api.php
@@ -569,7 +569,7 @@ function summary_print_by_reporter() {
WHERE $t_specific_where
GROUP BY reporter_id
ORDER BY num DESC";
- $t_result = db_query_bound( $t_query, null, $t_reporter_summary_limit );
+ $t_result = db_query_bound( $t_query, array(), $t_reporter_summary_limit );
$t_reporters = array();
while( $t_row = db_fetch_array( $t_result ) ) {
View
2 core/user_api.php
@@ -1074,7 +1074,7 @@ function user_get_accessible_subprojects( $p_user_id, $p_project_id, $p_show_dis
WHERE $t_enabled_clause
ph.parent_id IS NOT NULL
ORDER BY p.name";
- $t_result = db_query_bound( $t_query, ( $p_show_disabled ? null : array( true ) ) );
+ $t_result = db_query_bound( $t_query, ( $p_show_disabled ? array() : array( true ) ) );
} else {
$t_query = "SELECT DISTINCT p.id, p.name, ph.parent_id
FROM $t_project_table p
View
2 library/README.libs
@@ -5,7 +5,7 @@ The version and status of each is summarized below:
-------------------------------------------------------------------
directory | project | version | status
-------------------------------------------------------------------
-adodb | adodb | v5.18a-49 | unpatched [1]
+adodb | adodb | v5.19 | unpatched [1]
disposable | disposable | 1.1.0 | unpatched
ezc | ez Components | 2009.2.1 | unpatched
phpmailer | PHPMailer | 5.2.6 | unpatched [1]
2 library/adodb
@@ -1 +1 @@
-Subproject commit c1abd33cf8f4c67a98f559a0028f39d8194b21f0
+Subproject commit 9346d288a1b7f7a50cc35b6a0e56d29e9d000ecf
View
2 manage_user_page.php
@@ -179,7 +179,7 @@
echo '</ul>';
echo '</div>';
-$t_where_params = null;
+$t_where_params = array();
if( $f_filter === 'ALL' ) {
$t_where = '(1 = 1)';
} else if( $f_filter === 'UNUSED' ) {
Something went wrong with that request. Please try again.