vBulletin Community Forum - Blogs

vBulletin 4.0 Beta 4 Now Available!

Don Kuramura — Thu, 19 Nov 2009 23:09:53 GMT

We are excited to announce the release the new Beta 4 versions of vBulletin 4.0 Publishing Suite and vBulletin 4.0 Forum. If you have an active vBulletin license, you can download your copy of Beta 4 from the vBulletin Members Area at:
http://members.vbulletin.com .

Beta 4 fixes more than 140 bugs since the release of Beta 3 last week. Thank you everyone who has filed bugs in our bug tracker. If you find a new bug, please continue to file bugs here:
http://www.vbulletin.com/forum/project.php?projectid=6

Highlights of what�s Fixed and New in Beta 4:

(updated) New Posts and Search Results have updated Style.

Fixed Password Protected Forums bug

Fixed Promote to Article bugs

Fixed Ad Manager bugs

Fixed some usability bugs in the Attachment Manager

Fixed Video Players Aspect Ratio to 16:9

Fixed Multi-page comments browsing: Added anchor, comments links, comment page parameters

Fixed the CMS WYSIWYG to better handle images

Fixed Pagination in multi-page articles

(new) Added �Go to Last Post� link to the Recent Comments widget and Recent Forum Posts widget

(new) Ability to allow Not-Registered/Not-Logged-in (Guest) to comment on articles with Captcha

(new) Clicking on an article preview image now links to the article page

(new) Clicking on an image in the article page will bring up the lightbox and display the image in full size

(new) In Section Edit Page, we added a checkbox to limit the articles to display that section�s content only. Also, you can now choose to display/hide the �View All� link.

(new) In Article Edit Page, we added extra article �display settings.� You can now choose to display/hide the article�s title, author, published date, and pageviews.

(new) In Article Edit Page, we added an extra setting to the display the full article on the section page

(new) CMS Articles can now include attachments

Supercharge your vBulletin Forum with Memcached

Dick — Tue, 17 Nov 2009 04:39:19 GMT

There has been a lot of discussion on the forum about static content and caching in vB4, and I got me thinking... 9 out of 10 times when I look at a forum that someone is reporting as "slow", they aren't using memcached. Probably 8 out of those 9 times, enabling memcached solves the problems. It is one of the easiest things you can do to supercharge your forums, especially if you have millions of posts, threads with 10,000+ posts, or are running vBSEO-- and it's already built into vBulletin!

This post isn't a guide to installing memcached. It's not a difficult process, and there already plenty of resources out there that will teach you how to do that. I also assume that there are two types of people reading this-- those with managed hosting and those who manage their own servers. If you're one of the latter, you should be able to figure it out. If you're one of the former, call your hosting company and tell them you want memcached installed and configured to run with php. They'll know what you're talking about. If they don't, you should probably switch hosts.

Also, this is primarily for UNIX servers, however there is a port of memcached for Windows. I just haven't used it before, so proceed at your own risk.

Getting Started

The first thing you'll need to do is make sure that memcached is running. If you have shell access, type the following:
Code:
$ ps ax|grep memcached
You should get back something like this:

9101 pts/0 S+ 0:00 grep memcached
17541 ? Ssl 15:07 memcached -d -p 11211 -u nobody -c 1024 -m 64

