vBulletin sessions are accessible throughout the application using the $vbulletin->session object. Session variables are stored in $vbulletin->session->vars as an array, so accessing something like the useragent associated with the session is as simple as:

$useragent = $vbulletin->session->vars['useragent'];
echo $useragent;

The above example in my case would output “Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0”

vBulletin stores session data in a rather unique way. Each session variable is associated with a column on the session table in the database. This means if you want to extend the session to store some new information, you’ll need to alter the table to add your new columns. My Product already has an install script, so I’ll add it there, but you could also add it manually by running the below SQL statement against your database.

$vbulletin->db->query("
    ALTER TABLE `" . TABLE_PREFIX . "session`
    ADD COLUMN `new_session_variable` varchar(255) DEFAULT NULL;
");

So now we have our new column. How do we write to it you ask? Well the $vbulletin->session object has a method for that unambiguously called set. But we have a problem. We can use the set method to build an array of key => value pairs to write to the database, however the build_query_array method that prepares the values for the insert statement only matches keys based on hard-coded list of column names defined in the class. This means that before we call our set method we need to extend this array to include our new column.

$vbulletin->session->db_fields = array_merge(
    $vbulletin->session->db_fields,
    array(
        'new_session_variable' => TYPE_STRING
    )
);

Notice we’re also assigning a TYPE to this column. This will be used in the cleaning process that validates and prepares the value for the database, so it’s important to get this type right. The method that uses these accepts either TYPE_INT or TYPE_STRING.

Now we’re ready to set our variable. Adding to the script above, we get:

$vbulletin->session->db_fields = array_merge(
    $vbulletin->session->db_fields,
    array(
        'new_session_variable' => TYPE_STRING
    )
);

$vbulletin->session->set('new_session_variable', 'foobar');

Now our session variable is queued up to be saved, but keep in mind that it isn’t in our session just yet. At the end of each page load vBulletin executes a shutdown method that, among other things, executes $vbulletin->session->save() which will actually write this value to the database. On the next page load you’ll be able to access your new variable using $vbulletin->session->vars['new_session_variable'].

Share this article:

If this resonates with you I'd love to help!

I help business with problems like these every day.

Click below to schedule a call.

About The Author

Bryce Hamrick

Facebook Twitter

Bryce Hamrick is an entrepreneur, business & marketing strategist, and product consultant with nearly two decades of experience in industry. Bryce has been a software engineer, product manager, and director of product management for startups as well as large enterprises. He has led teams to bring dozens of products to market and has executed numerous six-figure product launches. Today Bryce and his team focus on leveraging his product execution strategy to help businesses with growth and scale.