foreach ($forumcache AS $forumid => $forum)
{
if ($vboptions['something'])
{
// do stuff
}
}
}
Rather, the code should look like this:
PHP Code:
function foo()
{
global $vbulletin;
foreach ($vbulletin->forumcache AS $forumid => $forum)
{
if ($vbulletin->options['something'])
{
// do something
}
}
}
Database
The MySQL database class has been totally rewritten, and the object is now called $db, rather than the old $DB_site.
You can also reference the database object via $vbulletin->db, so there is no real need to put $db into the list of globals in functions.
PHP Code:
function foo()
{
global $vbulletin;
$items = $vbulletin->db->query_read("SELECT * FROM " . TABLE_PREFIX . "user");
while ($item = $vbulletin->db->fetch_array($items))
{
// do stuff
}
$vbulletin->db->free_result($items);
}
Outside of function scope however, continue to use $db rather than $vbulletin->db.
Whereas we used to have a single $DB_site->query() function to run SQL queries, there are now three public functions to execute SQL. They are:
$db->query_read
Use this function to execute SELECT and SHOW queries only. If the user is using MySQL replication, these queries will execute on their slave server.
PHP Code:
$db->query_read("SELECT * FROM customer WHERE clue > 0");
$db->query_write
Use this function to execute UPDATE, ALTER and all other data-modifying queries. query_write() will execute on the master server in a replication situation.
PHP Code:
$db->query_write("UPDATE customer SET description = 'Clueless' WHERE clue <= 0");
addslashes() and addslashes_like() should be dropped in query strings, as it's problematic for some non-MySQL systems. Right now, the correct way to replace these functions is to use the newly defined functions in the database class, like this:
PHP Code:
$item = $db->query_first("
SELECT * FROM table
WHERE foo = '" . $db->escape_string($foo) . "'
AND bar LIKE('%" . $db->escape_string_like($bar) . "%')
");
Please also note that when escaping quotes for Javascript strings, you should no longer use 'addslashes()', but rather use 'js_addslashes()'.
Datastore
All items from the datastore now get fed directly into the $vbulletin class.
They become $vbulletin->itemname.
If their title is in the $unserialize array in the datastore class, they will be automatically unserialized when they are fetched.
Note that the code currently has a lot of code that is equivalent to
PHP Code:
if (isset($datastore_item))
That will not work any more, as the datastore item variables are initialized with the datastore class.
Therefore, instead of checking 'isset' you will need to check
PHP Code:
if ($vbulletin->datastore_item !== null)
Bitfields
The old $_BITFIELDS, $_FORUMOPTIONS, $_USEROPTIONS etc. arrays no longer exist as individual entities. They are now part of the $vbulletin data registry object and go by different names. All the data they contained is still there, but you'll need to talk to them differently.
If you look at the top of includes/class_core.php I have left a 'translation lookup table' so that it's easier to see where the data you are looking for has gone.
To avoid too much $object->array[key1][key2][key3][key4] stuff, there are references set up to allow you to talk to deep elements quickly. For example, $vbulletin->bf_ugp_adminpermissions is a reference to $vbulletin->bf_ugp['adminpermissions']... it makes more sense when you start using them
Oh... 'ugp' stands for usergroup permissions.
vB_Input Class
If you read includes/class_core.php, you'll notice that there's a class called vB_Input. This class deals with input into vBulletin and stuff that's related to the superglobal arrays ($_REQUEST, $_ENV, $_SERVER etc.)
Misc
As lots of variables have been shuffled around, you'll need to keep your eyes open for them. For example, $scriptpath is now $vbulletin->scriptpath and $nozip is now $vbulletin->nozip.
I strongly suggest that you read and familiarize yourself with the new init.php and the contents of includes/class_core.php before diving in.
01-22-2006, 10:00 PM
