Official definitions of "hack" categories.

[Christine]

Originally Posted by KirbyDE

@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]

Originally Posted by 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.

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.

[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]

Originally Posted by Erwin

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]

Originally Posted by 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).

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