A new vBhacker

[Fallout2man]

Well after finally getting the okay from Firefly, I've started working on a new vBhacker, it probably won't really be used much for 2.0 considering it's on its last legs, however I would hope that with the future release of vBulletin 3.0 it would be used as a de facto standard for releasing hacks.


In the spirit of wanting to make it that De facto standard, I ask you, the vBulletin hacking community. What do you want in the new vBhacker/vBhackmaker? What would make you use it above the old fashioned find and replace posts or text files?


So far I've got the following changes planned

1. Can Create files: vBhacker already supports most hacking operations, but I've noticed it can't create new files, seeing as it already edits files, creating new ones only feels like a logical expansion.
2. Can upgrade hacks: One of the features I think most would enjoy, would be an easy upgrading of hacks. This will be achieved by having the hack data segmented into versions, (So say, four file edits and two queries in 1.0, one edit and a new template in 1.1, three template edits and a query in 1.2,ETC).
3. Can uninstall hacks: Gotten tired of the extra queries? No problem, uninstall hacks at any time, without even requiring having the original hack package in your admin directory.
4. vBhacker table: This is how the top two are achieved, a database table that keeps track of what you have installed, what versions, and so forth, it will also contain uninstall data that will allow you to uninstall any installed hack.
5. Unique Identifacation and integrity checking: Each hack file will be identified not by its name, but a guid generated upon hack creation. During the installation, the guid is checked for integrity, to ensure the hack wasn't tampered with.
6. Compatability issues and dependancies: I've also been considering making the hack store a list of conflicting hacks, as well as conflicting vB versions that it won't install with, then adding a data column to that for safe versions of the offending code. So that the hack will safely pick what needs to be installed if two hacks modify the same area of code, or if the vBulletin code is unrecognizable in another version.
7. vBhacker compatabilities: Say I make a massive update in the future, to vBhacker, and it would render all previous hacks useless. No problem, each hack stores the vBhacker version it was made in, so the installer can detect that and install the hack correctly, according to the old standards, while still being able to work with new hacks

I've also been debating using what I call a Hack permission system, for vBhacker so that when the original author creates his or her hack, they can specify if they want the hack to either

1. Let everyone work on it reguardless, making a new data column containing unique author hashes so who worked on it can be kept track of.
2. Let only people given permission work on the hack. Meaning a special, unique, hack permission id would be generated upon its initial creation, anyone who would want to work on that hack would need to enter in the id.
3. Only let the original author work on the hack.

Of course the problem with that would be if I implimented a permissions system, I'd also need to use the zend encoder to encrypt the php files to ensure it wasn't tampered with.


Anyway, I've only really just begun working on this, but I want to hear what everyone thinks, ideas, comments, suggestions, etc. I want to make this the best possible vBhacker, in the hopes of someday in the future, we won't need to have to spend as much effort in manually going over file edits, and template edits, or queries and the like. This probably won't be finished for a while, but I'll do my best to make sure that when it is released, it works as advertised.