The second line tells us that memcached is running. The first line is just us looking for it running. If you don't see that second line, then you've got to have memcached installed. [edit: this actually means that memcached isnt running, not that it isn't installed.] Once you know that memcached is installed, we need to make sure that it is working with php. For those without shell access who weren't able to verify that memcached was running, this will pretty much get you up to speed.

Create a file called memcached-test.php on your server that has the following contents:

PHP Code:

$memcache = new Memcache; $memcache->connect('localhost', 11211) or die ("Could not connect"); echo "Server's version: {$memcache->getVersion()} "; $tmp = new stdClass; $tmp->string_attribute = 'testing'; $tmp->string_attribute = 123; $memcache->set('key', $tmp, false, 10) or die ("Failed to save temporary object at memcache server"); echo "Data from the cache: \n"; print_r($memcache->get('key')); ?>

Your output should be something along the lines of:

Server's version: 1.2.6
Data from the cache:
stdClass Object ( [string_attribute] => 123 )

If you get errors, then you should not proceed until your host has properly configured memcached. If you got output similar to the above, you should be ready to rock and roll. The first thing you're going to need to do is figure out what port memcached is running on. It's usually 11211, but you might want to make sure. In your admincp, Look for "View PHP Info" under the "Maintenance" section. Search that page for "memcache.default_port" and write down that value.

Enabling Memcached

You're now ready to edit your config.php file. Please, back up this file before you start editing it. Around line 135 (in a brand new 3.7.4 config.php file at least) you will see a commented out section entitled "DATASTORE CACHE CONFIGURATION". This is where we're going to configure memcached. Find the section that looks like this:

PHP Code:

/* $config['Datastore']['class'] = 'vB_Datastore_Memcached'; $i = 0; // First Server $i++; $config['Misc']['memcacheserver'][$i] = '127.0.0.1'; $config['Misc']['memcacheport'][$i] = 11211; $config['Misc']['memcachepersistent'][$i] = true; $config['Misc']['memcacheweight'][$i] = 1; $config['Misc']['memcachetimeout'][$i] = 1; $config['Misc']['memcacheretry_interval'][$i] = 15; */

The first and last lines there (the /* and */) are what is commenting out that section. We are going to remove those. Also, check that the 'memcacheport' setting is correct-- make sure that it's the same value as what you got from viewing the PHP info. If your site is using one server (other than an external db server), this is more than likely all you need to do. You can save your config.php and check to see that your site is still up. If your site is using more than one server, you should set up memcached to use pooling.

To set up memcached to use pooling, you first need to know the IP's of each server. Your host should be able to provide you with this information. You can also use host names, but let's just keep this simple for now. Then, you want to copy the memcached settings from "// First Server" to the closing comment so that it looks like this:

PHP Code:

$config['Datastore']['class'] = 'vB_Datastore_Memcached'; $i = 0; // First Server $i++; $config['Misc']['memcacheserver'][$i] = '111.111.11.111'; // ip of the first server $config['Misc']['memcacheport'][$i] = 11211; $config['Misc']['memcachepersistent'][$i] = true; $config['Misc']['memcacheweight'][$i] = 1; $config['Misc']['memcachetimeout'][$i] = 1; $config['Misc']['memcacheretry_interval'][$i] = 15; // Second Server $i++; $config['Misc']['memcacheserver'][$i] = '111.111.11.222'; // ip of the second server $config['Misc']['memcacheport'][$i] = 11211; $config['Misc']['memcachepersistent'][$i] = true; $config['Misc']['memcacheweight'][$i] = 1; $config['Misc']['memcachetimeout'][$i] = 1; $config['Misc']['memcacheretry_interval'][$i] = 15; // Third Server $i++; $config['Misc']['memcacheserver'][$i] = '111.111.11.333'; // ip of the third server $config['Misc']['memcacheport'][$i] = 11211; $config['Misc']['memcachepersistent'][$i] = true; $config['Misc']['memcacheweight'][$i] = 1; $config['Misc']['memcachetimeout'][$i] = 1; $config['Misc']['memcacheretry_interval'][$i] = 15;

The only other setting that that you might be concerned with here is the 'memcacheweight' setting. This is a relative number to allow you more closely control what servers are handling the memcached load. If we set the second server's 'memcacheweight' to '2', while the other servers' were set to '1', then that server would take twice the memcached load than the first two. This is handy when you have multiple servers that don't have the same amount of memory.

After you save your config file, you should immediately go to your forum to make sure that it's still up. If something is configured wrong, you'll see a white page with an error at the top. If the forum is still up, you're in good shape. Just to be sure, I usually log into the shell, run 'top', and look for memcached to show up on the list. This just tells me that it's doing something. If your forum runs vBSEO, you should log into the control panel and enable memcached under the 'Caching Options'. Please note that vBSEO requires a more recent version of memcached than vB does.

Note: After reading through this post, it really sounds like this is a difficult process. It honestly isn't. I considered making a dumbed down "John Wayne's Guide to Configuring Memcached", but decided against it. For anyone who is gutsy, you can probably figure out what I'm talking about and try it that way, although I wouldn't recommend it.

How-To: Beginners Guide to Creating a vBulletin 4 �Test� Environment

IBxAnders — Mon, 16 Nov 2009 21:29:17 GMT

Tutorial written by Pritesh Shah & Michael Anders

So you've finally got your hands on the shiny new vBulletin4 and you are ready to upgrade your forum. But wait! Before you upgrade � how do you test to make sure everything will work? This guide will show you how to create a vBulletin4 �Test� environment without breaking your �Live� forum.

Important Notes:
As always, please proceed at your own risk. While some of the general steps and advice are applicable to a Windows-based web hosting environment, this guide assumes that you have �shell access� on a Unix-based web host. �Shell access� is command line access to your site � and you will notice that we'll provide you with helpful Unix commands to complete various steps.

General Overview of the Process

Copy all vBulletin files from the �Live� site into the �Test� directory

Create a new Mysql database for vBulletin4 upgrade

Create a copy of your current �Live� database

Restore the database copy into the new vBulletin4 database

Edit vBulletin 3 configuration file

Validate vBulletin 3 test environment

Upload vBulletin4 files

Upgrade your �test� forum

Test your forum on vBulletin4 in the �Test� directory

Technical How-To Guide & Steps

(SHELL) Log in and Find Current Document Root
First, lets log into the web server and find where your current vBulletin 3 site lives. Access your server by using your favorite �terminal� client and navigate into your site's root directory via shell access. Your document root directory may look something like:

/var/www/html/domain.com/

Tip: You can navigate through your file system by using commands like:

cd
ls
dir
pwd � shows your current location within directory tree

At the end of this step you should be located inside your web document root directory, in our example we use /var/www/html/

(SHELL) Create a new directory for vBulletin4 upgrade test.
In our example we ran the following command:

mkdir vb40

and created the following directory structure in our document root:

/var/www/html/vb40

(SHELL) Copy vBulletin 3 Files into vBulletin4 Test Directory
While located in web document root directory /var/www/html we execute the following command:

cp -R /var/www/html/vb375/ /var/www/html/vb40/

Please note that we assume that your live forum is located in a directory called �vb375�; in reality � your forum could be located in the web document root directory itself or located in a directory named �forum�. This means that you'll have to modify the command above to work with your directory structure. Please note that the trailing slashes ( / ) are important!

After this step is complete you should have an exact copy of your vBulletin 3 files and directories inside the brand new �vb40� directory.

(SHELL) Log Into Your MySQL Server
Log into mysql server by executing the following command, please note that you will need to know your mysql database username and password. Check with your internet service provider if you do not have access to these credentials.

mysql -u'vb40dbusername' -p'vb40dbpassword'

IF your web host provided you with a separate mysql server ip address use the following command instead:

mysql -h'vb40dbip' -u'vb40dbusername' -p'vb40dbpassword'

Tip: Mysql server user information can be found in the config.php file in vBulletin, located in the forum root /includes/ folder. Please consult your host if you are unable to log into your mysql server.

(MYSQL) Create a New vBulletin4 Mysql Database
Once you've successfully logged into your Mysql server, execute the following command to create a brand new database:

CREATE DATABASE vb40;

Disable the �Live� vBulletin discussion forum
Go to your vBulletin 3 Admin Control Panel, select the vBulletin Options tab on the left and set your vBulletin On / Off option to �No�, not active.

Create Mysql Database Dump and Restore into a New Database
In step #5 you've created a new database called vb40. In this step you will create a �database dump� file of your existing �Live� site and restore it into the new database. In essence, you will create an exact copy of your database so that you can safely upgrade this copy to vBulletin4. Please note that you will need to know the database name, username and password for your current vBulletin 3 database. The username and password is most likely the same one you've used in step #5.

Once you have all of the information, execute this command in your shell:

mysqldump -uvb375dbusername -p'vb375dbpassword' vb375 | mysql -uvb40dbusername -p'vb40dbpassword' -C vb40

Alternatively, IF your database server is located on a different IP use the following command to include the directive for the database host:

mysqldump -hvb375dbip -uvb375dbusername -p'vb375dbpassword' vb375 | mysql -hvb40dbip -uvb40dbusername -p'vb40dbpassword' -C vb40

Turn ON �Live� Site
Now that you've made an exact copy of your �Live� vBulletin 3 database; let's go ahead and turn ON the �Live� discussion forum. Again, go to your Admin Control Panel and set the vBulletin option ON/OFF to �On�.

Activate the �Test� vBulletin3 Site
In step #3 you've created a mirror copy of your vBulletin 3 forum directory in the following location inside a directory called �/var/www/html/vb40/�. In step #7 you've created a copy of your database. Now, let's edit the config file in the �Test� directory so that it pulls data from the new �vb40� database. To do this:

Edit �config.php� located in the �Testing� directory /var/www/html/vb40/includes/; change the �Database Name� to �vb40�.

Test the vBulletin 3 �Test� Installation
Go to your web browser and access the �Test� directory by visiting the �/vb40/� URL; example,

http://www.mydomainname.com/vb40/

If the process was successful you should now have 2 identical vBulletin 3 installations; one is your current �Live� discussion forum and the additional �Test� instance located in the /vb40/ folder.

Please note; that your �Live� vBulletin site was turned ON; and your �Test� installation was turned �OFF� - this is a good way to make sure they are using different databases. No new posts or users online should be observed on the �Test� installation. If you are seeing otherwise � you may have confused the database names and incorrectly configured the config.php file. Please go back and make sure this is resolved!

--- Now that you have a copy of your vBulletin 3 site for �Testing�, lets Upgrade to vBulletin 4 Suite!

vBulletin 3 Pre-Flight Check: Disable Products! Check Settings!
Log into the Administration Control Panel in your �Test� installation of vBulletin 3 (in the /vb40 directory) and disable all products; do not disable all products by disabling the plugin system or editing the config.php file. Rather, simply choose �disable� in the product manager menu.

Upload and Overwrite vBulletin 3 Files with vBulletin 4 Suite
Upload and overwrite all of the vBulletin 3 files in the /vb40/ folder with the new vBulletin 4 files package. Please make sure that you are actually overwriting the existing files and not just creating new files.

Execute vBulletin 4 Suite Upgrade Script
Run the vBulletin 4 Upgrade script by executing upgrade.php file located in the newly created �install� directory.

Example: http://www.mydomain.com/vb40/install/upgrade.php

Test vBulletin 4 Suite
After the vBulletin 4 upgrade script successfully completes, you can begin playing around with the new vBulletin 4 Suite installation located in the /vb40/ �Test� directory.

Please note that at this point you should have 2 vBulletin installations, the first is your �Live� site and the second is your vBulletin 4 Suite �Test� environment.

Additional Tips:

If you are unable to log into your �Test� installation's AdminCP you may have a problem with your cookie path / domain. If this is the case; upload tools.php file from your vBulletin 4 �Do Not Upload� directory. Execute the file to edit the cookie settings.

Using custom templates within your own vBulletin 4 based files

David IB — Mon, 16 Nov 2009 19:04:50 GMT

Custom Templates
If you create custom vBulletin based files that utilize custom created templates within your forum installation, there are a few tricks to get them to work with vBulletin 4. Prior to vBulletin 4, you were able to use the following code to get vBulletin to evaluate the custom template for your script.

eval('print_output("' . fetch_template('myCustomTemplate') . '");');

With vBulletin 4, the same thing can be accomplished with the following two lines of code.

$templater = vB_Template::create('myCustomTemplate');
print_output($templater->render());

This code will now allow you to reference vBulletin 4 functionality to use your custom template within your custom vBulletin PHP file.

Example
Imagine that yourcustom vBulletin PHP script simply outputs the words "Hello there" and you want that text to appear within your own custom vBulletin template. Your file would have the following somewhere within the code.

$myScript_variable = "Hello there";

Within your custom template (called myCustomTemplate as an example), you would reference this variable as follows.

{vb:raw myScript_variable}

Back within your script, you can make a call to force your custom template to be evaluated. This would be accomplished using the previously example.

$templater = vB_Template::create('myCustomTemplate');
print_output($templater->render());

Pushing your variables to vBulletin 4 templates

David IB — Mon, 16 Nov 2009 19:03:11 GMT

Prior to vBulletin 4, you could reference your plugin variables within the templates without any extra necessary work. Say you wanted print out the words "This is my plugin" within the template header. The following code (with the correct plugin Hook Location) would allow you to do that.

$myplugin_output = "This is my plugin";

$myplugin_output would then be referenced within the appropriate template.

With vBulletin 4, a little extra work is necessary to get your custom text to appear within your forum. You must now reference which templates you want to push these variables to or vBulletin will ignore them completely.

If you wanted to reference this variable within the template header, you would need to include the following somewhere within my plugin code after the variable was set.

vB_Template::preRegister('header',array('myplugin_ output' => $myplugin_output));

If you wanted to push this variable to multiple templates, you would need to include multiple versions of this line within your plugin. For example, if you wanted to push this variable to your FORUMHOME template in addition to header, you would need to add the following lines to your plugin code.

vB_Template::preRegister('header',array('myplugin_ output' => $myplugin_output));
vB_Template::preRegister('FORUMHOME',array('myplug in_output' => $myplugin_output));

If you wanted to reference multiple variables within one template, you would just add to the existing array.

vB_Template::preRegister('header',array(
'myplugin_output' => $myplugin_output,
'myplugin_output' => $myplugin_output2,
'myplugin_output' => $myplugin_output3,
);

Back to Part One: http://www.vbulletin.com/forum/entry...etin-templates

Getting Started with CMS Documentation Files (PDF)

Don Kuramura — Sat, 14 Nov 2009 21:49:50 GMT

To help accelerate learning and mastering the CMS features in the vBulletin 4.0 Publishing Suite (beta 3) product, we put together an updated set of "Getting Started with CMS" documentations.

There are 5 PDF documents and I think this might be the right order to read them:
1. CMS_Sections.pdf (spilt into 2 pdf files)
2. CMS_Permissions.pdf
3. CMS_Articles.pdf (spilt into 2 pdf files)
4. CMS_Widgets.pdf
5. CMS_Grids_&_Layouts

And if you missed my past blog post on "Skinning your vB4 Forum in 10 Easy Steps", you can go here and download the PDF and example style:
http://www.vbulletin.com/forum/entry...-10-Easy-Steps

These are still working drafts and we will be continue to update them, but in the meanwhile I am hoping this will help everyone get to speed faster.

Thank you for all your help and support.

Don Kuramura

Attached Thumbnails

Referring to plugin variables within your vBulletin 4 templates

David IB — Sat, 14 Nov 2009 01:07:00 GMT

Prior to vBulletin 4, you were able to refer to your plugin's variables exactly as you would refer to them within a standard PHP script. Due to the changes to the way vBulletin's templates work, this is no longer the case.

Once you understand the new vBullein 4 template variable format, referring to your plugin's variables will be simple. Let's take a look at the new variable format by comparing some examples of how they look in vBulletin 3.8.X and vBulletin 4.

Example 1
In this example, we will assume that you have written a plugin that stores its data within the variable $myplugin_output. Using vBulletin 3.8.X, you could simply insert that variable within your templates and have the output display on the site.

Within vBulletin 4, this same variable from your plugin would now be referenced as follows.

{vb:raw myplugin_output}

Within vBulletin 4, all of the new template variables appear like the above example. The raw portion indicates that this is a raw variable and the translation between $myplugin_output and {vb:raw myplugin_output} occurs automatically.

Remember, you must still reference this variable as $myplugin_output within your plugin. It is only within the templates that the same variable needs to be referenced in the new format.

Example2
Say you store your variables as an array and one output variable within your plugin looks like $myplugin_var['output1'] or $myplugin_var[output1]. These variables are handled in the same way but with a slight variation. The following is how this same variable would be written within a vBulletin template.

{vb:raw myplugin_var.output1}

Again, you are using a raw vBulletin 4 variable. This time, the key within your array variable is called after the array name and the two are separated by a period. So these types of variables always follow the following format.

$arrayName['key'] translates to {vb:raw arrayName.key}

It's that simple. Once your get the formatting down, you will be able to reference your plugin variables without any issues just as you were able to within prior versions of vBulletin.

Part Two: http://www.vbulletin.com/forum/entry...s-to-templates

vBulletin 4.0 Beta 3 - Now Available to Pre-Sale Customers

Don Kuramura — Fri, 13 Nov 2009 03:23:19 GMT

All of us at vBulletin are pleased to announce the release of vBulletin 4.0 Publishing Suite Beta 3 and vBulletin 4.0 Forum Beta 3, our first public beta release of vBulletin 4.0. We�re extremely excited about hitting this milestone, and we know many of you can�t wait to get your hands on the product and start playing around with it.

Beta 3 is available to all vBulletin 4.0 pre-sale customers. If you�re a pre-sale customer, you can download your copy of Beta 3 from the vBulletin Members Area at: http://members.vbulletin.com/

Since the launch of Beta 2 on vBulletin.com, we�ve fixed more than 100 bugs thanks to valuable feedback from our customers and hard work on the part of our developers. Please keep the feedback coming as you explore Beta 3.

We also want to say a huge �thank you� to all of our vBulletin 4.0 private alpha and beta testers. Their contributions were crucial in bringing you the product we have for you to test today. You guys rock!

Go here to find some FAQs about Beta 3:
http://www.vbulletin.com/forum/showt...nses&p=1838067

In the meantime, enjoy exploring vBulletin 4.0!

Challenges in Curating and Publishing Content Online

chrisholland — Thu, 12 Nov 2009 11:43:17 GMT

First there was the L.A. Times, and news you consume while sipping coffee on a Sunday morning. Then LATimes.com. Much later, Forums and Blogging came around, and the Web blew-up, millions of voices came online, writing their own articles, cultivating myriads of micro-audiences, many of them growing to online publishing powerhouses.

Somewhere in that time-frame social networking also blew-up. Friendster. MySpace. Facebook. Then micro-publishing with Twitter. And statuses everywhere. People and content are everywhere, interconnected, closer.

All this has so-far left us with the following main categories of content sources:

Purely editorialized destinations such as CNN.com

Blogs

Forums

The first category strives to provide quality content with paid writers, without emphasis on community-contributed content. They claim and strive to "cover" stories, not merely "opine on topics". While the line is blurry, they've attained credibility, they're part of The Press, their web sites have fancy layouts, sections and categories. Readers aren't typically invited to "Comment" and among the few who do allow comments, this feature is typically executed as an "add-on" several clicks away. In this model, Content is unidirectional: Writer writes, readers read.

Blogging has opened the doors for the little guy to voice an opinion while fostering an open-dialog with readership in the form of Comments closely tied to a Post. A blog typically revolves around a Person or Voice and a set of Interests. Bloggers have for years challenged mainstream media in their coverage of events in timeliness and comprehensiveness. TV and Newspapers find themselves referencing and incorporating bloggers in their coverage. Part of this Blogger's edge flows from agility afforded by their open bias and their rapid-publishing model, as well as their ability to leverage content and feedback from their readership and fellow bloggers. In the blogging model, Content is bidirectional: Writer writes, readers write-back.

Forums have for over a decade grown into the ultimate source of timely information on a wide variety of topics revolving around a Niche Interest, powered by many Voices. Content flows from a collaborative and conversational model. Questions and Answers. Debates. There are no "second-class" contributors, in fact, a Thread Starter Post rarely contains the most interesting information, it's all in the conversation that ensues. All replies are equal. In this model, Content is omnidirectional: Many writers are constantly writing, readers are writers.

These models all have advantages and drawbacks.

While you've come to enjoy and trust the structured, consistent and reliable flow of quality event coverage coming from an editorialized site, you'll often find yourself wishing you could offer your opinion on an article to other readers.

While a certain Blog may have given you a lot of interesting and useful information for a while, you might find yourself yearning for some variety of opinion on a given topic as you start looking around for other bloggers or simply flee to a Forum.

After having enjoyed the variety of information and opinion on a Forum, you're finding yourself struggling with the vast amount of information, constantly wandering from one topic to the other while having the sneaking suspicion that someone somewhere is writing a very interesting post and you're not seeing it!

Beyond the drawbacks of each Content model, it's typically hard for a Publisher to explore which fits them best without wedging themselves into a platform slanted toward a specific model. While transition is always possible with modules, add-ons, plug-ins or full-fledged migrations, the process is typically painful, costly and time-consuming.

It's time for a publishing platform to keep your options open while enabling you to explore, blend and leverage those models.

It's time for Facebook addicts to graduate from the "friend of a friend" model, by meeting interesting new people on your site around the niche interest they share: the DNA for true social networking.

It's time to evolve way beyond Forums. It's time to graduate your Moderators from the "Content-Filterers" they currently are, to the "Content Curators" they could become. it's time to break valuable Content from its paginated forum shackles right onto the front-page. It's time to reward your most prolific users with prestigious links back to their profiles from the article, so they might connect with more users who are interested in their writing. And what better way is there to nurture their writing, than with a welcoming Blogging home?

it's time for a publishing platform to give you the tools you need to enable, foster and reward a culture of Great Content.

It's time.

New CMS Tutorial: Managing Sections and Content

Don Kuramura — Wed, 11 Nov 2009 20:50:01 GMT

Since the new CMS went up on vBulletin.com last Friday, we've received a ton of great initial feedback. We're reading every comment and taking everyone's input into consideration as we tweak the CMS. Thanks for the great response, and please keep the suggestions coming!

One theme we're seeing in the feedback is that people are finding our CMS tutorial articles valuable as they explore the CMS. I've just created a new tutorial article on Managing CMS Sections and Content. This article describes the various section features and attributes, including:

- Setting a unique style and layout for each section
- How to change the number of columns the articles will be displayed
- How to set section links on the top navbar
- How to manage which content to display for each section.
- Managing all the content assigned to a section and its sub-sections

You can check out the article here:
http://www.vbulletin.com/forum/conte...on-and-Content

We also held our first Developer Chat yesterday evening, and got a great response. We plan to continue these chats on a regular basis. If you weren't able to join the chat live, you can find a transcript at: http://www.vbulletin.com/forum/showt...Developer-Chat

Finally, some of you have asked for some more information about the vB team. Here's some background on me in case you're interested:

In my role as Director of Product Management for vBulletin, I oversee all aspects of the vBulletin product development process. I have quite a bit of experience in software, web, and mobile product development, and I'm having a blast applying my multi-platform skills to the vBulletin environment.

Before joining vBulletin, I worked at both big companies and small start-ups. At Sony Pictures Digital Entertainment, I was the Director of Product Development, where I oversaw global mobile product development working on mobile games with brands like Spider-Man 2, Wheel of Fortune, Jeopardy, Snoop Dogg, and the New York Times. At American Greetings Interactive, I was the VP Product Management, where I headed all mobile, instant messaging, and social networking products. As an entrepreneur, I co-founded a company that developed social applications on the Facebook platform, and in 1999 I founded a company that designed innovative new toys for Mattel. I have a B.S. and M.S. in Electrical Engineering from UC San Diego and also have a patent in multimedia databases.

We're all looking forward to the Public Beta release later this week! Stay tuned for more information.

CMS Update

Don Kuramura — Fri, 06 Nov 2009 22:45:38 GMT

Just wanted to give a quick update on the CMS features of the vBulletin 4.0 Publishing Suite. We just launched the CMS on our site. Check it out at:http://www.vbulletin.com/forum/content.php

You are going to see a sample site with multiple sections, categories and content created with our CMS. We are still trying out different layout and content. It would be great to hear suggestions from the community about what type of content they would like to see here. In fact, we may elect “editors” from the community to publish new articles.

For today, most of the content on the site is “lorem ipsum” articles with some of random photos. But on the homepage, I created 3 sample tutorial articles that I think will be helpful:

1. A visual guide of the various elements on the page.
http://www.vbulletin.com/forum/conte...-Read-me-first

2. An article that visually explains the steps to create an article. This gives you a better sense of features available when publishing content.
http://www.vbulletin.com/forum/conte...-a-New-Article

3. Description of the new “Promote to Article” feature.
http://www.vbulletin.com/forum/conte...rom-the-Forums

I will continue to publish more documentation of the CMS features here.

To demonstrate some of the layout and customization features, on each section you will see different page layouts, content layouts, and various built-in widgets and also 3rd party widgets (i.e. Google Gadgets). Of course, all of this is totally configurable by the admin.

To promote more content discovery across the entire site, you will see on the homepage right sidebar, three widgets:
- Recent Forum Posts Widgets
- Recent Blog Entries Widget
- New Article Comments

This is still beta and you will continually see the CMS UI designs, UX, and features evolve until we launch. In fact, the screenshots on vbulletin.com site is already old and need to be replaced. Some examples of recent changes as of this morning:
- The Section Navigation Widgets and Category Navigation look incredibly better.
- The Category Widget now displays the number of content in that category.
- We were now able to display the video player with the Article Preview on Section Pages.
- Updated and created new icons.
- The Recent Comments widgets now display avatars.

With all that said, take a look and we welcome suggestions and feedback.

Cheers,

Don

Our Vision for vBulletin

bbrisco — Mon, 02 Nov 2009 20:38:51 GMT

As we continue to introduce to our new vBulletin 4.0 Publishing Suite, we would like to share our broader vision and answer some questions about where we are headed.

First, our vision. We believe that both content and community are king. Launched in 2000, vBulletin has grown to become the leading and most powerful forum management software in the world, with considerably more than 100,000 copies sold. If you combined the traffic of all vBulletin sites, they would easily rank in top ten largest sites globally�roughly same the size as Wikipedia in terms of unique visitors.

We take pride in the success of our customers as they build some of the leading websites in the world.

But we feel this is only a start. To bring vBulletin to the next level, we are investing heavily. Over the last year, we have doubled the number of developers working on the product�and they are a very talented group. You should expect a much faster pace of development�and more exciting new features.

To focus our efforts, we continue to do research with vBulletin community owners and webmasters. We find that many of the most successful sites want to become more significant content publishers. This is because many communities that started as simple discussion forums have grown into powerful databases of knowledge and content� true leaders in their areas of expertise.

These site owners tell us they want simple, but powerful tools to manage articles, blogs, and all manner of content�all in one publishing platform. The new vBulletin does this elegantly. And by fully integrating with our forums, we believe that our new Suite uniquely captures the power of community and content in a single platform.

This doesn�t mean that we have slowed investments in forum functionality. To the contrary, we continue to invest heavily in the core forum platform and the new product includes some important new features. In our research, vBulletin site owners tell us that in addition to content management, they want tools to help with such activities as: advertising monetization, SEO, site analytics, and mobile.

While we have made some changes in vB 3.8 and vB 4.0 along these lines, many of those changes are ahead for the vB 4.0 series. In subsequent posts from our staff you will learn more specifics about our vision in these areas, in addition to our plans about more content management features, and more enhancements to forum and blog functionality.

You may have noticed that we�ve priced vB 4 products to strongly encourage adoption of the Suite by offering a much larger discount on the Suite. This is very intentional. We now view vBulletin Publishing Suite as our core product. As we add new functionality, it will continue to be fully integrated with the Suite.

You may have also noticed that we�ve finished migration of vBulletin development from the U.K. to California. We have deep respect for the wonderful heritage of vBulletin.
The primary reason for the move was the availability of pools of technical talent and proximity to the resources of our parent company.

We are occasionally asked about the role of Internet Brands as the parent of vBulletin. For instance, how important is vBulletin to Internet Brands? The answer is: very important. Internet Brands is the largest operator of vBulletin sites in the world. We deeply care about the software and will continue to invest heavily in its development. Internet Brands brings far more resources to the ongoing development of vBulletin.

We are also asked: how do we view certain vBulletin sites that compete with Internet Brands sites? The answer is: we manage vBulletin for its own success and we view those sites as valued customers. vBulletin thrives as its own community continues to grow. Internet Brands websites must compete on their own and receive no �special treatment�. Even where we compete, we are all in this together. It�s a big world.

In closing, we are extremely confident about vBulletin�s continued growth and success. We are grateful for your wonderful support. And we have enormous excitement about the road ahead for us all.

Coming Soon: Forum and Suite Beta

Joe Rosenblum — Sat, 31 Oct 2009 01:13:34 GMT

First, a huge thank you for all the great feedback on the 4.0 product from both the Alpha group and customers on vBulletin.com.

vBulletin 4.0 is right around the corner and we're eager to deliver it to you as soon as possible. To that end, we've decided to release a Beta version of Forum and Suite. If you have access to download Forum 4.0 or Suite 4.0, expect the Beta to be available in the member's area no later than mid-November.

And stay tuned in as next week we'll launch the Publishing Suite on vBulletin.com!

Part 1 vB4mance: Helping communities grow, performance data model changes in vB 4.0

IBxAnders — Tue, 27 Oct 2009 02:26:12 GMT

The new vBulletin 4.0 boasts a lot of new changes such as CSS-friendly styles, multi-content search and other various new features. The biggest improvement in vBulletin 4.0, however � is well hidden under the hood and it is the actual changes to the database storage mechanism. While there are exceptions, this change improves the way vBulletin sites scale upwards to serve more visitors and more content without sacrificing performance. As a preface to my blog post, allow me to please explain its purpose. I'd like to very simply describe the database processes and the problems that the average forum owner is facing. I'd also like to explain the basic solutions to these problems. Furthermore, I'd like to discuss this in the context of exciting changes coming in vB 4.0. I also further understand the problem, and I realize that this change is not a complete solution to the problems that large forums are facing, but it is a really good and exciting step in the right direction towards helping vBulletin perform better.

Let's talk Simple Database Server Mechanics:
In an average installation, vBulletin typically stores data in only one database, while it uses many different tables inside that database to store different sets of data. For example, user information is stored in a table called �user�, and post text is accordingly stored in a separate table called �post�. When a new thread is added, or a reply to a post is made, a new �row� is created in these database tables to store the additional information. When a visitor wants to read a thread, they click on a link sending the database server a command to query the various database tables and show the specified results. An average active discussion forum could be seeing hundreds of these queries per second.

Defining the General Database Problem and Errors:
As your discussion forum grows, you will notice that your hosting requirements may change drastically. As the user activity on your forum increases, so is the amount of data collected in your database. In turn, as the physical size of the database increases the server uses more and more hardware resources to service each individual request, such as displaying a thread or adding a new reply. When the server becomes overwhelmed with requests it starts taking a longer time to service each query, this starts a chain reaction where even the simplest of queries aren't being serviced; this condition is called �Locked�. The best way to visualize the �Locking� issue is to imagine a road traffic jam. This problematic condition manifests itself via MySQL error messages and general site slowness. It's believed that upgrading to a better web host (ie. Dedicated server) would resolve the performance issues; and while it's generally good advice � the reality is that upgrading to a better host only increases the safety buffer before the errors will occur again. In our example of a traffic jam, a server upgrade will increase the amount of travel lanes � but the traffic jam is still possible, even though more cars are able to travel. This traffic jam condition is not exclusive to vBulletin, but rather to a default implementation of MySQL; let's further examine the problem by talking about the Search function.

Taking a Closer Look at �Search�
Let's drill down and examine the search functionality in vBulletin 3. Earlier, we talked about the �thread� and �post� tables in the forum database. When a forum user executes a search, a query is issued that checks the �post� and �thread� tables for availability of the specified keywords. This process is very intensive and it uses an internal MySQL function called �fulltext� database search. Both the �thread� and �post� tables have an index that speeds up this process, something that resembles a table of contents in a book and it's called a �fulltext index�. While this search process is happening, the database server has much less resources dedicated to serving other queries (reading and especially writing). Depending on server capacity, activity level and the size of your post table, a single simple search can cause the aforementioned traffic jam condition and bring your forum down.

Examining the Search Issue and Solutions
Currently, the most common approach to scaling a vBulletin forum to handle the load is to avoid the traffic jam condition entirely. Lets evaluate the root cause of the problem.

Issues can be found in the mechanism storing and retrieving the data inside the database tables; this storage engine is called �MyISAM�. When a database request is made on a specific table (specifically the �write� query), the MyISAM engine temporarily �locks� the specified table briefly making it unavailable to all other requests. This means that given the typical conditions while it's searching through the larger tables such as �post� all other requests are quickly queuing as well, creating the traffic jam condition, in turn spewing database errors and slowing down the site.

The solution to �table level locking� in MyISAM is as simple as converting the database table engine to type �InnoDB�. At a first glance, InnoDB is very similar to MyISAM; the main difference being that unlike MyISAM engine, InnoDB uses �row level� locking, whereas the specific table is never locked completely and is always available to service all other requests. This means that when an expensive search query is executed and and/or writing occurs, the �post� table does not lock and delay all other requests from successfully completing.

InnoDB - The important difference between vB 3.x and 4.0
The main problem is that InnoDB does not support �fulltext� searching; this means that converting to InnoDB will break the default search engine in vBulletin 3. This is due to InnoDB requiring that �fulltext index� be dropped when the conversion occurs. No full text index, no search; it's as simple as that. Currently, the solution is to use a third-party search engine such as Sphinx. vBulletin 4 data model tackles this problem head on by redesigning the search engine functionality by no longer relying on a fulltext index in the �post� and �thread� tables and giving the flexibility of optimization without sacrificing the search.

Database performance changes in vB 4.0
As I've mentioned in the beginning of my blog post � what's really cool in vBulletin 4.0 is not necessarily apparent to the untrained eye. Previously, vBulletin utilized the fulltext index on both �thread� and �post� tables making optimization and server problem resolution very expensive and complicated. vBulletin 4.0 no longer needs the fulltext index to be present in either of the �thread� or �post� tables. This means that vBulletin 4.0 database can utilize the InnoDB table engine and prevent a lot of common database issues associated with locked database queries. This is great news for small to medium board owners who will be able to resolve some performance overhead problems without having unnecessary expenditures for expensive hosting or complicated third-party search engines.

What else is new?
Another cool update in vBulletin 4.0 are the new indicies that it builds on tables such as thread and post that further optimize database performance. This is especially beneficial to forums with �long� threads where replies could reach well into the thousands.

Stay tuned for a detailed guide to InnoDB converting vBulletin 3.8 and 4.0.

Dear vBulletin Developers...

Joe Rosenblum — Fri, 23 Oct 2009 22:35:22 GMT

Thanks for your continued support of vBulletin. It's been several years since the last major point release of vBulletin, and through all that time, your energy and enthusiasm have been inspiring to us. With the upcoming release of vBulletin 4.0 Forums and Publishing Suite, we want to re-engage and strengthen the ties between the core vB development team and all of you.

We just publicly unveiled vB 4.0 and there are some great new features, including:

-An awesome, and highly flexible CMS product (unveiling soon!)
-A Great new default theme
-SEO Urls
-Multi-content search capability

Along with some of these consumer facing changes, we've made some major changes to the internals, including:

-Validating XHTML markup
-A new templating system
-A new stylevar system

All in all, we're talking tens of thousands of lines of new and improved code. While this means your old styles will need rework and some of your plugins will break -- we're confident that all the new features and functionality we've added make up for it. Additionally, we have no designs on changing the styles or template system again in 5.0 (yes, we're already planning for 5.0), so you can be confident that your updates will have real longevity.

In addition to initializing this discussion of the developer impact of vB4, I want to take this opportunity to announce three major initiatives for the developer community.

vB 4 Plugin Prize
Starting soon, we'll kick off a contest with a cash prize for the best vB 4 hack or plugin.

Formal Developer Program
In the coming months, we'll unveil a formal vBulletin developer program which will include pre-release access to vB source code.

Monthly Developer Chats
We'll be hosting monthly, moderated live chats with the core developers of vB. The first chat will be 4pm PST on Tuesday, November 10th and will feature Kevin Sours, Lead VB Developer.

More details will be forthcoming for all of these, and we have more exciting plans that we're not yet ready to announce but will be discussing here soon.

Thanks for all your contributions, we wouldn't be here without you,

-Joe

Joe Rosenblum
CTO, Internet Brands, Inc.
www.internetbrands.com
www.vbulletin.com

Update: Submit and vote on questions for our first developer chat here: http://bit.ly/Y1NW0

vB4: Skinning Your Forum in 10 Easy Steps

Don Kuramura — Fri, 23 Oct 2009 22:07:26 GMT

In the spirit of providing more documentation to our customers and developer community, we put together two PDF documents and an example style. The first is "vB4: Skinning Your Forum in 10 Easy Steps." This is a step-by-step guide on how to customize the main areas of your vB4 Forum.

The second document is the vB4 StyleVar Visual Dictionary. The StyleVar (style variable) Dictionary is more of a complementary reference guide aimed at understanding how and where to use each StyleVar for advanced customization. As we finalize the product, I will continue to provide updated versions of these two docs.

Finally, I also included a zip file, "Wave 1.zip" that includes:
1. Image files used in this vB4: Skinning doc.
2. wave-style.xml - if you want to install this new style.
3. install.rtf - instructions on how to install wave-style.

We are currently writing similar documents for customizing the new CMS. Stay tuned.

I hope these documents are helpful and I welcome suggestions.

Cheers,

Don

vB4_Skinning_Forums_Steps.pdf Attachment 37894

Wave 1.0.zip

vBulletin Update #42

Freddie Bingham — Fri, 28 Aug 2009 16:40:23 GMT

I spent quite a lot of the last few months working on the vB4 style. Obviously, there was a lot of HTML to convert to the proper semantic style. Kier converted a lot before he left and I was assisting him in that process.

There was just too much HTML to convert for one person so Alpha is very much an alpha in terms of the style. It is very rough around the edges and usability is being worked on.

A few days ago I added a popup to the editor that allows a video url (youtube, metacafe, etc) to be input, which results in a video bbcode being output. The result is that you can finally embed videos in your posts. The timeframe and requirements did not allow me to include a method by which end users can add their own video services but I'm sure that can be handled in the near future.

At the moment I am working on the asset manager, working on its usability.

Widget Programming

Edwin Brown — Fri, 14 Aug 2009 03:01:08 GMT

Widget Programming

Introduction
This is intended for reasonably experienced PHP programmers with some experience in vBulletin programming. You should have at least a basic understand of the vB templating system and phrasing. If you don�t, I strongly recommend you do some homework before trying to program a widget. I will use as an example the static html widget.

It's very early to be writing this, I know. I can't say exactly when alpha testing will start on the CMS system, which will be part of the suite. Soon, but I'm not in a position to give a date. I've had several requests for more information, so here it is. I've attached a zip file for two widgets- the static html and the rss. This may not be the final code, but it's close.

I've walked through the statichtml widget, because it's the simplest. If you understand that, there are two more things you need to know. You can call $this->content->getNodeId() to get the unique id of the page you are on. This allows you to do things like make navigation widgets that are page-dependent. Neither of these widgets need that. Also, most widgets should be cached. There is a generic caching algorithm- the first parameter is a value or array of values that form a key. vB_Cache::instance()->write and vB_Cache::instance()->read() do this for you.

At the risk of repeating myself, let me explain the hierarchy.

In the CMS system you define grids. Grids divide the page into columns, with optional header and sidebar settings.

Then you create widgets. Widgets are a combination of a widget type (i.e. static html), plus a configuration. If you want ten different Youtube videos, that's ten instances of a statichtml type widget. If you want five different Google gadgets, that's five more instances of the statichtml type.

Then you make layouts. Layouts put the primary content into a grid, and optionally place one or more widgets in specific places. You apply a layout and style to each section (section is the primary organization system in the CMS, but not the only one). All the pages in that section get that layout.

Let's say you wanted to have a form-type widget where users could enter information about each article. You could create your own database table and use that. Or you could use the widget storage we designed. In that case you would want to use a per-page configuration. We haven't written any of those, yet, but the setConfig and getConfig calls will handle per-page configuration.

I don't want to take credit for something I don't deserve. I didn't write the CMS system, but I've been working in it a lot for the last couple months. I think you'll find it powerful and well designed for extension.

Code Example
Files
You will need at least two files. You will need to define a package and class. The package should be something unique. The class can be anything you like, but it�s generally something descriptive. You will need to create the following file structure.

/packages (already there>
/

/item

/content

/

/content

/

Note that we use all lower case file and path names. The static HTML widget has package = vBCms, class=Static. The files are
/packages/vbcms/item/content/static.php
/packages/vbcms/ content/static.php

Database
You will need to create two database entries to use your widget. In the TABLE_PREFIXpackage table you need to insert a record with package= . In the TABLE_PREFIXwidgettype table you need to create an entry with class= , packageid = .

Item/Content file
This file is simple. It�s just for the convenience of the CMS router. You declare a class, and define the package and class. If you have a default configuration setting you should put it here. Here is the file for Static HTML (I�ve removed the comments and licensing.)

if (!defined('VB_ENTRY')) die('Access denied.');

class vBCms_Item_Widget_Static extends vBCms_Item_Widget
{
protected $package = 'vBCms';
protected $class = 'Static';
protected $config = array('html' => 'Enter HTML here.');

}

Content file
This is the file that does the work. You need, at a minimum, to create two functions: getConfigView and getPageView. The first is called to configure your widget, and the second is called to render the view. With most widgets you�ll want to do some caching. For the static html widget it�s one query to get the data, and I couldn�t see executing a query to see if I needed to run one simple query.

Below is the file.

This php file should never be called directly, only from a properly initialized page. This call ensures that.

if (!defined('VB_ENTRY')) die('Access denied.');
licensing

/*================================================= =====================*\
|| ################################################## ################## ||
|| # vBulletin [#]version[#] - Licence Number [#]license[#]
|| # ---------------------------------------------------------------- # ||
|| # Copyright �2000-[#]year[#] Jelsoft Enterprises Ltd. All Rights Reserved. ||
|| # This file may not be redistributed in whole or significant part. # ||
|| # ---------------- VBULLETIN IS NOT FREE SOFTWARE ---------------- # ||
|| # http://www.vbulletin.com | http://www.vbulletin.com/license.html # ||
|| ################################################## ################## ||
\*================================================ ======================*/

/**
* Static HTML Widget Controller
*
* @package vBulletin
* @author vBulletin Development Team
* @version $Revision: 31096 $
* @since $Date: 2009-06-03 08:42:31 -0700 (Wed, 03 Jun 2009) $
* @copyright Jelsoft Enterprises Ltd.
*/
Declare the class
class vBCms_Widget_Static extends vBCms_Widget
{
/*Properties======================================= =============================*/

/**
* A package identifier.
* This is used to resolve any related class names.
* It is also used by client code to resolve the class name of this widget.
*
* @var string
*/
Declare the package and class. You need to do this so the data managers and other components know how to handle inputs
protected $package = 'vBCms';

/**
* A class identifier.
* This is used to resolve any related class names.
* It is also used by client code to resolve the class name of this widget.
*
* @var string
*/
protected $class = 'Static';

/*Render=========================================== =============================*/

/**
* Returns the config view for the widget.
*
* @return vBCms_View_Widget - The view result
*/

Here's the first essential function. This creates the configuration interface and saves data. There is a template called vbcms_widget_static_config.

public function getConfigView()
{
Ensure we have been fully loaded. The classes use lazy loading

$this->assertWidget();

Verify and store the form variables we want.
'do' => vB_Input::TYPE_STR,
'html' => vB_Input::TYPE_STR,,
'template_name' => vB_Input::TYPE_STR
));

Get the template view. This rendering of templates is new for the CMS system. You can use the old methods, but this will be a bit faster.

$view = new vB_View_AJAXHTML('cms_widget_config');
Set the title

$view->title = new vB_Phrase('vbcms', 'configuring_widget_x', $this->widget->getTitle());
load the configuration

$config = $this->widget->getConfig();

See if we have data to save. verifyPostId, together with the addPostId function, adds a security layer

if (('config' == vB::$vbulletin->GPC['do']) AND $this->verifyPostId())
{
get the data manager and set the values

$config['html'] = str_replace('%u0025', '%' , vB::$vbulletin->GPC['html']);
if (vB::$vbulletin->GPC_exists['template_name'])
{
$config['template_name'] = vB::$vbulletin->GPC['template_name'];

}

$widgetdm = $this->widget->getDM();
$widgetdm->set('config', $config);

We don't really need this call in this widget. We have the ability to define widgets which have a per-page configuration. For this widget we have a single configuration site-wide. If you want a different statichtml widget you make a new widget instance. We left it here in case we want to extend it later.

if ($this->content)
{
$widgetdm->setConfigNode($this->content->getNodeId());

}
Save it
$widgetdm->save();
Check for errors, and display a message if we need to.
if (!$widgetdm->hasErrors())
{
if ($this->content)
{
$segments = array('node' => $this->content->getNodeURLSegment(),
'action' => vB_Router::getUserAction('vBCms_Controller_Content ', 'EditPage'));
$view->setUrl(vB_View_AJAXHTML::URL_FINISHED, vBCms_Route_Content::getURL($segments));
}

Show we're finished
$view->setStatus(vB_View_AJAXHTML::STATUS_FINISHED, new vB_Phrase('vbcms', 'configuration_saved'));

}
else
{
if (vB::$vbulletin->debug)
{
$view->addErrors($widgetdm->getErrors());

}

// only send a message
$view->setStatus(vB_View_AJAXHTML::STATUS_MESSAGE, new vB_Phrase('vbcms', 'configuration_failed'));

}

}
else
{
Now let's create the configuration interface. First create the view

// add the config content
$configview = $this->createView('config');

if (!isset($config['template_name']) or ('' == $config['template_name']) )
{
$config['template_name'] = 'vbcms_widget_static_page';

}

Add the html code
$configview->html = $config['html'] ? htmlspecialchars_uni($config['html']) : '';

// item id to ensure form is submitted to us
Set the form variables for security
$this->addPostId($configview);

Load the configuration and status

// send the view
$view->setStatus(vB_View_AJAXHTML::STATUS_VIEW, new vB_Phrase('vbcms', 'configuring_widget'));

}
and return the view

return $view;
}

And the second function. This creates the widget.

/**
* Fetches the standard page view for a widget.
*
* @return vBCms_View_Widget - The resolved view, or array of views
*/
public function getPageView()
{
ensure the widget is properly loaded

$this->assertWidget();

get the configuration- in this case it's the html code and the template

$config = $this->widget->getConfig();

if (!isset($config['template_name']) or ('' == $config['template_name']) )
{
$config['template_name'] = 'vbcms_widget_static_page';

}

instantiate the view

// Create view
$view = new vBCms_View_Widget($config['template_name']);

set the class, title, and description

$view->class = $this->widget->getClass();
$view->title = $this->widget->getTitle();
$view->description = $this->widget->getDescription();

load it into the view
$view->static_html = $config['html'];
and return the view
return $view;

}

/*================================================= =====================*\
|| ################################################## ##################
|| # Downloaded: [#]zipbuilddate[#]
|| # SVN: $Revision: 31096 $
|| ################################################## ##################
\*================================================ ======================*/

vBulletin 3.8.4 Release Chaos

Andy Huang — Tue, 11 Aug 2009 14:33:39 GMT

As many of you have no doubt noticed by now, we are running vBulletin 3.8.4 here on vbcom. In fact, we've been running the code here since around 11AM Pacific yesterday. But, this version is not available to the general public yet. Here's a brief account for what happened, and why it is not ready yet.

Originally, we planned to have the release out two weeks ago. However, because everyone with sufficient access was busy with working on 4.0 alpha, we did not had the resource to release it then. As such, we had planned for it to be review our resources for release last Friday. When we looked at it, we figured that it is best to release it on Monday, so if anything goes wrong, we can be around to fix the release as soon as we notice the problems, instead of leave things to go crazy all weekend.

Monday, yesterday, armed with Kier's documentations on how to do a release, we tried to do the release at around 10AM. We started to package the updated code, and upgrade scripts, only to realize that the upgrade script is not running as its intended to. This lead us to discover that in the midst of 4.0 preparation and regretful departure of Kier, Scott, and Mike, we've forgotten about updating the software version. As such, all changes we've made to that point was made for 3.8.3 release, not 3.8.4, so non of the template changes would kick in, and the any of the updated options/phrases we've added will not deploy proper. We sorted out the problems, did tests on our local environments, and pushed the code here -- it is always better to break our site than thousands of customers' site ;)

Even though the upgrade went through properly, we figured that it is best to let the code sit a bit, and see if any problems creep up on us before releasing. And it did. At around noon, we were told that there is an issue with a fix we've put in. Apparently, the diff placed the fix in a wrong place, causing all drop down menus to break. We corrected that and pushed the code to the live server.

Shortly after that, at around 1PM Pacific time, we start to get hit with DOS attack... No, it wasn't a swarm of happy clients hitting F5 in member's area looking for their download. It started as a SYN-flood like attack, IB's net ops deployed some scripts to deflate it, and prevent it creep up on us again. The attackers then went and changed their tactics and targeted our databases. This went back and forth until around 3PM or so. By then, it was probably too late in the day to be doing a release.

We also received words that there may be some potential problem which could be used to cause forum to stop working for some installations. So we took the time to investigate in this issue. Long story short, if your forum allows very very very long posts -- test data for reproducing the problem was 1.4MB or something in size -- the vbchop() function we use to make thread preview may eat up all the memory php is allowed to use. Going back and forth with the person who reported this problem to us for a bit, we were able to come up with a workable solution to this problem.

After all these chaos, it was too late to do a release, so we are going to do a take 2 today after our daily meeting -- probably around 10AM Pacific again. Hopeful thinking is telling me that we've done enough stress test on this thing, and it shouldn't have any problems this time around... but hey, you never know what might explode in your hand these days.

PS: As noted in the blog title, I forget to blog; so don't be too surprised if I forget to reply to your comments, too.

PS2: This is by no means a formal announcement. Just a running stream of thoughts. Don't quote me for times, or alike. And if the timezone's too vague, well, guess ;)

