Official definitions of "hack" categories.
 

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

can these be moved to extensions please

Reset most users online from the AdminCP
Import/Export BBCodes
Custom Template Manager 0.3 (import, export, mass copy, mass delete)
Read PMs
View XML 0.2
JavaScript Tester Console

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
edit: this is not a plugin either Multiple Option BBCode
edit: not a plugin, has db changes whodownloaded this attachment
edit: not a plugin, has db changes Attachments in private messages

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

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

That forum is not displaying things as hacks or installable - can you fix that please.

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.

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

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

I think these kind of mods should be called extensions, since they do require file uploads.

Soft Deleted Archive is an Extension. Could you move it, please? :)

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

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

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.

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

* Bump * Did this get missed ?

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

I think she was asking whether db changes invalidate Jelsoft support, which I wonder too.

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

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

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

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?

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

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

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

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.

Thanks Wayne!

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

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

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.

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.

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

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.