This is alpha quality code, we are just in the testing stages; the current code in the archive simply provides 2 tests that you can run to see if the plugin system code will work on your server/forum/site.

We should have "fully" operational code with the next day or so.

Thans let us try with it in our test site ...
:)
thnx

Hey thanks,
But there is no file called static_plugins.php in the zip file!

I renamed it to test.php, sorry I'll update page.

Re: No4 below, what findings do you want?

/me clicks on the clicky clicky Install button...

Check the results of test 2 to verify that the ($hook = vbxxxxxx ? : false) is replaced with example php code inside comment blocks.

So let's just make sure I understand this;

This will scan every vbulletin php file for hook calls, and for each one it will ;-

1. If you have no plugins associated with that hook it will just comment it out

2. If you have a plugin that uses it, it will edit the actual file - to copy the code into it.

What happens when I edit/enable/disable plugins ?

Would it not be less dangerous to copy the plugin code to a php file named after the hook, and just edit the hook call to an include() for that file (have a plugins folder the same as the includes folder) ?

Paul, included I have a file called hook_files.php that list 1 file per line that tell the script which files are permitted to be parsed.

The hooks that have no plugincode associated with it, are commented out in "Accelerated Plugin Style Comment Blocks" for use later (Which Still Saves You an Empty Hook Function Call". If there is a valid hook that there is plugin code, it will insert the code in the correct location inside the files that use that hook.

When you enable/disable plugins, the files that are modified are reverted back to their natural state with their default vbulletin php code.

As for using includes, specifically "naming a file after each hook name", we would encounter 'the law of diminished returns'; as there are 8+ hooks in some files, includes() account for filesystem stat calls while on "Most" pages be faster than an eval() to a large amount of code; still be slower than running it directly from inside the script using it.

Note to Anyone Reading This: None of the above actually Works yet; we are still in testing stages.

Interesting cocept. I think I'll stick to manually doing my files.