Edit:
.... And we are live (bit late). The release is out, and things looks like its working. Please do let us know if you find anything that is broken!

Nothing to Update

Freddie Bingham — Wed, 01 Jul 2009 19:37:10 GMT

It has been almost 4 months since I posted a blog entry. Sorry about that.

I have really had nothing concrete to post. I have been heavily into creating mock ups of the existing templates for the new style.

Presently, I am converting the mockups, along with some of the support team, and others at IB, into functional templates.

I have just finished getting the WYSIWYG editor functioning in the new style. vB4 has a new menu system, which is used for the Fonts, Sizes, Colors, Smilies, and Attachments. There was some pain involved in converting over to the new menu system.

vBulletin 4 - Style Variables

Kier — Tue, 16 Jun 2009 16:46:25 GMT

Since the beginning, vBulletin has had some way of inserting style-related variables into its templates.

In vBulletin 1 and 2, replacement variables were used, and simple html-esque tags could be inserted in order to re-style text etc. For example:

Here is some small text

would be replaced with

Here is some small text

The content of the replacement could be altered, so if you really wanted to, could be replaced with or something like that...

This system was necessarily simplistic and its scope for dramatically altering the appearance of the templates was strictly limited.

For vBulletin 3 we wanted to make use of CSS, if only for reasons of bandwidth. After all, it requires a lot less text to be delivered to a client to have than to have being translated into . Yes, those considerations seem largely irrelevant now, but it was important back then...

