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

[CarCdr]

To help explain the sorts of things one could do, I took a few minutes to search for questions regarding permissions/allowing/disallowing/showing/hiding Here are a few selected links to hacks, hack requests, or template customizations that could be done using only the AdminCP interface of the proposed system:

How to disallow all but ADMIN from seeing Tachy'ed posts?
https://vborg.vbsupport.ru/showthread.php?t=64913

Limit Members to X posts in X hours
https://vborg.vbsupport.ru/showthread.php?t=68084

Is it possible to have the user signatue to show up ONCE per page?
http://www.vbulletin.com/forum/showthread.php?t=90108

Disallow guests to view threads, must register first
https://vborg.vbsupport.ru/showthread.php?t=59859

Member Search turned on by usergroup
https://vborg.vbsupport.ru/showthread.php?t=67178

Allow certain users to post HTML when forum has HTML off?
https://vborg.vbsupport.ru/showpost....59&postcount=1

Allow Group to Read Titles / Not Content
https://vborg.vbsupport.ru/showthread.php?t=60178

How do I hide certain forums on the forumhome page only?
http://www.vbulletin.com/forum/showpost.php?p=646342

Disallow Mass Prune/Move for Super Mods
https://vborg.vbsupport.ru/showthread.php?t=66312

[CarCdr]

How would one control access to a hack that was just a mod to an existing vB script?

For example, Erwin's excellent little Microstats hack installs in function print_output in the file functions.php. It contains a hard-coded test for usergroup of 6. To change this default access, or update it later on, an administrator would have to modify functions.php.

What would be easier to manage would be a Feature Permission associated with the hack. In such a case, the contributor could simply add a permission name so that administrators would only have to use the AdminCP to control access to the hack.

In the case of Microstats, let's say that Erwin wanted to associate the permission name "Microstats" with the hack. His code would be delivered looking something like this:

if (defined('FEATURE_PERMISSIONS'))       // Feature permissions installed
{
     require_once('./includes/functions_feature_permissions');
     $grant_access = fp_access_allowed('Microstats');
}
if (!isset($grant_access))                // Use default access check
{
     $grant_access = ($bbuserinfo[usergroupid]==6)
}

Here, if permissions are defined via AdminCP for the permission name "Microstats", then those permissions will apply. If the administrator does not define permissions, the default permission check will apply.

To control access using feature permissions, the administrator would define the permissions before installing the hack. For example, here is a mockup of AdminCP values required to restrict the hack to usergroups 6-9 or supermoderators or userids 46 or 101:

AdminCP:: Feature Permissions:: Define Permission
Permission name: Microstats
Usergroups: 6-9, supermoderators
Userids: 46, 101

[CarCdr]

I find it odd that this proposal was not worth commenting on whatsoever. Was is odd? Was it poorly written? Do you opine it has no merit?

There are ways to deal with the issue of customizing our boards without installing tens of hacks, code mod's, and template changes.

Just mho.

[Sypher]

kind of tired... breezed through the posts...

but it sounds like a great idea and it sounds like you have it pretty planned out how to do it

access modifications for anything should be easy (I agree with you)

I say go for it

[CarCdr]

How nice it would be to have the capability to run modified templates without actually modifying them. Let me explain.

Right now, the template system has a few real drawbacks:

#1 Tracking and re-mod'ing after upgrade a large headache.
#2 Have to modify a template in many styles if you have styles.
#3 Difficult to test a change on a live board.

Using the "Template Hooks" system (described earlier in this thread), you would not actually modify templates to apply a change. No more length comparison of template code. No more revert and reinstall.

The hooks are defined through AdminCP and saved in a separate table. No templates are actually modified. The proper template code is output when pages are built, but no change is made to the installed templates.

I'll recap that discussion with the example I used:

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
  Styles:         all
  Userid:         1
  Type:           before template
  Hook template code:
     if (your custom test here or a feature permission test here)
     {
          $show['avatar'] = false;
     }

#1 problem solved: installed templates are not actually modified
The key here is that you are not changing the base template. The modified template code is output only when the page is built. (This would require a small mod to the functions cache_templates and fetch_template, without worry of any noticeable performance penalty.)

#2 problem solved: change is only used for a specific testing account.
Notice in this example that I applied permissions. This makes it very easy for an admin to test a change. In this case, the change would be applied only if the running userid is '1'. You could set this to any testing user account.

#3 problem solved: making change to many styles
In this case, the change will be applied under all styles. One could also specify a list of one or more style id's to limit the change. Again, no change to any vB-delivered table actually takes place.

Another Challenge For The System
A limitation with the "Template Hook" system is that the hook can be applied only before and/or after a style. What about changes to template code in the middle of a template?

Here's how that would look. In this case, we want to modify a template so that "Quote message in reply?" is checked by default when using Quick Reply. This request was raised in a recent thread here at vb.org.

Problem: Apply a change within showthread_quickreply template

AdminCP mockup solution:

Feature Permission Add Hook
  Hook type:      Template
  Template name:  showthread_quickreply
  Styles:         all
  Type:           find/replace
  Find:           tabindex="4" />
  Change to:      tabindex="4" checked="checked" />

The system would complain if the "Find:" string match was either (a) not found or (b) not a unique match. Also, an AdminCP utility would be provided to check all hooks for these errors after an upgrade.

In this case, the change applies to all styles and there are no permission limitations.

Developing this template hook system would offer the admin more power and, perhaps more importantly, less maintenance work. Sure, after upgrading vB the admin would have to check that the underlying templates did not change incompatibly, but this would be a heckuva lot easier using this system than applying the changes by hand to templates.

There will be cases when applying a hook would not be the right approach, but this proposal would cover the vast majority of simpler changes.

Comments?

[CarCdr]

Sharing Hooks

To make the sharing of hooks very easy, the right approach would be to allow for one to copy and paste a hook.

One could just post the text of the hook on a board, like so:

Hook type: Template
Template name: showthread_quickreply
Styles: all
Type: find/replace
Find: tabindex="4" />
Change to: tabindex="4" checked="checked" />

then the reader could copy it and paste it into his Hooks AdminCP page that allows for the importing of such hook descriptions. He then clicks "Import" or whatever, and is taken to the same page he would be at if he had filled in the hook information by hand.

Maybe that text is XML. Not important at this point in the discussion.

An alternative would be to share XML files, but that would require many more steps for both the contributor (create file, upload to post, not visible to readers) and a few more steps for the importer/Admin.