List of changed var/array/function names

[Brad]

A lot of things changed in 3.5 and you might find yourself lost for awhile as you figure out how to work with the new var/array/function names. This list should help you port your old 3.0.x hacks quicker, if you have anything to add to the list reply to this thread and I will edit the first post! :)

Note that some of these might not work in some parts of the new code, OOP changes a lot of things, in some cases you might be using $this-> or some other alternative to get to these.

On the front end they will work for the most part. Do remember that there are hooks littered in the 'build' functions like the one that builds postbit. For an example of working with such hooks you can check out a plug-in I released, I spend 5 minutes wondering why $post would not work until I realized I was begin an idiot!

Anyway check out the .xml file: https://vborg.vbsupport.ru/showthread.php?t=82623

Turned out I needed to use $this->post because that hook was inside of a function! Doh!

The big list...

3.0.x version of the var will be on the left, 3.5 on the right as so:

3.0.x => 3.5

Global

$DB_site-> => $db->
$bbuserinfo[] => $vbulletin->userinfo[]
$vboptions[] => $vbulletin->options[]
$_GET/$_REQUEST/$_POST/$_COOKIE => $vbulletin->GPC[]
globalize() => $vbulletin->input->clean_array_gpc()

[Colin F]

$DB_site->query(); => $db->query_read();

[Andreas]

Hmm ... not always.
Only for SELECT.
For REPLACE/UPDATE/INSERT it would be query_write(), to support mySQL 4.1 Master/Slave.
To keep compatibility, query() is also available and will call the correct connection.

[Brad]

Yea I'll need to add that one, will cause alot of questions when this goes public, thanks guys and keep adding them as you find them :)

[Wayne Luke]

The following was written by Kier for the developers. He has agreed to release it here.


Variables in the $vbulletin (vB_Registry) class

Just about all the variables that used to get set up by init.php have now been migrated to the $vbulletin class.

When migrating the old code, I don't want to see this sort of thing unless there's a specific reason for it:
function foo()
{
global $forumcache, $vbulletin, $vboptions;

$forumcache =& $vbulletin->forumcache;
$vboptions =& $vbulletin->options;

foreach ($forumcache AS $forumid => $forum)
{
if ($vboptions['something'])
{
// do stuff
}
}
} Rather, the code should look like this:

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.

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.
$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.
$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:
$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
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
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.

[Revan]

Thank you for this update, Wayne. It helped me answer my question about query_read vs query_write :)
[Removed question as more indepth studies of the files answered it]

[Andreas]

You can use query_first() as this basically does the same as query_read() and fetch_array().

[Brad]

You can also use the old school query();, but it preforms a preg call to check for the query type (SELECT = read, everything else = write). Really you should not use query(); anymore, but there is nothing stoping you from doing it ;)

[Revan]

Ah I see, thanks :)
I really wish they didn't add support for the old query(), this will only lead to lazy coders writing shi'ite stuff that keeps using these old, outdated versions, forcing vB to sacrifice performance in order to determine the correct function which again leads to a performance hit. :(.
I guess this means I will have to be more selective and conservative with the stuff I install, as I like things running fast and smooth :)

[AN-net]

god everything i have worked for has to be rewritten, damn u!!!!

also is $vbulletin->bbuserinfo[] now used in templates and where is official vbulletin.com documentation?

[Andreas]

god everything i have worked for has to be rewritten, damn u!!!!

That was to be expected :)

As far as I can see $bbuserinfo/$vboptions/$session is being unsed in the Templates.
But I am not sure if this will be changed.

[Zachery]

god everything i have worked for has to be rewritten, damn u!!!!

also is $vbulletin->bbuserinfo[] now used in templates and where is official vbulletin.com documentation?
No, the old way still works in the templates.

[Zero Tolerance]

if you're not in the mood to re-write all the variables, you can put stuff like:

$bbuserinfo = $vbulletin->userinfo;
unset($vbulletin->userinfo);

