[fixed] bug in the SQL backup feature

[bira]

The backup feature in the Admin CP is ignoring isnull and switching ALL fields to a NOT NULL fields in the .sql dump file.

example:

Dump via telnet (mysqldump -d):



awaydate int(10) unsigned default NULL,
returndate date default '0000-00-00',
awayreason varchar(200) default NULL,


Dumping via phpMyAdmin:


awaydate int(10) unsigned,
returndate date DEFAULT '0000-00-00',
awayreason varchar(200),


And, dumping via vBulletin's backup script:



awaydate int(10) unsigned NOT NULL,
returndate date DEFAULT '0000-00-00' NOT NULL,
awayreason varchar(200) NOT NULL,


Tested and verified.

Cheers,

Bira

[bira]

No idea why this is such a crime against humanity (;)) but after testing, this is the fix:

in admin/backup.php find:



if ($field[Null] != "YES") {
// can field be null
$tabledump .= " NOT NULL";
}


And change it to:



if ($field["Null"] != "YES") {
// can field be null
$tabledump .= " NOT NULL";
}


The quotation marks around Null fix it.

[Tommy Boy]

Nice catch bira! This brings us to the bad way arrays are referred to in the vBulletin code... Here is what I mean, extracted from the PHP official website:
Array do's and don'ts

Why is $foo[bar] wrong?
You might have seen the following syntax in old scripts:

$foo[bar] = 'enemy';
echo $foo[bar];
// etc

This is wrong, but it works. Then, why is it wrong? The reason is that, as stated in the syntax section, there must be an expression between the square brackets ('[' and ']'). That means that you can write things like this:

echo $arr[ foo(true) ];

This is an example of using a function return value as the array index. PHP knows also about constants, and you may have seen the E_* before.

$error_descriptions[E_ERROR] = "A fatal error has occured";
$error_descriptions[E_WARNING] = "PHP issued a warning";
$error_descriptions[E_NOTICE] = "This is just an informal notice";

Note that E_ERROR is also a valid identifier, just like bar in the first example. But the last example is in fact the same as writing:

$error_descriptions[1] = "A fatal error has occured";
$error_descriptions[2] = "PHP issued a warning";
$error_descriptions[8] = "This is just an informal notice";

because E_ERROR equals 1, etc.

Then, how is it possible that $foo[bar] works? It works, because bar is due to its syntax expected to be a constant expression. However, in this case no constant with the name bar exists. PHP now assumes that you meant bar literally, as the string "bar", but that you forgot to write the quotes.

So why is it bad then?

At some point in the future, the PHP team might want to add another constant or keyword, and then you get in trouble. For example, you already cannot use the words empty and default this way, since they are special keywords.

And, if these arguments don't help: this syntax is simply deprecated, and it might stop working some day.

[Freddie Bingham]

v3.0 will have all arrays quoted properly and we expect it to run with any level of error reporting and not output any warnings.

[Tommy Boy]

Excellent, that's great to hear! Will it also fully support PHP 4.1.0, with register_globals set to off?

[DarkReaper]

Must...have...3.0....... :D

[tubedogg]

Originally posted by Tommy Boy
Excellent, that's great to hear! Will it also fully support PHP 4.1.0, with register_globals set to off? register_globals being off is not a requirement for PHP4.1.0...

[Tommy Boy]

Originally posted by tubedogg
register_globals being off is not a requirement for PHP4.1.0... True, but it is recommended. Therefore, I may wish to convert my site to support it, and I want to know if vBulletin will support it too.

[John]

Yes, we do plan to support it.

John

[Tommy Boy]

Thank you! You're doing a great job! (yeah, like this is the first time you hear that...) ;)