The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
[How-To] Product Managament (vBulletin 3.5 RC 1 and up)
This How-To is mainly meant for Hack-Developers, if you are only planning to use Hacks just read the End-User section. Developers vBulletin 3.5.0 RC1 introduces a new concept for customizing/modifying vBulletin: Products. With Products, you can manage Plugins, Phrases, Settings and Templates in just one XML File. Furthermore it supports Install/Uninstall Codes (for running queries, etc.), it also covers updating existing Hacks as you can add Codes for different Versions. To start, you first have to turn on debug mode: Put PHP Code:
Then go to ACP / Plugin System / Manage Products. Click Add/Import Product. In the second Form (Add New Product) fill in the Details for your Hack:
Afterwards, create all the Plugins, Phrases, Templates and Settings your Hack requires and make sure you select the Product you just created. Important: Templates must be placed in the MASTER Style, Phrases in the MASTER Language When you are finished, go to ACP / Plugin System / Manage Products and select Edit from the Dropdown next to your Product. In the Form (Add New Install/Uninstall Code) add all Code necessary to install/uninstall your Hack (eg, Queries, etc.). If you are updating an existing Hack, add new Install/Uninstall Codes for the new Version that just make the changes necessary to upgrade the previous Version; Product Management will make sure that all necessary Codes will be run. If your Hack includes Usergroup Permissions/Bitfields, add the following Code to Install and Uninstall to rebuild the Bitfield cache: PHP Code:
End-Users Go to ACP / Plugin System / Manage Products. Click Add/Import Product, select the product XML File for the Hack you want to install. If you are upgrading an existing Hack, make sure that Allow Overwrite is set to Yes This How-To is (C) 2005 by KirbyDE and you are not allowed to redistribute it in any way without my explicit consent. |
#92
|
||||
|
||||
I have added settings and they show up like normal even after an upgrade. yes, you need to have it set to yes for "vBulletin Default" but if it is still attached to a product, it is there. And mine saved the title and description also. I'm not sure why it isn't working for you.
|
#93
|
||||
|
||||
So what's the vBulletin Default setting do? The description is misleading, to say the least.
|
#94
|
||||
|
||||
Kirby could probably answer that better than I could. I was just told in order to export it and have it retain the settings you entered, you must have it set to yes and attached to a product.
|
#95
|
|||
|
|||
The term 'vBulletin Default' is something that is inherited from older versions. The phrase should be changed to somehting that more fits the current situation.
|
#96
|
||||
|
||||
As already pointed out, "vBulletin Default" is misleading.
The correct meaning would be smth. like "Default Setting<dfn>This setting will be replaced during upgrades of the Product this setting does belong to</dfn>" |
#97
|
||||
|
||||
That would help, but I still don't understand why this setting exists. If you set it no, it's almost like the setting isn't attached to your product. It won't export or uninstall with the product it's part of unless vBulletin Default is set to yes.
|
#98
|
||||
|
||||
Yes. That's was this option is for:
Making custom settings that won't be affected by upgrades. And as they are custom settings, they won't be exported with the product. |
#99
|
|||
|
|||
Oh my... I should've read this... I crafted the secret admirer one by hand, poking around in the code trying to determine what it wanted, and guessing bits as I went along!
Well, I don't think I did badly |
#100
|
|||
|
|||
Something peculiar I've discovered.
If your product involves templates and they are edited after installation, when an upgrade takes place, the modified template stays in use. Admins need to be made aware to click revert just like stock templates on vb upgrades. I think also in one instance, I edited the product xml file by hand but didn't change the timestamp of when the template was authored. Not done testing this but I think if the dates are the same you may wind up with the same situation even though the templates have changed. Almost forgot... If they install a product, edit the template and then uninstall the product the template will not be uninstallled. It will move up to custom templates in the template list. |
#101
|
||||
|
||||
Templates behave the same way like standard vBulletin Templates:
Customizations will not be affected by Updates; If customized Templates are no longer compatible they will be reverted. Also, if you have customized Templates and these Templates no longer exist in the MASTER style of upcoming vBulletin Versions, they will show up as custom. I don't think that this is a big issue - it just wastes some table space. The timestamp does not matter - whenever you import a product XML all master style templates with the productid will be deleted first. |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|