How about this?

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

Hm... Actually I think I goofed up somewhere else before. $GLOBALS is working fine now.

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:

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.

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

$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(...))

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.

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).

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.

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:

Now, the code has to be changed to:

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