Version: 1.2.1, by Trigunflame
Developer Last Online: Nov 2019
Version: 3.5.3
Rating:
Released: 02-05-2006
Last Update: 03-11-2006
Installs: 171
Code Changes Additional Files
No support by the author.
Vbulletin Plugin Accelerator Accelerate Your Forums Plugins
Summary:
If you use the Vbulletin Plugin System (Specially if you use a lot of plugins), this will help improve the performance of the system overall by inlining all of the plugin code into the PHP files themself.
Essentially making it as if you had hacked the files yourself, this will give you better performance on your forum overall.
Open install.txt and Read Instructions to install like usual.
Current Status: (RC2)
Release Candidate 2 Has Been Released.
This code has been deemed acceptable and to be used by all.
Please report any bugs back to this thread.
Thanks.
Latest Changes: 02/11/2006
Fixed another problem with backslashes, hopefully this will fix some other problems.
To upgrade, just replace the includes/class_plugin_accelerator.php with the new one.
Important Notes:
1. While this IS a release candidate, more than likely its not fully bug free so Please backup your files before you install this modification, this system is not yet perfect.
2. When running "Rebuild Hook Cache" and "Rebuild All Plugins" if you ever see a small parse error, or file couldnt be opened error; re-run both again and it should go away.
3. includes/hook_files.php contains locations of all the files the accelerator scans for plugin hooks, if you have any files that have been renamed, moved, etc.. you need to add it to that file on its own line, thanks.
If You Have Problems:
If you incur any parse errors, or pages not displaying after running the steps. Please make a copy of the affect file as well as its original version, zip them and upload somewhere. Send me a link to the file for me to download, review and provide a fix.
Show Your Support
This modification may not be copied, reproduced or published elsewhere without author's permission.
Interesting
I wrote a little windows application to prepare a "slipstreamed" vBulletin with all Plugins included back in beta stage.
Worked very well, though you loose the flexibility of the Plugin system:
You can't easily enable/disable Plugins/Products through ACP anymore, as this requires reprocessing the files.
And having them +w might not be a too good option, especially in shared environments.
Interesting
I wrote a little windows application to prepare a "slipstreamed" vBulletin with all Plugins included back in beta stage.
Worked very well, though you loose the flexibility of the Plugin system:
You can't easily enable/disable Plugins/Products through ACP anymore, as this requires reprocessing the files.
And having them +w might not be a too good option, especially in shared environments.
Well this is the thing, you Will be able to easily "enable/disable" the plugins and products from the ACP; this system will not hinder the use of that, I will keep a cache of the hook_name => file pairs, by good use of power of preg via comments I can control where code is placed in the vbulletin files and be able to add and remove plugin code easily (Only) on the needed files, no need to scan the files again for every plugin code change.
As for the chmod options, there is a truth to that; but I can probably write a suitable php implementation that can control the chmod options to a degree when files need to be wrote, then set back to 755.. ofcourse this will defer depending on the system; in the end people can always chmod their files to 777 when they want to make a change, then back to 755 when they finish.
Yeah, but if I turn Off the Plugin System you will have to re-process all files that contain active Hooks
Also, you would have to add a check for DISABLE_HOOKS being set on every Hoook location, or that won't work any longer - which again adds some overhead.
Yeah, but if I turn Off the Plugin System you will have to re-process all files that contain active Hooks
Also, you would have to add a check for DISABLE_HOOKS being set on every Hoook location, or that won't work any longer - which again adds some overhead.
That is true, but you are talking hypothetically. Realistically no one is going to turn their plugin system on and off several times a day every day. There are lots of plugin hooks, but not all of them are used.. as such not every file has to be modified and not every hook has to be replaced. If the file contains hooks that are not currently used by the system they are simply commented out.
I plan to keep existing compatability; Even if used an if() construct for each plugin segment that still takes less cpu cycles than an empty function call.