What about hacks that include many images, lots of php/js/whatever files? These can be much larger then 1mb, and you aren't pushing that to a php script via http in most cases. Sure it can be done without http/php but then we start getting into other problems, mainly requiring things to be done at the server level that don't need to be in place to install vBulletin in the first place, making the entire system useless to most.

a) Just because it is on the admin side doesn't make it un-exploitable or less exploitable. Said system requires us to access your server, the code used to govern this access can/will have some bugs over time. If every bored had to have this code in place to install other hacks that would mean a large number of customers would be at risk is a bug was found.

b) I think I've seen you post this multiple times now, it is a moot point. Why don't you show said exploits to the dev team via the bug tracker so they can get fixed? We all know bugs exisit in the code and vB is not perfect, no software is :rolleyes:

Here is the problem, and yes it is a problem, I've seen it happen with HTL and multihack (although that is used mainly in the ubb community). Using a system like this leads to one of three things:

1) Hack author has to do double the work by providing a method to install his hack via the 'installer system' in addition to including a way to install it without said system.

or

2) End user must install 'installer system' to install hacks made for it that do not include a txt file (asuming we followed the same rules as we did for htl this would not be allowed in the first place)

or

3) Asuming there is a way to extract a .txt (or some other form of installtion manual be it html or pdf or whatever). The end user would have to install the 'installer system' just to generate said file.

I almost forgot the most important point, the code base is always changing, which means we (the vB.org staff) would not only have to code the proposed installer system, but would have to patch it everytime the code in vB changed in some way that would render old installation methods useless. All of this while insuring 'legacy' hacks would still work with the new code.

Like I said it sounds good in concept, but it doesn't work in real life. You might get it to work with a few of your servers, but remember that no two servers are alike, and many customers that use vB have no control of their server beyound simple things like ftp, sql managment, and some form of control panel.

Good point. Fsck the images ;)
NONONO! The only accessing would be from the client server to your server, not the other way around. I think you misunderstood me the first time.
I have posted this multiple times? :O News to me... lol.
To make this hack compatable all that a user would need to do is make their hack installable/upgradeable/uninstallable via do=install/do=upgrade/do=uninstall respectively
Huh?
I will respond to this after the fireworks :-P
[edit]The proposed installer system would take about 30 minutes to make and 1 hour to test. In addition, you would never have to patch it or make sure that legacy hacks would still work. This hack doesnt do any installing, it is just the middle man.[/edit]
it only requires FTP

Here is what you have proposed...

Never mind the fact that you didn't mention file edits, which a lot of hacks will still do (you guys give plug-ins to much credit..). I will assume you meant to include this, because not doing so renders the whole thing useless imho (maybe not totally useless, but it certainly would not cover everything).

Just to make sure we are on the same page here, this is what I gather from your post:

User clicks install at vB.org hack thread -> User is redirected to his admincp and loads the php script that fetches the hack's files from vB.org -> after files are fetched the files are un packed and ran through an installing php file that does the needed edits.

Now this sounds nice in concept (like I have said multiple times), but it just doesn't work in the real world because it causes more problems then it fixes.

First and foremost all hacks would have to be released in a standard format to work with said installer. You can't throw random files at a script now can you? This has to be done to insure the script will work there is no way around it.

This poses problems for the author.. What if I want to do something that is impossible due to a limitation in installer system? More often then not the author would probably opt not to use the installer system all together in this case, and just release his own instructions.

The next problem like I said before are large files. Php scripts can only run for so long before they hit the internal timeout setting. This is not a problem in most cases but when you are dealing with file transfers it pops up very often. This is the same kind of thing you run into when uploading large attachments.

While it can be argued that a server is going to have a bigger pipe and thus will download these files quicker, we can't overlook this issue and would have to build a lot of error checking to get around it.

All of that still assumes a perfect connection between vB.org's server and the one hosting your vBulletin. What if vB.org goes offline in the middle of a file transfer? As there is no way to monitor a file transfer as it happens in php the end user is going to run into a timeout error.

