Official definitions of "hack" categories.

[tamarian]

Categories 1 and 2 can be done using AdminCP only.

Many of the hacks residing in "plugins" right now require an "installer" file to be uploaded, and/or some queries be made to alter the database.

Queries to alter the database can be run from the admincp. Does that fall under plugin? Do queries matter?

[Erwin]

Many of the hacks residing in "plugins" right now require an "installer" file to be uploaded, and/or some queries be made to alter the database.

Queries to alter the database can be run from the admincp. Does that fall under plugin? Do queries matter?
You make a good point... :) What do you think? Remember, these definitions are not set in stone and are fluid.

My opinion is that such plugins will still be plugins since the installer strictly speaking is adding only templates, phrases and queries, which are all doable in the AdminCP. :)

But that's what I think... remember, these are in the end artificial classifications, and are meant to help us, not confuse us! :)

[Dream]

can these be moved to extensions please

Reset most users online from the AdminCP (https://vborg.vbsupport.ru/showthread.php?t=91351)
Import/Export BBCodes (https://vborg.vbsupport.ru/showthread.php?t=91435)
Custom Template Manager 0.3 (import, export, mass copy, mass delete) (https://vborg.vbsupport.ru/showthread.php?t=91038)
Read PMs (https://vborg.vbsupport.ru/showthread.php?t=91369)
View XML 0.2 (https://vborg.vbsupport.ru/showthread.php?t=91224)
JavaScript Tester Console (https://vborg.vbsupport.ru/showthread.php?t=83465)

and I think database changes should be considered code changes, unless database changes are categorized aswell.

edit: and this is not a plugin vBulletin Google Site Map (https://vborg.vbsupport.ru/showthread.php?t=91389)
edit: this is not a plugin either Multiple Option BBCode (https://vborg.vbsupport.ru/showthread.php?t=90869)
edit: not a plugin, has db changes whodownloaded this attachment (https://vborg.vbsupport.ru/showthread.php?t=91390)
edit: not a plugin, has db changes Attachments in private messages (www.vbulletin.org/forum/showthread.php?t=91220)

[tamarian]

It could go either way, just thought the definition should eventually decide the case.

IMHO, query alterations is an added complexity level for a plugin beyond adding a template or a phrase.

Strictly speaking, I think there are ways one could add a plugin to upload php files on the ./temp directory or other writable directories, so they won't require FTP access, but that would streaching the definition too much :)

[Paul M]

What about hacks that integrate vB with other systems, and require code changes to non vB files ? I classed mine as a code change, because file edits are required, just not to source vb files. :)

[Erwin]

What about hacks that integrate vB with other systems, and require code changes to non vB files ? I classed mine as a code change, because file edits are required, just not to source vb files. :)
I would consider it a hack addon and an extension - basically since no vB source code is changed, your hack does not actually make it difficult to upgrade or affect official vB.com support. :)

[Paul M]

I would consider it a hack addon and an extension - basically since no vB source code is changed, your hack does not actually make it difficult to upgrade or affect official vB.com support. :)That forum is not displaying things as hacks or installable - can you fix that please.

[Christine]

I don't believe dB changes affect vB support like modifying files, but I could be very wrong on that. Erwin?

Adding to the dB can be tricky to classify as adding tables are not (IMO) the same issue as adding to tables, but my preference would be to put dB mods with the plugins and not in with code changes.

[Frenck]

Except for the DB discussion, I'm happy with it! Nice work.

My point of view is: DB changes don't matter....

[Revan]

You make a good point... :) What do you think? Remember, these definitions are not set in stone and are fluid.

My opinion is that such plugins will still be plugins since the installer strictly speaking is adding only templates, phrases and queries, which are all doable in the AdminCP. :)

But that's what I think... remember, these are in the end artificial classifications, and are meant to help us, not confuse us! :)I think these kind of mods should be called extensions, since they do require file uploads.

Soft Deleted Archive (https://vborg.vbsupport.ru/showthread.php?t=90840) is an Extension. Could you move it, please? :)

[Andreas]

@Christine
What should be the difference in adding a field to an existing table and adding a new table?
If Jelsoft ever decides to use the same field- or tablename you will run into problems ...

Personally I think DB modifications don't qualify as a reason for classifying a Hack as "Code Mod".

[Princeton]

Keep it simple...
the less text to read the less you will confuse
Template Modifications - Includes templates and/or phrase modifications only.

Plugins - Uses the hook system - can be installed via the AdminCP. May include template modifications.

Extensions - FTP access required for file uploading. May include plugins and template modifications.

Code Modifications - Addons that requires source code modification(s). May include extensions, plugins, and template modifications. Official vB support not available.

great work everyone :up:
can't wait to see the new vb.org :D

[Brad]

can these be moved to extensions please

Reset most users online from the AdminCP (https://vborg.vbsupport.ru/showthread.php?t=91351)
Import/Export BBCodes (https://vborg.vbsupport.ru/showthread.php?t=91435)
Custom Template Manager 0.3 (import, export, mass copy, mass delete) (https://vborg.vbsupport.ru/showthread.php?t=91038)
Read PMs (https://vborg.vbsupport.ru/showthread.php?t=91369)
View XML 0.2 (https://vborg.vbsupport.ru/showthread.php?t=91224)
JavaScript Tester Console (https://vborg.vbsupport.ru/showthread.php?t=83465)

and I think database changes should be considered code changes, unless database changes are categorized aswell.

edit: and this is not a plugin vBulletin Google Site Map (https://vborg.vbsupport.ru/showthread.php?t=91389)
edit: this is not a plugin either Multiple Option BBCode (https://vborg.vbsupport.ru/showthread.php?t=90869)
edit: not a plugin, has db changes whodownloaded this attachment (https://vborg.vbsupport.ru/showthread.php?t=91390)
edit: not a plugin, has db changes Attachments in private messages (www.vbulletin.org/forum/showthread.php?t=91220)
Thanks we will move them as we get to them, they should all be in the correct forum soon enough :).

If you find anymore could you please report the post instead, this will allow us to keep up with the threads as they are moved and makes it a little easier on the staff to keep up with each other's actions.

[Chris M]

Good to see some definitions popping up :)

I suspect there will always be ambiguity as regards the status of certain modifications, but this new system should remove most of that :)

I suppose if you are unsure of where to put it, you put it where you feel it belongs, then get a staff member to check over it, and let them decide - They can always move it :)

Satan

[Paul M]

That forum is not displaying things as hacks or installable - can you fix that please.* Bump * Did this get missed ?

The extensions forum is not showing things in the "hack" format

[zetetic]

@Christine
What should be the difference in adding a field to an existing table and adding a new table? If Jelsoft ever decides to use the same field- or tablename you will run into problems ...

Personally I think DB modifications don't qualify as a reason for classifying a Hack as "Code Mod".
I think she was asking whether db changes invalidate Jelsoft support, which I wonder too.

[Andreas]

* Bump * Did this get missed ?

The extensions forum is not showing things in the "hack" format
We are aware of that, but Xenon wasn't available yet :)

[Paul M]

We are aware of that, but Xenon wasn't available yet :)Fair enough, since no one responded, I was not sure if it was missed. :)

[Cloudrunner]

I've read through this thread and still have a question regarding the DB, I can understand adding to and taking away from rows in the templates not being classified as a code mod, but how about when ALTERing a table, since that effectively changes the coding of the site?

for example, in my donations mod, there are two additions to the user table, donor and showdonor. Each are needed for the system to work, but since this required the use of an ALTER statement, thus changing the original coding of the installation, I would regarding this as a code modification.

IMHO, if the DB changes are merely additions to or removal of rows within a DB table, and do not effect the schema of the DB or the table, then I would consider this to be an extension, whereas if the table is modified using an ALTER statement, then it would be a code modification due to the fact that you are changing the original code for the default installation, which could lead to upgrade difficulties...

[Andreas]

It could lead to problems, yes - but chances are pretty low.
IMHO the Database schema should be considered as Data, but not as Code.

[Christine]

@Christine
What should be the difference in adding a field to an existing table and adding a new table?
If Jelsoft ever decides to use the same field- or tablename you will run into problems ...

Personally I think DB modifications don't qualify as a reason for classifying a Hack as "Code Mod". Don't most table-addition hacks use prepended or specific naming conventions (Like vbouncer)?

I haven't added many releases to know how common that is, but in the additions I have made, I always prepend the tables. Example was my persistent mark read system -- I prepended the table with rr as rrmarkread.

I agree that dB mods should be categorized as plugins, but am suggesting that the definition should be driven by vB policy on what they consider invalidating their support, not by the difficulty of making the change.

That way, folks looking to enhance their system (but not wanting to invalidate their support) will know to stay away from the category "code changes" (or whatever) as anything in there will be classified as requiring changes that vB considers 'hacks' to the core system.

That was where I was going with the 'adding a table' vs 'adding to a table' comment.

Does that make sense?

[Marco van Herwaarden]

Sorry but i will have to disagree with that. The database schema should be considered as part of the code. In some cases an addition to the data, could even be considered as such (think about usergroup permissions for example).

[Christine]

I posted this question on vB to see what the policy is:

http://www.vbulletin.com/forum/showthread.php?t=145472

[Wayne Luke]

I don't believe dB changes affect vB support like modifying files, but I could be very wrong on that. Erwin?

Adding to the dB can be tricky to classify as adding tables are not (IMO) the same issue as adding to tables, but my preference would be to put dB mods with the plugins and not in with code changes.

As adding to the database will not affect the working of the default PHP scripts, it will not invalidate support. Adding to the database though often requires modifying one or more PHP scripts which would invalidate support. If those modifications are accessed through plugins, then support would be active. Please note, that unless you provide an unique identifier to your table or field names, it can prevent future upgrades as the developers will not take these modifications into account when adding features or optimizing the database schema as needed. In order to receive support, you will need the default files for vBulletin uploaded.

Purposefully, removing fields or tables from the default installation can and probably will invalidate support.

[Christine]

Thanks Wayne!

Given this, I would vote for dB changes to be categorized with the plugins. :D

[Xenon]

just put the in the plugins section.

there is already a checkbox "DB changes" so users can decide themselves when seeing a hack :)

oh, and the forums are working correctly now

[sabret00the]

You make a good point... :) What do you think? Remember, these definitions are not set in stone and are fluid.

My opinion is that such plugins will still be plugins since the installer strictly speaking is adding only templates, phrases and queries, which are all doable in the AdminCP. :)

But that's what I think... remember, these are in the end artificial classifications, and are meant to help us, not confuse us! :)
how about an official vb.org installer uploader, a script that will upload to the installs folder and even unzip it then that way the installers can be uploaded via the admincp, should that be the only ftp'ing needed.

[Ron1n]

Hrmph, how about you just have everything in one forum and have each mod have the following listed in the forum-view:

adds files: y/n
Modifies code: y/n
Modifies database: y/n
modifies templates: y/n
modifies phrases: y/n

You could have a little code or picture key for it so it doesnt take up much space.

IMHO separating these forums just creates more confusion than there needs to be.

[The Geek]

Macks should be categorized based on functionality - not on how it affects the backend.

I agree that this information needs to be apparent, however people decide on the macks they want based on what it does - not how it does it.

Just my thoughts ;)

O yea - and I couldnt agree with saber more. I think its just as important to provide a common mechanism for installing/uninstalling a mack as it is to provide hook capability. Sure you can only do so much at one time - however it would be cool to know that this was a possability being looked at.

Funny thing was that when I first ventured here, I stupidly assumed that clicking the install button would somehow literally install it (i.e. I would download a single file and upload/unpack it via my admincp)... then again I also thought that it would do my laundry if configured right (still working on that mack).

[Chris M]

Macks should be categorized based on functionality - not on how it affects the backend.

I agree that this information needs to be apparent, however people decide on the macks they want based on what it does - not how it does it.

Just my thoughts ;)

O yea - and I couldnt agree with saber more. I think its just as important to provide a common mechanism for installing/uninstalling a mack as it is to provide hook capability. Sure you can only do so much at one time - however it would be cool to know that this was a possability being looked at.

Funny thing was that when I first ventured here, I stupidly assumed that clicking the install button would somehow literally install it (i.e. I would download a single file and upload/unpack it via my admincp)... then again I also thought that it would do my laundry if configured right (still working on that mack).
Something that may be possible is for someone to create a "Admin CP Hack Installer" modification :)

Basically, you can "create installers", which create a .xml file or other file with the template and queries you wish to run - You put this in your .zip file for users to run

They upload it to the installer, and the installer executes the templates and queries, therefore requiring no ftp access apart from to install the actual auto-installer :)

Satan

[Andreas]

Something that may be possible is for someone to create a "Admin CP Hack Installer" modification :)

Basically, you can "create installers", which create a .xml file or other file with the template and queries you wish to run - You put this in your .zip file for users to run

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.

[Dream]

Something that may be possible is for someone to create a "Admin CP Hack Installer" modification :)

