Request feedback: ... Modify templates without changing installed templates

[CarCdr]

Feature Permissions and Hooks System

I am looking at implementing a generalized feature permission and hook system. (More on hooks later...) Feature permissions can be arbitrarily complex such as "Post rate requred" or "Required registration period".

Feature Permissions would control access to:

1. Scripts (Examples: newattachment.php or vb_stats.php)
2. Script Actions (Example: search.php/getnew or postings.php/dodeletethread)
3. Templates
4. BB Codes

Here are some examples of how one could use Feature Permissions:

• Allow attachments only if user has a certain number of posts.
• Disallow unregistered users from viewing post content.
• Control access to the HTML BB Code
• Allow poll posting only if user has a minimum reputation.
• Control access to installed hacks
• Control access to non-vBulletin pages (i.e., login required)
• Restrict access to features within scripts, such as the physical deletion feature.

These sorts of things could be done without requiring Admin's to modify vBulletin or install custom hacks. This would allow Admin's to run many smaller customizations and access checking without having to worry about managing and upgrading custom hacks they would normally require.

(Developer note: The Feature Permissions and Hooks system itself would require only 3 or 4 small mod's, not counting the AdminCP interface and the new table: global.php, template fetcher, BBCode parser. The mod's would be small because they would consist primarily of calls to the vb_features_and_hook functions.

Controlling access to non-vB pages would require admin's to use links to these pages that go through our permission checker -- a simple check and redirect script.)

The permission system would allow for access control to most vBulletin features. The hook system would allow for the injection of PHP code or template code before and/or after installed scripts and templates. The hook system would accommodate many types of current mod's without any need to modify PHP scripts or templates.


Access Permissions

While many types of common permissions would be included, new permissions of arbitrary complexity can be defined by the Admin to grant or deny access to features.

The default permissions (you can define others) that one can specify would include:

• usergroup check
• userid check
• adminstrators
• moderators
• spiders
• minimum registration days
• minimum post count required
• minimum post rate (i.e., per day) required.

You can extend the system by defining your own permissions as well. For example, let's assume that you setup your more powerful usergroups to begin with the characters "Admin". You could define a new permission called "Admin usergroup name" and define this new permission to be a test to "Grant acccess only if usergroup name begins with the characters 'admin'.". Here's a text-only mockup of this in AdminCP:

Feature Permission Define New Permission
Permission name: Admin usergroup name
Permission test: preg_match('/admin*/i', $bbuserinfo['username')

Assigning Permissions

From your list of defined permissions (default or customs permissions), you can assign them to any script, script+action, template, or BB Code. Here's an example of how restricting access to the HTML BB Code might look (mockup):

Feature Permission Assign Permission
Feature type: BBCode
BBCode name: html
Permission tests:
1. Usergroups: 8, 11, supermods, admins
2. Reputation: 100

This example would restrict access to the HTML BBCode to the usergroups specified if their reputation is 100 or more.

As mentioned earlier, you can also define your own permission tests and use them to restrict/grant access. For example you could restrict access to a feature such as "Can physically delete posts?" to only those passing your custom "Admin usergroup name" test. AdminCP mockup:

Feature Permission Assign Permission
Feature type: Script
Script: postings.php
Script actions: dododeletethread, dodeleteposts
Script parameter:deletetype = 1
Permission tests:
1. Admin usergroup name

Hooks

Hooks are a common technique of allowing administrators to run custom code/settings without having to modify the base system. No change is made to any vBulletin script, table, or template.

Hooks might be run at the folllowing minimum number of points:

1. Before global.php is eval'd
2. At the beginning of any script
3. Before any template
4. After any template

The affect of hooks is as if you modified the underlying script or template. The code snippet you specify is "run" at the points listed above. Here are a couple of simple examples...

Problem: Restrict the use of custom avatars to usergroups 1, 8, and 9.
AdminCP mockup solution:
Feature Permission Add Hook
Hook type: Script
Script name: profile.php
Hook code:
if (your custom test here or a feature permission test here)
{
$permissions['genericpermissions'] ~= CANUSEAVATAR
}

The affect would be to turn off the custom avatar feature under certain conditions (i.e., for certain users) without having to modify vBulletin.

Problem: For postbit_legacy, only show the avatar under certain conditions.
AdminCP mockup solution:
Feature Permission Add Hook
Hook type: Template
Template name: postbit_legacy
Run when: before
Hook code:
if (your custom test here or a feature permission test here)
{
$show['avatar'] = false;
}

That's About It...

Imo, such a system will allow for many types of access control and customizations without having to modify scripts or templates.

We can define new types of permissions and hooks, then post them here for others to use.

I have not tried to be too detailed at this stage regarding the implementation details or the finer points of the AdminCP interface.

Your feedback is welcome.

C.C