A new vBhacker
 

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.

Hey Fallout man is me tha guy dat had a convo wid ya in Vbulletin.com
glad to see u going ahead with this infact very happy

My idea would be for a seperate template in Admin cp
to show what hacks have been installed , and have it intergrated into Admin cp so with the Click of a button install and uninstall right from there, also if there is a problem in the hack
instead of Showing u steps to do it manually remove the changes completely back to the original settings
because it would cause problems if the hack that u wanted to Installed didn;t work anyway

A hack manager would be implied in what I'd be making, it would contain a list of what you had and let you uninstall from there.

This sounds pretty impressive pal :D

- miSt

Specifically, I'd like to ask everyone about the idea of a hack permission system, reguarding editing. Do you think it's worth it to encode the files to keep such a system tamper proof?

Would it really be worth all the effort?
Why bother doing so much in an attempt to prevent someone's hack from being edited.
As a matter of fact, unless you're selling your hack, it's free and under the terms of the GNU public license, isn't it?
Which states you can edit without redistribution.
No?

Dave.