The use of CSS in vBulletin 3 is relatively light. Its primary purpose was to handle the specification of font sizes and families, and to manage the colours and backgrounds of commonly-used elements.

It achieved this through the use of a relatively small number of CSS classes, such as .tborder, .tcat, .thead and .tfoot, each of which had predefined properties for which values could be specified, together with a free-form field in which extra CSS properties could be entered. All of these values were then automagically baked into a single CSS stylesheet, the precise content of which could not be (easily) altered.

This system started to show its limitations when vBulletin 3.7 called for a CSS-driven layout for the user profile page (member.php). For the tab controller, I needed access to the colours and background attributes of the .tcat predefined vBulletin 3 class, and also the border attribute from the .tborder class, without all of their extra baggage. Unfortunately, this is not possible in vBulletin 3, so a kludge class had to be made that combined .tborder and .tcat, then undid various styling rules that were set up by those two. It was not pleasant to work with.

For vBulletin 4, I wanted a system that was based on CSS and semantic XHTML, but it had to retain the simplicity of changing colours, backgrounds and fonts etc. that existed in previous versions. I also wanted to be able to access individual components of CSS classes in order to re-use them elsewhere, in a way that can not be done using vBulletin 3.

The system I devised builds on another feature that appeared in vBulletin 3, namely the Style Variable or Stylevar. For vBulletin 3, used these for storing simple strings of data, such as the path to an image directory, or the amount of cell padding to apply to tables. These variables would then be available for use anywhere in the templates, so you could see things like or . These values could be customized and had the same system of inheritance as the templates themselves.