At the top of your files (after you've included the files you require), ofcourse if your embedding code into an existing vB 3.5 php file, like forumdisplay, i wouldn't use the unset function.

It's a quick and easy method, until you get time to properly convert everything :)

- Zero Tolerance

[Andreas]

*cough* functions_legacy.php, enable_legacy() *cough*

[Zero Tolerance]

*cough* functions_legacy.php, enable_legacy() *cough*
Or that will do too :p I really need to look through the files more.

- Zero Tolerance

[calorie]

That was to be expected :)

As far as I can see $bbuserinfo/$vboptions/$session is being unsed in the Templates.
But I am not sure if this will be changed.
Can the new way also be used, and if so, what way?

[Andreas]

I doubt so. But to get a definitive answer you should ask the developers :)

[calorie]

I doubt so. But to get a definitive answer you should ask the developers :)
See this (https://vborg.vbsupport.ru/showthread.php?t=82774) vB 3.5.0 mod, and look at the attached TXT file in that thread. It has <if condition="$vbulletin->userinfo['userid'] != '0' AND... in it, so is it that conditions use the new way, but things to be echoed use the old way, or ???

[Zachery]

See this (https://vborg.vbsupport.ru/showthread.php?t=82774) vB 3.5.0 mod, and look at the attached TXT file in that thread. It has <if condition="$vbulletin->userinfo['userid'] != '0' AND... in it, so is it that conditions use the new way, but things to be echoed use the old way, or ???
In a conditional, which is executed as raw php code. I could have used $bbuserinfo but I prefered to update and use the new code.

[calorie]

In a conditional, which is executed as raw php code. I could have used $bbuserinfo but I prefered to update and use the new code.
Okay, good, but what about vars in templates that just sit there to be echoed? New way or old way? If old, any hint as to what method (new vs. old) will be used in vB 3.5.0 final?

[noppid]

Very good explainations, thanks.

[Logikos]

When using something like this for an example:


$db->query_write("UPDATE thread SET open = '0' WHERE threadid <= 99");


That obviously will close a threadID 99. My question is. Do we have to use the TABLE_PREFIX before we define the table to update?

[Cap'n Steve]

What's the reason for changing the $_GET, $_POST, etc.? Is there any benefit to using the new versions?

[Zachery]

What's the reason for changing the $_GET, $_POST, etc.? Is there any benefit to using the new versions?Security

[calorie]

When using something like this for an example:


$db->query_write("UPDATE thread SET open = '0' WHERE threadid <= 99");


That obviously will close a threadID 99. My question is. Do we have to use the TABLE_PREFIX before we define the table to update?
I found $db->query_write("UPDATE " . TABLE_PREFIX . " in vB 3.5.0 code, so I'd guess yes.

[Erwin]

Security
Absolutely. You'd be surprised how many older hacks still use these variables without checking them.

[Revan]

Then again, as far as I can see theres nothing stopping a lazy coder from just using the superglobals.

[Cap'n Steve]

Absolutely. You'd be surprised how many older hacks still use these variables without checking them.

Ah, ok. So what does this class actually do to the variables? Is it basically a replacement for globalize()?

[Brad]

Ah, ok. So what does this class actually do to the variables? Is it basically a replacement for globalize()?

Basicly yes :)

[zetetic]

In 3.0.7 I put this code in phpinclude_start:
$buddyarray = explode(' ', $bbuserinfo['buddylist']);
And referenced that array using $GLOBALS['buddyarray'] in the templates.

In 3.5 I made a global_start plugin using this code:
$buddyarray = explode(' ', $vbulletin->userinfo['buddylist']);
But $GLOBALS['buddyarray'] doesn't seem to work.

Also the u=$userinfo[userid] doesn't seem to work in the postbit either. :ermm:

[tamarian]

Thanks for the how-to's :up:

I needed to use $session outside the templates, it's now:

$session => $vbulletin->session->vars

[noppid]

Thanks for the how-to's :up:

I needed to use $session outside the templates, it's now:

$session => $vbulletin->session->vars

That syntax you used may be confusing. It took me about 3 minutes to catch your drift. I see now that you were making a relation though. But here's what the new one looks like for the other folks.

$vbulletin->session->vars['sessionurl']

[tamarian]

That syntax you used may be confusing.

It shouldn't be :) That's the syntax suggested by the first post, left to right.

[noppid]

It shouldn't be :) That's the syntax suggested by the first post, left to right.

Sorry I tried to help. Perhaps I should just shut up. :/

I was not trying to start an argument.

[tamarian]

Sorry I tried to help. Perhaps I should just shut up. :/

I was not trying to start an argument.

Me neither. My post was not meant to offende you, and if it did, I apologize. I just meant that was the syntax used by Brad in his first post. Anyway, between the both of us, we may have actually helped someone. :)

[sabret00the]

what is the new array for $userinfo (not $bbuserinfo)

[Colin F]

what is the new array for $userinfo (not $bbuserinfo)
That's the one that's used on the members profile and so, right?

I just checked the memberinfo template, and it hasn't changed there...

[zetetic]

Yeah, I mentioned that u=$userinfo[userid] wasn't working in the postbit a few posts ago. I think we might have to wait for the documentation to find out all the new conditionals.

[tamarian]

userinfo is not a global variable like bbuserinfo. So it won't be part of the new $vbulletin object and other globals. The variable name for userinfo will be different depending on the script or template being edited.

[zetetic]

userinfo is not a global variable like bbuserinfo. So it won't be part of the new $vbulletin object and other globals. The variable name for userinfo will be different depending on the script or template being edited.
Thanks for the info, tamarian. I'll just use $post[userid] in the postbit instead. :)

Do you have any idea how I can solve this problem (https://vborg.vbsupport.ru/showpost.php?p=665292&postcount=30)? Is there a replacement for $GLOBALS?

[tamarian]

Thanks for the info, tamarian. I'll just use $post[userid] in the postbit instead. :)

Do you have any idea how I can solve this problem (https://vborg.vbsupport.ru/showpost.php?p=665292&postcount=30)? Is there a replacement for $GLOBALS?

How about this?

$vbulletin->userinfo['buddyarray'] = $buddyarray

[zetetic]

How about this?

$vbulletin->userinfo['buddyarray'] = $buddyarray
Hm... Actually I think I goofed up somewhere else before. $GLOBALS is working fine now.

[deathemperor]

function construct_page_nav now accepts 5 params, not just 3 as the legacy one

but I don't really know why the phpdoc only states for 3 params:


// ################################################## ###########################
/**
* Returns the HTML for multi-page navigation - based on code from 3dfrontier.com
*
* @param integer Total number of items found
* @param string Base address for links eg: showthread.php?t=99{&page=4}
* @param string Ending portion of address for links
*
* @return string Page navigation HTML
*/
function construct_page_nav($pagenumber, $perpage, $results, $address, $address2 = '')


1st param: current page number
2st param: number of items per page.
the last 3 params are defined in the phpdoc above, they're just like before.


Please update all the info that users submit so that others only have to look at the fist post so that they can check for what has been changed.

[Brad]

Yeah, I mentioned that u=$userinfo[userid] wasn't working in the postbit a few posts ago. I think we might have to wait for the documentation to find out all the new conditionals.
$userinfo did not change, it is still built in member.php take a look. The reason it didn't work in the postbit is it's not defined there, what your looking for is.

$post[userid]

[deathemperor]

$url => $vbulletin->url

-----------------------------------------

I can't use $vbulletin->input->clean_array_gpc as globalize()

with globalize()

globalize($_POST, array('e' => INT, 'do' => STR_NOHTML, 'iconid' => INT));

gives value to varibles $e, $do, $iconid

but with

$vbulletin->input->clean_array_gpc('p', array('e' => TYPE_UINT, 'do' => TYPE_STR, 'iconid' => TYPE_UINT));

I can't get $e, $do, $iconid

any suggestion to use $vbulletin->input->clean_array_gpc properly ?

EDIT: I figured out it turns to be $vbulletin->GPC['e'], $vbulletin->GPC['do'], $vbulletin->GPC['iconid'], am I correct ? how complex.

------------------------------------------

print_standard_error(...)
is now redundant. Instead, use
standard_error(fetch_error(...))

[scotsmist]

While looking at the changes needed for vbportal, I wanted to share what I found.

I see you have $bbuserinfo is now $vbulletin->userinfo listed, you may want to add $session is now $vbulletin->session

$session[sessionurl] for example is now $vbulletin->session->vars[sessionurl]
$session[sessionurl_js] is now $vbulletin->session->vars[sessionurl_js]

another is with the datastore caches which are unserialised in init.php

$forumcache is now $vbulletin->forumcache
$iconcache is now $vbulletin->iconcache
etc

another is $url is now $vbulletin->url
also $nozip is now $vbulletin->nozip
plus $scipt is now $vbulletin->script
and $scriptpath is now $vbulletin->scriptpath

in addition to $vbulletin->input->clean_array_gpc you can also use $vbulletin->input->clean_gpc when there is only one variable. you may wish to use something like $perpage = $vbulletin->input->clean_gpc('r', 'perpage', TYPE_UINT); so you can use $perpage in a template

the bitwise $_FORUMOPTIONS and $_USEROPTIONS have been replaced by $vbulletin->bf_ugp_forumoptions and $vbulletin->bf_ugp_useroptions

notice that HTML_SELECTED and HTML_CHECKED are not defined now

function iif() is marked as obsolete to ! (one of my personal favourites)

function bbcode_parse is now $bbcode_parser->parse

the print_standard_redirect function has changed a little and it doesn't pass the $url anymore, so you need to set $vbulletin->url first. the function also supports forceredirect, so there's no need to set $GLOBALS['forceredirect'] anymore.

[mute]

Big-board here, with the annoying questions nobody wants to answer.

I read all about the 3.5 changes on vb.com, but I didn't see anything about the query_write query_read abstraction until just now. Color me floored!

My question is, for us large sites that use MySQL replication functionality, is there anything in place currently to distribute reads among a group of servers which are replicating? I'd love to be able to easily spread reads to our slave server(s) for queries, and have the ability to pseudo load balance queries, or at least have some type of "failover", that is, if our slave server is unresponsive to remove it from the pool of available query_read capable servers.

Obviously this would be a very rudimentary form of clustering, but I'll take what I can get at this point (It's more MySQL's fault than anything else, not having master<->master replication sucks).

[Ratchet]

Does anyone know how the style vars are stored now? $style["imgdir_misc"] still works as before, but $style["title"] and some others do not.

[sv1cec]

$_GET/$_REQUEST/$_POST/$_COOKIE => $vbulletin->GPC[]

I read the above, but still in the code, there are instances that vBulletin uses $_REQUEST.

Can someone shed some light on this? Based on the above, I changed a program to use $vbulletin->GPC instead of $_REQUEST and the program no longer works. Switched back to $_REQUEST and everything works fine.

I am puzzled.

I think I need to elaborate:

In the past, I was using this part of code:


// ########################## REDIRECT ###############################
if ($_REQUEST['do'] == 'nextstep')
{
globalize($_REQUEST, array(
'action' => STR,
'done' => STR
));
if (empty($action))
{
define('CP_REDIRECT', THIS_SCRIPT . '.php');
}
else
{
define('CP_REDIRECT', THIS_SCRIPT . '.php?step=' . $action);
}
print_stop_message('redirecting_please_wait');
}


Now, the code has to be changed to:


if ($_REQUEST['do'] == 'nextstep')
{

$vbulletin->input->clean_array_gpc('r', array(
'action'=> TYPE_STR,
'done'=> TYPE_STR,
));

if (empty($vbulletin->GPC['action']))
{
define('CP_REDIRECT', THIS_SCRIPT . '.php');
}
else
{
define('CP_REDIRECT', THIS_SCRIPT . '.php?step=' . $vbulletin->GPC['action']);
}
print_stop_message('redirecting_please_wait');
}


I found this after a lot of trials and errors. What's the reason for having to check for $_REQUEST['do'] in the first if, and then use $vbulletin->GPC in the next parts? Where do I use $_REQUEST and where $vbulletin->GPC????

[Cloudrunner]

I read the above, but still in the code, there are instances that vBulletin uses $_REQUEST.

Can someone shed some light on this? Based on the above, I changed a program to use $vbulletin->GPC instead of $_REQUEST and the program no longer works. Switched back to $_REQUEST and everything works fine.

I am puzzled.

I think I need to elaborate:

In the past, I was using this part of code:


// ########################## REDIRECT ###############################
if ($_REQUEST['do'] == 'nextstep')
{
globalize($_REQUEST, array(
'action' => STR,
'done' => STR
));
if (empty($action))
{
define('CP_REDIRECT', THIS_SCRIPT . '.php');
}
else
{
define('CP_REDIRECT', THIS_SCRIPT . '.php?step=' . $action);
}
print_stop_message('redirecting_please_wait');
}


Now, the code has to be changed to:


if ($_REQUEST['do'] == 'nextstep')
{

$vbulletin->input->clean_array_gpc('r', array(
'action'=> TYPE_STR,
'done'=> TYPE_STR,
));

if (empty($vbulletin->GPC['action']))
{
define('CP_REDIRECT', THIS_SCRIPT . '.php');
}
else
{
define('CP_REDIRECT', THIS_SCRIPT . '.php?step=' . $vbulletin->GPC['action']);
}
print_stop_message('redirecting_please_wait');
}


I found this after a lot of trials and errors. What's the reason for having to check for $_REQUEST['do'] in the first if, and then use $vbulletin->GPC in the next parts? Where do I use $_REQUEST and where $vbulletin->GPC????Do this instead to avoid that situation:$vbulletin->input->clean_array_gpc('r', array(
'do' => TYPE_STR,
'action'=> TYPE_STR,
'done'=> TYPE_STR)
);

if ($vbulletin->GPC['do'] == 'nextstep'){
if (empty($vbulletin->GPC['action'])){
define('CP_REDIRECT', THIS_SCRIPT . '.php');
} else {
define('CP_REDIRECT', THIS_SCRIPT . '.php?step=' . $vbulletin->GPC['action']);
}
print_stop_message('redirecting_please_wait');
}This effectively puts the $_REQUEST['do'] into the GPC, thus removing the need for the call to any $_REQUESTs. Of course, if you are only using the $_REQUEST['do'] to navigate through your script and not calling anything else, then you can leave the $_REQUEST calls and it will remove some overhead according to KirbyDE when I asked basically the same question.

[Kadence]

The parameters for the print_forum_chooser() function in /includes/adminfunctions.php have changed.

Old (vB 3.0.7):
function print_forum_chooser($name = 'forumid', $selectedid = -1, $topname = NULL, $title = NULL, $displaytop = 1, $multiple = 0, $displayselectforum = 0)

New (vB 3.5 Beta 3):
function print_forum_chooser($title, $name, $selectedid = -1, $topname = null, $displayselectforum = false, $multiple = false)

The $title parameter has moved from the 4th parameter to the 1st, $displayselectforum and $multiple have swapped places, and the $displaytop parameter has been deleted.

[MrNase]

It took me a while to figure out:


$id = intval($_REQUEST['id']);


has become:


$vbulletin->input->clean_array_gpc('r', array(
'id'=> TYPE_UINT
));
$id = $vbulletin->GPC['id'];

[Andreas]

$id is empty because you must use $vbulletin->GPC['id'] :)

Btw: For just one variable, it doesn't make too much sense to use clean_array_gpc().

[MrNase]

I edited my above post to add another example so that someone who's as stupid as me understands it :)


vBulletin provides this functions so I'll use them ;)

[Andreas]

Easier approach & less overhead:

$id = $vbulletin->input->clean_gpc('r', 'id', TYPE_UINT);

[MrNase]

Thank you :)

One should edit the first post of this thread and add all usefull information :)

