![]() |
Official definitions of "hack" categories.
Quote:
Queries to alter the database can be run from the admincp. Does that fall under plugin? Do queries matter? |
Quote:
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. :)
|
Quote:
|
Quote:
|
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.... |
Quote:
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
great work everyone :up: can't wait to see the new vb.org :D |
Quote:
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 |
Quote:
The extensions forum is not showing things in the "hack" format |
Quote:
|
Quote:
|
Quote:
|
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. |
Quote:
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 |
Quote:
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 |
Quote:
|
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). |
Quote:
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 |
Quote:
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. |
Quote:
|
Don't think so.
You can install Phrases, Templates, Settings and Queries through ACP only - no FTP access required. |
Quote:
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. Quote:
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 ;)
Quote:
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 |
Quote:
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. |
Quote:
Quote:
Quote:
Quote:
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. |
All times are GMT. The time now is 03:51 AM. |
Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
![]() |
|
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|