This is exactly what my (not fully finished yet) Advanced Plugin Manager does :)
If you take a look at the last few Hacks I released, they already contain some parts of the necessary information.

Theoretically, it would even be possible to make it so only the XML-File would be required - and no installer backend.

wouldnt that be cheating on the hack definitions tho? ;)

Don't think so.
You can install Phrases, Templates, Settings and Queries through ACP only - no FTP access required.

Cheers.

Thats what I think - it should be like 3.0 except also have information about how it does what it does in the thread. However, it shouldnt be SORTED by that information.

That is 100% possible. All admins need to do is install one hack on their board that can download files to the server. WHen you click install, it goes to:

http://www.domain.ext/dir/admincp/ha...oad&hack=23432

23432 is the thread ID for vBDownloads, and that would then download the vBDownloads file to /admincp/hacks/23432/ by accessing vbulletin.org/forum/hackinstaller.php?do=download&hack=24532&username= x&password=y

A header is sent to the browser "location: hackinstaller.php?do=install&hack=23432

THe user then sees /admincp/hacks/23432/install.php which is fetched by the hackinstaller mod.

The hackinstaller mod would require each hack have support for different functions:

- add template, remove template, upgrade template
- add phrase, remove phrase, upgrade phrase
- install sq, remove sql, upgrade sql
- add files, remove files

Each hack could be managed so easily with no errors, EVER!

Sounds excellent Kirby ;)

Not really - Like Kirby said, you can already add templates and run queries from your ACP - The only reason people write installers is so that you run the file and it's done for you - Otherwise if you have to add several templates and run several queries by hand it can get a bit tedious as a user ;)

Satan

Kirby - your the dude (I think the one from some nintendo game if I am right).

Yesyesyes. This should and ought to be done (for humanity sake).
I started work on a universal installer - but ditched devloping it as it would have been a butt ache to support. If it helps - take any of my installers (like the GAB or GISH ones) and strip whatever can help from there as they actually also make file edits for you (ooo. thats almost a swear word with 3.5 isnt it?).
The installers are underdevloped for a broad use - however they do seem to do the trick for most cases and only reqire an array that contains the templates, phrases, file edits, etc...).

Or not.

Im sure you are quite capable of doing a kick ass version without any of that ;)

I think somethings are getting confused between two factors that are not one and the same:

1. FTP upload
2. vBulletin support

FTP access isn't as important a factor as the rest (code mod, alter queries, installer, plugin, etc.). What about cpnav_x.xml additions? These do require upload through FTP, but clearly wouldn't invalidate support, or be seen as a support issue or complexity factor. Yes, 3 members don't have FTP access, so what? They can use hacks that do not require FTP access, no need for a special category just for that.

vBulletin support shouldn't really be used to classify mods into caegories. Just add a check box, and let it be categorized wherever it belongs. Really, one could write a single plugin file that I'm sure vBulletin would not support, based on the actions and queries the plugin would do ;)

The new database can classify based on functionality, and sub-forums can be either a single forum, or divided by complexity level (tenplate/style; just plugin; plugin+installer and extra queries; extensions; and code modifications)

Well, the installer part is almost working already ;)
But support for Uninstall/Upgrade doesn't really exisrt ...yet

You will never see this, here are a few reasons why:

1. It would require a direct connection between your server and vB.org's server, even if done with php only it leads to other problems, due to php's timeout setting.

2. Said installer hack could be exploited, while this is true for all things this would put a lot of customers at risk if a hole is found.

3. It would require authors to release their work in a certain format, and would mean users would have to install a hack before they can install anything else. We already saw what happens in this situation back when the htl hack came out.

It's a nice idea in concept but it just doesn't work in the real world.

We shall see.

Wrong. Probably the best example of this is paypal... It is quite easy to try to connect to another server and then debug problems along the way. If worst comes to worst then the user sees "transfer error: try a manual install."

I can respond to this in two ways, which I will do. (a) This is less exploitable than the majority of hacks because it is 100% admin side. In addition, it wouldn't be explotable at vBulletin because there is no way to exploit the 10 lines of code that it would take. (b) Would you like some vB 3.0.7 exploits?

Yes yes, a very democratic approach to the world. The huddled masses are too stupid to manage things so lets dumb it down for them even if it means they have to do more work. However, your logic here is wrong. Authors would not have to release their work in any format exactly, it would be flexible. All the installer would have to support is 'do=install' 'do=upgrade' 'do=uninstall.' And, it would not require users to install the hackinstaller.php file, because all they would have to do is access the regular install file without the aid of hackinstaller.php.

For everyones information, I have already designed my installer to be compatable with this system and I have created a small library. I dont plan to actually make the mod because vbulletin.org would have to cooperate with me - and they would never do it because it is just too big of a change and they could see it as risky.