Therefore, the basis of the vBulletin 4 style system is freeform, editable CSS templates with the ability to call values from style variables.

Basic Style Variable Use

Consider the following example:
this is not code from vB4
.tcat {
color: #FFFFFF;
font-size: 10pt;
font-weight: bold;
font-family: verdana, geneva, lucida, 'lucida grande', arial, helvetica, sans-serif;
background-color: #869BBF;
background-image: url(../../images/gradients/gradient_tcat.gif);
background-repeat: repeat-x;
padding: 6px;

}

In vBulletin 3, it would have been impossible to extract that #869BBF background colour for use in a different CSS class. Now let's have a look at how the same CSS could be written in vBulletin 4:
.tcat {
color: {vb:stylevar tcat_color};
font-size: {vb:stylevar tcat_fontSize};
font-weight: {vb:stylevar tcat_fontWeight};
font-family: {vb:stylevar tcat_fontFamily};
background-color: {vb:stylevar tcat_backgroundColor}
background-image: {vb:stylevar tcat_backgroundImage}
background-repeat: {vb:stylevar tcat_backgroundRepeat};
padding: {vb:stylevar tcat_padding};

}

Using this new system, the various instances of {vb:stylevar stylevarname} will be replaced with the value of the corresponding style variable. Therefore, if we want to create an entirely new class that just happens to have the same background colour as the .tcat class but the text styling from .thead, we can do so very easily:

.whatever {
font-family: {vb:stylevar thead_fontFamily};
background-color: {vb:stylevar tcat_backgroundColor};

}

Style variables can be defined and edited through the new style variable editor, which is a little rough around the edges right now, but it's functional so I'll provide a screenshot of some simple style variable values being edited:

Here you can see three different colour variables being edited, together with a simple 'size' type, which will accept a value and a unit specification.

Compound Style Variables

Further, one can have what we have called compound style variables.

Those familiar with CSS will know that some CSS properties also have shorthand equivalents. Font and Background are two examples. Instead of writing the names and values of each CSS property, like this...
.foo {
font-size: 10pt;
font-weight: bold;
font-family: verdana;
background-color: red;
background-image: url(image.png);
background-repeat: repeat-x;

}

One can instead write it like this:
.foo {
font: 10pt bold verdana;
background: red url(image.png) repeat-x;

}

Compound style variables take advantage of this ability in CSS, allowing specific shorthand properties to be employed. For example, one may define all background properties into a single compound style variable, or access the individual elements. Some code will illustrate this better than me trying to describe it...
.foo {
font: {vb:stylevar foo_font.fontSize} {vb:stylevar foo_font.fontWeight} {vb:stylevar foo_font.fontFamily};
background: {vb:stylevar foo_background.backgroundColor} {vb:stylevar foo_background.backgroundImage} {vb:stylevar foo_background.backgroundRepeat};

}