[MrNase]

What happened to $_FILES ?

What would this code look like:

$imagesize = getimagesize($_FILES['src']['tmp_name']);

[Marco van Herwaarden]

You would be using clean_gpc with a 'f' as the first parameter.

[Erwin]

Easier approach & less overhead:

$id = $vbulletin->input->clean_gpc('r', 'id', TYPE_UINT);


Interesting. :)

[RaidenDAWG2]

These new globalize things are driving me nuts here.

I used to have something that looked like this in 3.0.x...

if(isset($_POST['do']))
{
$do=$_POST['do'];
}
if(isset($_GET['u']))
{
$spammerid=$_GET['u'];
}
elseif(isset($_POST['u']))
{
$spammerid=$_POST['u'];
}
if(isset($_GET['t']))
{
$threadid=$_GET['t'];
}
elseif(isset($_POST['t']))
{
$threadid=$_POST['t'];
}
if(isset($_GET['p']))
{
$postid=$_GET['p'];
}
elseif(isset($_POST['p']))
{
$postid=$_POST['p'];
}


Pretty standard $_GET/$_POST structure that reads in either the get or post based on which step it is (it's a spam killing type thing, pops up a window with some options to confirm, then submits and does its thing).

So in trying to convert it over to 3.5 RC1, I tried this...

$vbulletin->input->clean_array_gpc('g', array(
'do' => TYPE_STR,
'u'=> TYPE_INT,
't'=> TYPE_INT,
'p'=> TYPE_INT)
);
if(isset($vbulletin->GPC['do']))
{
$do = $vbulletin->GPC['do'];
}

if(isset($vbulletin->GPC['u']));
{
$spammeruserid = $vbulletin->GPC['u'];
}

if(isset($vbulletin->GPC['p']));
{
$spammerpostid = $vbulletin->GPC['p'];
}

if(isset($vbulletin->GPC['t']));
{
$spammerthreadid = $vbulletin->GPC['t'];
}


So...yeah...where am I going wrong here? Any help you guys can give me would be much appreciated :D

Thanks,
-RD

[Marco van Herwaarden]

I think the shorthand notations get converted to longnames: u->userid, p->post(id)

[RaidenDAWG2]

I think the shorthand notations get converted to longnames: u->userid, p->post(id)

So I should modify my template/code to pass in variables with the longnames (i.e. convert u->userid) instead of the current ?u=x&t=y&p=z format I've got now on the URL?

-RD

[Marco van Herwaarden]

No, if you pass a 'u=..' on the url, i think you will end up with the userid variable, instead of just 'u' in the target script.

[akanevsky]

This should be sticky, plz tyvm.

[Cap'n Steve]

Agreed. This is really the best place to start getting familiar with 3.5.

[Neutral Singh]

Global

$vboptions[] => $vbulletin->options[]



$vboptions[] works in vB3.5.0 too.

[akanevsky]

Thank you :)

One should edit the first post of this thread and add all usefull information :)