Yes I am sure that would go over well with the authors...

It may not have been you, but I've seen it posted a number of times in the past week when someone brings up an exploit. It is a useless point, it's the same as someone pointing out a bug in firefox for windows and me coming back with 'I can show you x number of exploits in windows'.

Which as I said before, this would require standard file formats and standards enforced inside of these files (xml perhaps?). You can't give the author total freedom in the way they prep/release their work and expect an automated installer script to work at the same time!

As I said before an automated installer requires the files to follow certain standards, ones the php script will expect and be able to pick up on. No matter how nice the automated installer is there are going to be a large number of users that prefer to do installation the 'hard' way, that is following a .txt (or .html) and do the needed modifications by hand.

What about these users?

Look at the whole HTL situation we had not to long ago. A lot of users liked the fact that this hack made it easier to install hacks, and began releasing their hacks to work with the hack tracking log, many of them not including .txt file for people that did not have the HTL hack installed. This got the rest of the users angry because there was no way to install these hacks without installing the HTL hack, something they did not want to do.

Eventually this rule was made:

We are basically faced with the same situation here.

30 minutes to make and 1 hour to test? Do you honestly think we would put something online like this after only 1 hour of testing? If the proposed system is going to do SQL queries that is one very large backdoor waiting the happen right there.

Please keep in mind that this is not your normal forum, any mistake made by us can hurt Jelsoft's reputation very badly. I would really hate to come online one morning after this is released only to find a large number of vB's cracked (I use the term lightly here..) due to some oversight in our code. This wouldn't be very good for Jelsoft nor would it be good for us....

It would have to do the installing, we can't pass random files to the scripts and expect it all to work. The automated installer would have to look for certain text in our standardized file format then take that needed text and run the operation it was created for (run a query, add a template, add a word, move file to certain directory, etc).

Things change between version, in time the system would have to be patched, on both ends as a matter of fact. We would also have to re-build the entire thing over again every major upgrade (2.x -> 3.0.x -> 3.5 begin major upgrades).

And giving php scripts permission to write to certain folders (something that you don't have to do durring a vB installation). While most all ftp clients come with chmoding ability, hardly any newbie I've come across understands the concept until they are forced to learn it. Not to mention requiring the use to use an ftp program defeats the point of plug-in's that can be installed via the admincp only (something that won't be possible under an automated installer as the end user needs to ftp in to install the automated installer).

I'm not trying to target you or bash your idea, I'm just trying to show you why it doesn't work in the real world. You are making this sound way more simple then it would be.

Jelsoft will not support any hack or plugin whether it modifies the code or not. The only reason plugins do not invalidate support is because they can be turned off.

The "Support" checkbox is to signify that the hack/plugin author will provide support for their modifications via this forum. And yes this is a big deal to many people.

Well, I think some kind of installer System would be useful for both sides - Autors and Users.
Even for a medium-sized Hack, it's a pain in the Ass having to write dozens of "Create a Template with the following Content", "Create the following Phrase", etc. Instructions.
And it takes ages to install a Hack this way.
Best thing would be an installer here, but not everybody is willing and/or able to do so.
It is not that hard to write a system that could support a large scale of Hacks while keeping it easy for the Author and the User.
If Jelsoft could provide some standard Interface to Export and Import Phrases/Templates/Settings, tha would be a large Step forward.
In fact the basic functions are there already.

you have my vote

an installer system would be great...
but, it's success depends on who creates/supports it

a vb.org installer would definately be successful

I'm still abit baffled as to why my Soft Deleted Archive was moved to Code Modifications, when the last entry in the Features say "NO Code Modifications needed!".
By the definitions of the Subforums, it is an Extension.
For all the lazy staff, https://vborg.vbsupport.ru/showthread.php?t=90840 is the link. Now shoo, and go do your job :p

Ah nice to see some order in place

Could we have a tick box added to the [first post] classification list for "Adds/Modifys Third Party Files" :)

I second the motion
:cool: