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:

The only thing I worry about is that some users will get confused. I've heard several people mention that they will only be installing plugins from now on, and with these definitions, a lot of hacks using installer scripts will be excluded from that category.

Since you guys apparently think FTP access is a big hurdle to overcome, we need an installer system. The problem is, it needs to be made by Jelsoft. Having an offical installer will bypass the problem of having to install an extra hack to use the hack you want.

And given that they don't support modifications, the chances of that happening are small, Id say :p

Well, no, the entire plugin system indicates that they support the existance of modifications, what they don't support are individual modifications or boards with active modifications. Providing official mechanisms for bulk query execution and bulk template and phrase addition do nothing to change their stance on any of these, nor would providing a system that would support uploading a single XML file that contained several of these and handling them all appropriately.

As far as uploading additional php scripts and images or running actual install scripts that are more than just a bunch of calls to $DB->query_write, I don't think that will or should happen.

It is not really necessary to have an "install backend" (be it official or a custom Hack) to provide easy installation without having upload an installer.
Everything can be done with just the Plugin XML File, but creating such a XML manually is a PITA ...

True, however xml files are easily generated by other files.

If vB had a plug-in pluginer that read the contents of an xml file, installed phrases and templates (even better if it would run queries too - however I could understand reluctance toward that) then a mack could easily be created that would allow you to store your mack in development in tables, and export the mack as an xml file to be read by the vB plugin pluginer.

hmm. Just think I lost myself there :)

Could someone create a plugin that could parse this into readable text. :D

man alive. I must cut down on the crack for lunch :)

Here is how I figured it could work:

vB has a mack installer.
The installer would deal with new phrases, phrasegroups, plugin code, templates and optionally running queries.
Macks would then come with as an XML file listing all of these things.
vB could cache the xml file for later removal if needed.

The real butt pain as was previously mentioned is that complex XML files are a bummer to create.

That is until a mack maker is released.
The mack maker would simply be an admincp page that would:
Allow you to create a 'project'
Define the phrasegroups and phrases
Define the templates
Define the plugin code
Optionally define DB queries
It could then persist these into a table(s), click 'generate' and viola! It could create the xml for you.
A mack maker wouldnt be too hard to make and I am sure the community would take care of that in no time. However that would be dependant on vB creating an installer that at least handled more than just doing the plug in code.

Whew.

@The Geek
My Advanced Plugin Manager (currently under heavy development) does all that :D
It creates XMLs that can contain Phrases, Settings, Templates, Queries/Install-Code - and to install these it requires nothing except a vanilla vBulletin 3.5
However, if the User has installed APM he gets some extra Goodies like Grouping of Plugins, setting Execution-Order, Descriptions, etc.

looks groovy to me.

Uh... try not to go too off-topic here. :)

Kirby, Did I ever mention that your my hero? :)

Ah, I didn't even realize that the plugin system could take care of phrases and other queries. I guess my criticism is invalid now, those categories look pretty good.

Well ... in fact it doesn't :)

Since no staff commented, I assume this request got missed.

We are currently working on a new modification database. This will be completly attribute based. We will review this thread for all attributes that might be wanted for modifications once this systemm is finished.

Ok, now I'm confused. Didn't you just say you could include phrases and such in the XML and they would be added automatically? Sorry, I have no license at the moment so I haven't seen the new system. :(

Okay. :up:

on the other hand: it doesn't hurt to add the checkbox now, so :)

Yes, you can use the plugin .xmls to install phrases (with the appropriate queries).

I have seen it -- nothing my mind could have _ever_ come up with (and I barely follow it) -- but it works and it is slick. Credit KirbyDE for figuring this one out as well. He is becoming the master of the plugin system. LOL!

This hack is still listed in code modifications:

https://vborg.vbsupport.ru/showthrea...threadid=83316

It's purely xml based, one xml for the plugin, and another for the bitfields, plus the installer.

I've reported it twice in the last two weeks, and it's still there. If you guys are back-logged, no problem. If it's actually deemed a code modification, I'd like to know for which part.

To add onto this:

I released an Extension earlier, but it shows up as a Code Modification in my profile ;)

Should say "Extension" :D

Satan

That's different. Anything that is not a plugin, will show as a code modification on the profile.

But if you click on those shown as code modification, they'll take you to the extensions forum or one of the others. So among a few in my profile that are shown as code modifications, only 2 reside in the code modifications forum. One does belong there, sicne it is a code modification, but the other is just xml, and either belongs in plugins, or extensions.

Shouldn't it show up as an Extension though because of the new categories?

Because an Extension doesn't modify any existing vBulletin code;)

Satan

Sure. But I don't think the new categories are/will be listed in the profiles. Sort of like the vB3 divisions into two categories, hacks and addons.

It may look a bit odd to divide into seperate headers for each category. But if there's a new column in the list, showing the sub-forum where it resides, this may look better.

Well Plugins, Templates and Styles are listed seperately...

It's only natural to assume Extensions would be :)

Satan

I did not think of that.

So say someone released (for 3.5) a plugin, an extension, a code modification, a style and a template. Those would be listed as 5 items on 5 rows, with 5 other rows as headers for each category. Seems a bit long for a list, 10 rows for 5 items. But not too bad I guess, since you're looking for details when you click on a member's profile.

Alternatively, they could be listed on 5 rows, with a new column stating the subforum, or better yet, an icon for each category.

Yeh - But if you take a look at my profile for instance, there are over 40 vB2 hacks that are listed and that is almost as annoying as having 5 rows and 5 headers ;)

The advantage though is that at least they are collapsable :)

Satan

What's annoying is your fricken signature that takes forever to load due to a missing image :mad:

My signature?

No images missing here o_O

Satan

The profile is not build to divide between extensions and codehacks, as the extensions part was not really planned in my codings.

of course i can add an extra header, but as said several times now, we are working on a whole new system, which will make it a lot easier to do such things :)