One is going to do that today, in a new thread, and the new thread will contain 15x more useful information than that of this thread's first post :)

[akanevsky]

Posted, and I think this threads should be deleted as obsolete. :)

[scotsmist]

A link to the new thread please :)

[akanevsky]

A link to the new thread please :)

https://vborg.vbsupport.ru/showthread.php?t=98047

[FamilyCorner]

I think I've finally found the thread that can solve my problem! :)

I have already made the change for "db" from "DB_site", but this page seems to still be having a problem:
http://www.familycorner.com/forums/contest.php3

You will see if you scroll down to where it says "Posts Today" in a purple box that the total number of posts are missing. This is what the post count is calling from:

<?php
while ($user = $db->fetch_array($users))
{
$username = $user["username"];
echo ("$username<br>");
}
echo ("<br>");
while ($user = $db->fetch_array($admin))
{
$username = $user["username"];
echo ("$username<br>");
}
?>
<br>
</font>
</td>
<td align="center">
<FONT face="verdana,verdana" size="2">
<br>
<?php
$db->data_seek(0,$users);
while ($user = $db->fetch_array($users))
{
$count = $user["count"];
echo ("$count<br>");
}
echo ("<br>");
$db->data_seek(0,$admin);
while ($user = $db->fetch_array($admin))
{
$count = $user["count"];
echo ("$count<br>");
}
?>

What else do I need to change from the old version code to update it to work on 3.5.1?

THANK YOU!