Add options per forum
 

What this is
This guide will teach you to use the hooks system to add options to your admincp/forum.php page. One finished, you will be able to add new options to your forum with just a few lines of code.

Don't understand?
Ever wanted to turn something on, but only in one of your forums? For example, lets say you want to execute code, but only in forum I.D. 2, 16, and 45.

Lets begin!
In this tutorial we will assume that you want a yes or no option; in order to enable/disable some code. In order to do that we first need to create a new row in the database. This will hold the information of which forums will be enabled/disabled. Always remember that '1' is considered as on, or enabled. And that '0' is considered off, or disabled.


We have to store the data!
Run this SQL Query:
[sql]
ALTER TABLE forum ADD (
var smallint(3) unsigned not null default ''
)
[/sql]

Var = The name of the row in the database. This should be a name that will describe your system in one word. For example. In my vB Category Icons hack. This row is named 'forumhomeicon'

Now that we have added our new row named 'var'. We now have to add the on/off option in the forums manager area of the admin control panel.

Add the option in the ACP
To add this new option in the ACP we need to create a new hook and add some code to that hook.

The hook name should be: forumadmin_edit_form
And the code should be:
Notice the 'var'? Remember, that's the row name!
That will actually add the yes/no row to all your forums in the admincp. So when you click on the save button, it will add your selection to the database.

But how does it know which row to add it to? Glad you asked.

You have to create one more hook!
The hook name should be: forumdata_start
And the code to add there is the following
Notice the var again? That's telling it which row to add it to.

I want to add more then just one option!
Then you will need to repeat this tutorial for each option you would like to have.

Now that you have saved both hooks. You can now use the following code in any of your hooks.

In templates you would use

Big Tip:
If you have 2 or more options being added to the forums, you can place all the code in each hook. For example:

Hookname: forumadmin_edit_form
Code:
Hook Name: forumdata_start
Code:
You don't have to keep creating new hooks for more options for the same hack. Is better to only create hooks for separate hacks.



Custom Fields
The following fields can also be used.
There are more that can be used. When I have some more time I will add them all here. :)

This tutorial was created for a member who needed to know how to do this exact thing, so I figured I would teach everyone. :p

There is actually an easier way:
Just add a new bit to the $_FORUMOPTIONS array and you are there. Why alter the database?

Care to share?

Using existing Bitfields is bad coding style ;)
This will cause problems sooner or later when Jelsoft starts to use further Bits.

Furthermore, $_FORUMOPTIONS doesn't even exist in vBulletin 3.5

And as it is possible not to use forumoptions here, it should be encouraged to do so (eg. use custom fields).
This is official Jelsoft stance regarding Bitfields.

Thanks for clearing that up Andreas. I thought the way I was doing it was incorrect for a min.

Nope, it's absolutely correct - but you might want to point out that if you are adding a bunch of Yes/No type settings, it could be a good idea to introduce a custom bitfield :)

Thanks, I'll edit my first post with all of them in a few mins. After I type them all. :)

Umm... Why? Did you just make this up?

That would be a release of a new version. And the hack would have to be recoded anyways.

You're right. I thought it was there because it was in 3.0.7. I am sure there is another variable of that kind, I'ma go and take a look at the code.. By the way, I used custom bitfields in one of my hacks for 3.0.7.. It was fine.

Then they should make "custom fields" for forums just like there are some for users.

Didn't say "incorrect". Just wanted to suggest a way that does not involve changing DB.. ;)

When i said incorrect, I meant not to your coding standards. ;)

No. As said, this is official Jelsoft stance.
It is bad, as (in contrary to custom tables/colums/variables) using default vBulletin Bitfields for custom settings will cause Problems.

Wort Case scenario: Your Hack uses the next available Bit in forumoptions for "Show Quick Stats for this Forum".
Now the next vBulletin Version comes and redifines this Bit to "Prune this Forum every 24 hours".
Now all users of this Hack have the Bit set ...


Well, what does adding a custom field do?
It adds a record to Table profilefield and alters table userfield to have a new MEDIUMTEXT columd fieldxx.
This is just an easy-to-use frontend to alter the Database, so where is the difference?

Keeping the Product Manager in mind, such DB alterations can be done easily, without the User having to know anything about running queries.