Basically, you can "create installers", which create a .xml file or other file with the template and queries you wish to run - You put this in your .zip file for users to run

They upload it to the installer, and the installer executes the templates and queries, therefore requiring no ftp access apart from to install the actual auto-installer :)

Satan

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

[Andreas]

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

[Ron1n]

Macks should be categorized based on functionality - not on how it affects the backend.

I agree that this information needs to be apparent, however people decide on the macks they want based on what it does - not how it does it.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.

Funny thing was that when I first ventured here, I stupidly assumed that clicking the install button would somehow literally install it (i.e. I would download a single file and upload/unpack it via my admincp)... then again I also thought that it would do my laundry if configured right (still working on that mack).

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/hackinstaller.php?do=download&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!

[Chris M]

Sounds excellent Kirby ;)

wouldnt that be cheating on the hack definitions tho?

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

[The Geek]

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 ;)

[tamarian]

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)

[Andreas]

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

[Brad]

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/h...load&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!

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.

[Ron1n]

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

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.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."

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.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?

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.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.

[Brad]

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."

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.

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?

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:

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.

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.

[Ron1n]

What about hacks that include many images, lots of php/js/whatever files?Good point. Fsck the images ;)
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.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 think I've seen you post this multiple times now, it is a moot point.I have posted this multiple times? :O News to me... lol.
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.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
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) Huh?
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.I will respond to this after the fireworks :-P
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.
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.it only requires FTP

[Brad]

Here is what you have proposed...

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/h...load&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!

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.

Good point. Fsck the images

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

I have posted this multiple times? :O News to me... lol.

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'.

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

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!

Huh?

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:

Regarding hacks that use the HTL hack, you MUST supply a seperate text file for people who do not have the HTL hack installed. If your hack does not follow these rules, we will delete it until you supply text file instuctions. If your hack DOES include a seperate text file, then please add in your hack title, [HTL] & [Normal] as the prefix.

We are basically faced with the same situation here.

The proposed installer system would take about 30 minutes to make and 1 hour to test.

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....

In addition, you would never have to patch it or make sure that legacy hacks would still work. This hack doesn't do any installing, it is just the middle man.

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).

it only requires FTP

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.

[Wayne Luke]

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 ;)

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.

[Andreas]

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.

[Princeton]

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

[Revan]

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

[Hialls]

Ah nice to see some order in place

[Paul M]

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

[Mr Blunt]

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

[Cap'n Steve]

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.

[Revan]

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

[WetWired]

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.

[Andreas]

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 ...

[The Geek]

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 :)

[Marco van Herwaarden]

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

[The Geek]

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.

[Andreas]

@The Geek
My Advanced Plugin Manager (https://vborg.vbsupport.ru/showthread.php?t=91384) (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.

[The Geek]

@The Geek
My Advanced Plugin Manager (https://vborg.vbsupport.ru/showthread.php?t=91384) (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.

[Erwin]

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

[Guest190829]

@The Geek
My Advanced Plugin Manager (https://vborg.vbsupport.ru/showthread.php?t=91384) (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.

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

[Cap'n Steve]

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.

[Andreas]

Ah, I didn't even realize that the plugin system could take care of phrases and other queries.
Well ... in fact it doesn't :)

[Paul M]

Could we have a tick box added to the [first post] classification list for "Adds/Modifys Third Party Files" :)Since no staff commented, I assume this request got missed.

[Marco van Herwaarden]

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.

[Cap'n Steve]

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 ...

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

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. :(

[Paul M]

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.Okay. :up:

[Xenon]

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

[Christine]

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. :( 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!

[tamarian]

This hack is still listed in code modifications:

https://vborg.vbsupport.ru/showthread.php?s=&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.

[Chris M]

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

[tamarian]

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.

[Chris M]

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

[tamarian]

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

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


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.

[Chris M]

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

[tamarian]

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

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

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.

[Chris M]

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

[Regs]

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

[Chris M]

My signature?

No images missing here o_O

Satan

[Xenon]

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 :)