Can also be written as...
.foo {
font: {vb:stylevar foo_font};
background: {vb:stylevar foo_background};

}

As can be seen from this example, when a compound style variable is called without specifying one of its component properties, it will return all of its component properties, in a fashion that is usable for shorthand CSS properties.

This screenshot shows compound style variables being edited - each set of values is saved into a single style variable that can be accessed either with the shorthand method (foo_font), or specified as individual properties (foo_font.fontSize, foo_font.fontFamily etc.).

Style Variable Mathematics

When using CSS, there are often times when an exact dimension is required for an element in order to fit into a particular place within a layout. Unfortunately however, CSS does not provide a method to specify an absolute size for elements. Consider the following example:

...

My 600 x 400 div

This will produce a box of exactly 600 x 400 pixels. However, if we now add a little extra CSS...

...

My 622 x 422 div

... we end up with a box measuring 622 x 422 pixels, because the border width and padding size are added to the dimensions of the box.

When dealing with static pages, one can deal with this by manually subtracting the border width and padding size from the dimensions, in order to restore the intended 600 x 400 pixel size:

...

My 600 x 400 div

However, in a dynamic page, where the border width and padding size are not fixed, this becomes impossible.

...

Oh dear, a 644 x 444 div

In the previous example, the result will not be the intended 600 x 400 box, as the padding size and border widths have been trebled from their original values.

The solution? Style Variable Maths! We can now enter mathematical expressions into our templates in order to resolve this issue and provide precise element dimensions (or positioning, or anything else that might involve numbers) while still respecting the values entered for style variables.

...

My 600 x 400 div

So What Does All This Get Me?

All this wrangling means that there are now three distinct methods to edit the style of a vBulletin 4 installation, depending upon the expertise of the administrator and the degree of customization required.

1) Editing Style Variables

The majority of administrators will not need to venture outside of the safe confines of the style variable editor to customize their sites. Access to colours, fonts, backgrounds, padding etc. can all be found within the style variable editor, and the use of Style Variable Maths in the templates means that (for the most part) administrators are free to change the variables' values as they choose without breaking the layout.

2) Editing CSS Templates

Those administrators with a greater knowledge of CSS may want to delve into the CSS templates in order to make more extreme customization to their style.

One may do this safe in the knowledge that at the worst they could break their layout by editing CSS, but they will not prevent content from being delivered to the browser - all of that is controlled by the HTML, not the CSS.

Further, the administrator no longer has CSS classes force-fed to them by the system. Under vBulletin 3, the .tborder, .thead, .tcat, .alt1 (etc.) classes were hard-coded to exist, and removing them involved code modifications and an abandonment of all style variables. This is no longer the case in vBulletin 4, where administrators may completely rewrite their CSS if they choose to do so, and in the process they may choose to employ all the default style variables in their CSS, ignore a few, or abandon their use completely. It's your choice.

A bonus of this approach is that there should be very few occasions where as CSS template is flagged by an upgrade as 'revert required', because critical data is not stored in these tempates, so there should be no reason to require them to be updated.

3) Editing XHTML Templates

The final method, and the one that will be most familiar to existing customers. Maybe you don't like or don't understand CSS. Maybe you want massive changes to your layout that CSS alone can't deliver. Either way, there is nothing to stop you editing the raw XHTML of the vBulletin templates, just as there has always been.

Except that now there is the three-way-diff template upgrade method, which will attempt to compare your customized templates with their original version from when you customized them and the new version of the default template, and then apply your customizations to the new version...

...which was the subject of a previous blog entry by Mike.

Over And Out

I think most people now know that I am working my last few days here at vBulletin. It's been almost nine years since I was brought into the vBulletin development team and eight since I took over John's role as lead developer and product manager. In that time I've made some great friends both of staff and customers and the decision to leave all of you, and the product to which I have dedicated so many years of my life, was one of the hardest I have ever made.

I will miss vBulletin, its staff and its customers greatly.

Thanks everyone.
- Kier

A Couple of Widget Screen Shots

Edwin Brown — Wed, 03 Jun 2009 15:19:41 GMT

I know it's hard to visualize the widgets when you can't see either what they look like or how you administer them. I've been holding off putting up screen shots, because none of the pages have been styled. The admin pages probably won't change much if at all, but the user-facing changes are getting a thorough facelift, both visually and in terms of the styling and templating. So please don't comment on how ugly the CMS page is. We know, and we've got all available hands working on it. But the screen shot does have the right elements in roughly the right order.

So the first screen shot shows the page where you set up the CMS page layout. This is a 75%/25% layout grid. We give you a number of options, and it's possible to create your own. Here I've put the content on the left, and two widgets on the right, for navigation and "my friends activity". This is all done with drag and drop. See the scrolling list of widgets on the left? You press the button to put one on the page, then drag it to the place you want it. You can have widgets on any of the columns, above or below the main content.

The second and third screen shots show widget configuration interfaces. Each widget type has it's own interface. To repeat, you create as many widgets as you want, each with it's own unique configuration. So for example you could have dozens of RSS feed widgets, each of is an RSSFeed widget type. Each has its own configuration, which for that widget is the URL of the feed. You then put each of those widgets onto one or more page layouts. Then when you create a CMS article you define the page layout.

The fourth page shows a CMS page. For this page I have turned the commenting on and made a couple of comments. You see the content in the center and left, extracts of the comments on the bottom with links to the discussion thread, the navigation widget at the top right, and below that the output of the "my friends" activity widget. In any real article of course the content would be more than two short sentences, but I wanted you to see everything at once.

So Long, and Thanks for All the Fish

Mike Sullivan — Mon, 11 May 2009 13:23:34 GMT

I originally got involved with vBulletin as one of the initial beta testers, way back in March/April 2000. I started writing some modifications for the vB 1.1 series (the member list and the PM system came from my code originally), and at the end of 2000, I was brought on to help with development of vB 2.0. Aside from a short period where I focused on my university studies, I've been involved in vB's development since then. Many of you probably know that I even relocated from the US to the UK 3 years ago to work with Kier, Scott, and Ashley in person.

However, I've decided that it's time for me to move on and pursue other goals.

I'd like to thank Jelsoft for giving me the opportunity to work on vBulletin. Generally, it's been a good 9 years. I've learned more things in that time than I could have imagined, and being able to see my work all over the internet in the shape of your websites is a very cool feeling indeed.

I'm sure you'll still be able to find me online. I try to stay involved with the PHP community, and a few vB'ers have already found me on Twitter... though I should get more involved with both.

So to borrow a famous line, so long and thanks for all the fish. :)

Mike

Near-Final List of Widgets

Edwin Brown — Thu, 07 May 2009 00:05:33 GMT

We've been doing a lot of work with widgets, and I have something that is close to the final list that will ship with vB 4.0. It's always possible something could change, but it looks right now like we have.

Static HTML: This allows you to enter any static html. That means you can put a remote page in an i-frame, or an image, or a google gadget, or a lot of other things.

Static BB Code: This gives you the BBCode editor and lets you put the results into a widget.

My Friends: You can specify a content type (posts, social groups, social group messages, visitor messages, CMS articles, or CMS static html), a maximum age, and a maximum count, and your users will see that content posted by their friends.

Recent Polls: You can specify either a specific poll or list of polls, or a specific user, and/or a forum, plus a maximum age and count, and you'll see a summary of matching polls.

RSS Feed: You can pull RSS content in RSS2 or atom format and see it in the widget.

Navigation: You can specify any combination of top-level nodes, parent nodes of the current page, and/or siblings of the current page. I find this on the right with all three options on, plus the breadcrumbs along the top, to be a good way to move around in cms. You may like something different.

Recent activity: This gives you threads which have had at least one post in the last X days (default is 1). You can set a maximum count (default is 10). Within that, you get the threads with:
Most recent activity

Most views

Most responses

Generalized Search Widget: This is by far the most powerful. You can specify
A content type. Default is everything, which then ignores the type-specific options.

A Forum, with or without its children

A social group category

A social group

A user

All friends

Keywords

Tags

Prefixes

Maximum age

As always, maximum count

The search widget gives you a lot of capability. You have to be a bit careful using it. You can't do any damage, but you can enter combinations of terms that will never return information. So for example if you enter a prefix and type "Social Group Messages", you're never going to get a result. That's because prefixes only apply to threads. We've tried to catch the obvious inconsistencies, and what we do is ignore additional search parameters that would generate an impossible search. If you put your head to it you can certainly enter combinations we didn't block.

Keep in mind that each of these is a widget type. You create widgets, each of which is one of these types with a specific set of parameters. So you could for example have ten statichtml widgets, each of which used a different google gadget. You could make five different search widgets, and myFriends widgets for visitor messages, posts, and social group messages. That would be eighteen widgets from three types. You then make eighteen page arrangements, and you can make multiple cms pages with each arrangement. If you have a hundred pages that use the same arrangement, you can change the widget on all 100 pages by changing it on the master arrangement. So although there are "only" eight widget types, you could easily find yourself creating dozens of widgets from the two or three types you find most useful.

I'm intentionally not posting pictures. We're working hard on moving pages to the new styles, but there's a lot of work to do and we haven't done any of the widget or widget admin pages. The appearance at the moment is no different from my earlier post.

Hope this helps.

vBulletin 4.0 Template Syntax

Scott MacVicar — Fri, 01 May 2009 14:05:37 GMT

With the style changes going into vBulletin 4.0 it is the ideal time to change the template syntax being used. The original syntax in vBulletin 3 is no longer supported and suitable replacements and enhancements have been added.

The first thing that has been is excessive eval, before in vBulletin 3 you would find eval peppered around the code everytime a template was being evaluated, this however has potential security implications and an overhead associated with it since none of the templates could be stored by opcode caches like APC and XCache.

vBulletin 4 now requires variables to be registered prior to their use within templates, previously all variables available at the time the template was rendered were available but this was known to cause problems when a variable was overwritten or not available. For the moment eval is still used to render the template but only inside the method in the class, this could potentially be removed in a future release.

The new code to render a template looks similar to below, while this may seem very verbose the registration method will allow more optimizations to be performed in the future.

PHP Code:

$templater = vB_Template::create('forumhome_event'); $templater->register('callink', $callink); $templater->register('daysevents', $daysevents); $templater->register('eventdate', $eventdate); $templater->register('eventdates', $eventdates); $upcomingevents = $templater->render();

The templates themselves also use a new syntax themselves, these have been namespaced for performance reasons. During scanning we only need to look at tags that have the vb namespace. Due to the way the scanner is written to provide a new tag syntax a class has to be dropped in with a validate and compile method defined.

Code:

Value is 2 Value is 3 Value is {$var}

So as you can see we've added an elseif condition to templates, another commonly requested feature was a loop.

Code:

Hi {$foo}

For content that helps describe the value of a template but has little use in being in the output we can use the new comment tag, when the templates are compiled these will be left out of the output. This can potentially help save in bandwidth.

Code:

Output: Test This won't be printed as comments are stripped at compile time.

For the cases in which we wish to print literal text and do no variable evaluation or tag parsing we can use the literal tag, everything will be printed exactly as it is within the tags.

Code:

Some test

In addition to the new tag syntax, we've also introduced a short hand curly syntax for simpler actions and some output formatting on variables. This moves the requirement to do formatting within the code to the template layer.

Dates can be formatted based on a timestamp, the second parameter indicates the format, if left blank the default board format is used.

Code:

{vb:date $var} {vb:date $var, Z} {vb:time $var} {vb:time H:i}

There is also a shorter if condition, when you only want a simple if, else.

Code:

{vb:if 1+1 == 2, 'It does make 2', 'Ooops, maths fail!'}

Number formatting

Code:

{vb:number 1000.1234, 3}

In an attempt to reduce the likelihood of XSS attacks there is now the concept of raw phrases and raw variables, anything without the raw prefix will automatically be escaped with htmlspecialchars_uni() before being evaluated.

Code:

{vb:phrase phrasename, $var, '