*** HTL Suggestions ***


Suggestion Legend
----------------------
Discussed for inclusion in a future version (not necessarily next version)
On To Do List for next version release
Not likely to be implemented -- (reason given, if any)
Comments from the man himself (KuraFire) ;)

**NEW**: Updated 1/31/04.

Manage Hacks

Edit Hack details:

Hack Version: Add <dfn> to note that "v" (for version) is automatically added
Difficulty rating to install this hack: Change to drop-down, or list examples of suggested ratings (to keep consistency in hacking community). Ratings options:

1 - 5 (1 = Easy / 5 = Hard)
1 - 10 (1 = Easy / 10 = Hard)
Beginner, Intermediate, Advanced
Novice, Average, Expert
Easy, Normal, Hard
It will be: Very Easy, Easy, Normal, Hard, Extremely Hard


Edit Steps:

Modify: File and Template edits:

Option to mark file edit as "SQL" so that comments will be SQL comments ("--") instead of PHP comments ("//") -- Adding MySQL comments to queries slows them down.
Add a "remove old code only" option to edits, or allow blank "new code"
For "removed" code (i.e. - new "remove" option above or blank "new code"), modify [start] / [end] comments to be [lines removed], or do not display "new code" section in installer / mods list -- it will probably be something like [start] [x lines removed here] [end]
**NEW**: Ability to specify number of "Mods" (file / template edits) and have that number of edit sections display on Hack Manager --> Edit Steps --> Modify: File / Template edits (instead of having to "save" every 2 edits to get more boxes)
**NEW**: Admin Option - Separated file and template edits
**NEW**: Option / ability to order the edits (manually, instead of the default alphabetically)


Generate Installer:

Stand-alone PHP Installer generation / utility (i.e. - PHP "pretty" installer for the new templates, phrases, etc. but without needing to have the HTL pre-installed, possibly a more generic form of XML importer / hack installer to be optionally distributed with hack install) -- would undermine the goal and essence of the HTL.
Compressed HTL generation / download (for large hacks for people on dial-ups) -- HTL downloads are extremely small, even dialup should have no problem with a major hack.
**NEW**: Ability to generate "upgrade" .htl files that would update the HTL record, install changes, and list new template / file edits for "upgrade"




Install Hack

**NEW**: Ability for new templates to import into all / selected styles (instead of just default style)



List all modifications

Option to list edits by file / template (either all on a page, or like "by Hack" option) -- this section will have a completely new interface for sorting options, Listing by File or Template will be one of the new methods



Front End

**NEW**: Make front end an add-on (instead of prepackaged with HTL) for those that don't want the added templates and phrases used with it
**NEW**: Ability to "View Hack" from Hack Manager without Front End enabled (admin-side one for Hack Manager?)



General

Move some of the "function" / "includes" files edits to their own files and just have the file edit be an "include" of the new files
HTL Admin Help Topics Add-On (for those that want it, and for those that don't)
Template Only Mod options (for those that aren't "truely" hacks):

Ability to mark a mod / "hack" as a template only mod on hack edit screen (or a "add new hack" and "add new template mod" button choice)
Displays as "hack" or "template mod" on manager
A "make vbtemplates.com post" option instead of "make vborg.com post" option for template only mods
If you go with the different "add" buttons (vs the checkbox), a toned down edit page (same code with some "if"s around the hack specific stuff, i.e. - no module, no menu items, take out some step options, no settings group, no files stuff, no table stuff)
If you go with the different "add" buttons (vs the checkbox), no edit menu links, take out some step options, and take out some step instructions options

**NEW**: New "Temporary Phrases File System":

New "Edit Hack details"? option: a switch to denote which "phrases" file is being used
New phrases file structure with nested arrays to specify phrases going into different phrases groups (i.e. - GLOBAL, cphome, and / or newphrasegroup?, see post (http://www.everythingvb.com/showpost.php?p=188&postcount=7))
Temporary phrases file management / creation / editing

**NEW**: Option to view *all* details / changes of hack (i.e. - new templates / files (possibly links to see code of file) / phrases and all mods / edits for hack
**NEW**: Ability (admin cp option?) to have no hack info saved into database and either read straight from .htl files and / or temp files created by HTL for quicker "processing" / accessing
**NEW**: Support for having different file extensions (i.e. - not .php)
**NEW**: Utility to "download" all hacks installed (including any specified styles, in full) on a forum into a file and install the mass file onto other forum (say for test --> live forums, requiring only the file edits to the "live" forum) and ability to list only the file edits after "install"

Okay, that should be all of the suggestions from the EvB site. Next I will focus on the HTL suggestions on vb.org. First, I think I will work on the ones in the "General" forum, and work on the actual release thread (in the "Hacks" forum) last since it is more active than the rest...

I updated your post, moved the legend to the top and added colors where applicable. :)

I would like the file edit steps to be made so you can specify the number of edits and it will have that many boxes to put in. It is kinda annoying when you have to keep saving over and over and over again to get enough boxes.

I don't really see a problem with that right now, dan. Although I'd really like to see the textfile generator in action.

I'm with Dan. Another small thing I'd like to see is an admin option to seperate template and file modifications when editing a hack.

I would like the file edit steps to be made so you can specify the number of edits and it will have that many boxes to put in. It is kinda annoying when you have to keep saving over and over and over again to get enough boxes. You can already do this with the HTL. Just open /admincp/hackadmin.php and look at the define() rules at the very top. They have explanations with them, you're free to modify those to suit your needs. :)


Squall, I'll look into it :)




Additions of my own (that Nikki may add to the official list when she has the time):


- new Temporary Phrases File system. Hacks will have an additional option: a switch to denote what phrases file is being used.
New TPF will allow this kind of use:


$temp_phrase = array(
'cphome' => array(
'phrase_one' => 'Content of Phrase One',
'phrase_two' => 'Content of Phrase Two'
),
'GLOBAL' => array(
'global_phrase_one' => 'Content of Phrase One for phrasegroup GLOBAL'
'global_phrase_one' => 'Content of Phrase Two for phrasegroup GLOBAL'
)
);


The XML file can be generated that way without the need for using the phrasegroup in the varname.


and more stuff, but I'm too tired now, i go sleep...

Okie dokie... Sorry for the delay, had an issue with work that kept me busy...

I have updated the list with the suggestions from this thread and all the vb.org related HTL threads I found... Everyone check for your suggestions and make sure I have "summarized" them appropriately!


Thanks!

Bah, then I'd have to re-write my temporary phrase file generator... thanks alot Kura... :p

BUG REPORT:

phrases xml generator checks for all existing phrasetypes;
should be: generator does a query for all of vBulletin's phrasetypes only.

This will be incorporated into HTL 1.1

I'd like to see the .htl file format either discarded, or another format added.

In essence I think that hack developers should be given a simpler XML format to create, and that those who implement hacks would benefit from a more human readable format that they are able to step through and understand should anything go wrong.

I'd imagine this to be simple such as:


<hack>
<details>
<hacker vbOrgUserId="37" everythingVbUserId="65">buro9</hacker>
<version>1</version>
<title><![CDATA[Secret Admirer / Crush System]]></title>
<description>A matchmaker system for your users to encourage incestuous behaviour and babies!</description>
</details>
<languages>
<language name="English">
<phrases type="Front End Error Redirections">
<phrase name="dupliacateAdmire"><![CDATA[Sorry, you cannot admire the same person twice.]]></phrase>
</phrases>
</language>
</languages>
</hack>


That only shows a small bit of what it would look like... obviously with sections for template changes, file changes, SQL to execute, etc, etc.

I'll share a little secret with you...

XML replacements for the .htl format were already planned :)

Though it's unlikely that phrases, settings and templates will all go into the one .xml file because that would prevent the HTL from being able to use vB3's own XML Import functions for phrases, settings and templates, and would force me to re-write THEIR functions into new functions that can work with different data input (you can't tell an xml parser to start at position x and stop at position y and treat that as an xml file of its own). Hence, it would still be phrases.xml, templates.xml and settings.xml (which is more useful anyway), but the new feature would be the existance of hack.xml :)
(though there will most likely still be a small .htl file for each hack as well, that contains the initial data for the HTL to know where it can find all of the xml files, etc.).

you can't tell an xml parser to start at position x and stop at position y and treat that as an xml file of its own
Of course you can, it's called XSLT.

Transform just a branch of the hack XML into the VB style to utilise their functions, whilst allowing for hacks to be stored in a single file (not including images, etc obviously).

This would also mean that hack XML files would be future proof, because as long as your middleware layer (the HTL stuff) correctly performed the transform from your known schema to VBs known schema... none of the hack writers would have to rework their XML in the event of the VB schema changing slightly.

That's the reason you use XML... because it syndicates, transforms and transmits data easily.

It's not as efficient though.
Creating one huge hack xml file would take long, VERY long for bigger hacks, and installing a hack would mean I'd have to re-parse the same file up to 5 times in a row. Additionally, it would complicate various other parts of the HTL.

It's still a sound idea, it's just not something I'm willing to work on, all by myself, with time pressure, and no compensation for it. If Jelsoft would be making such a system themselves, they would undoubtedly go for it, but me all by myself, no can do...

Another Good Feature to have is one that is in FireFly's VB2 Hack Manager program. It goes and finds the code in the said pages and addes the code that is needed to be added. I would assume that is would be an option that you can turn off and on as there might be some times where you dont want to use that feature.

No, that's not a good feature, it's a large security leak to have that feature and as such I will not implement it. Sorry. Most people prefer to do file edits themselves anyway (I estimate about 80-85% of the people).

I'd like to mark querys, that may be intensive (mainly ALTER TABLE querys on large tables) as intensive querys, so that the following things will be done/displayed before and/or after the querys:


A warning will be displayed, that the query may be very intensive, with a link to 'more info', while more info could contain a hint, that opens in a JS-PopUp or a new window, like "if the script timeouts, wait a bit and check, that the table has this and that now (e. g. this column/key added/removed). If it does, the script succeeded and you can continue with the next step (next step would be a link, of course). Perhaps with a default hint-text, that could be edited.
the time taken will be determined and displayed as "Query took ss.mm seconds to execute." for example.
other things, that come in mind ;)

The first can already be done by just putting a warning in the Install Instructions for the query step. Javascript-stuff is unnecessary and too complicated to add.

Query execution time is a good idea, I'll implement that for verbose test runs (on a per-query level) and in real installs I'll display a total time taken by the queries.

A checkbox to choose per query to display the time taken or not would be nice, too. The vB-upgrade-scripts have a similar feature, though they're hardcoded there.

During a real install, query time per query isn't really necessary, mostly as it's interesting for development purposes and all, and hardly interesting for the end-user. Cluttering up pages with devel-stuff for end-users is a bad idea. :)

OK, to put it another way: Assume, that there is one query, which is very intensive, then I want to see, how long it took, especially, when I'm testing it locally, before I stress my online server with it. On the other hand I don't want to see other verbose info or execution times for querys, which only took a handful of millisecs and since the developer may think the same, why not giving him the possibiliy the choose, whether to enable this for certain querys or not? atm, there are only 2 choices: loads of verbose info or nothing at all. The vB-upgrade-scripts display this decent verbosity, when running rather intensive querys.
In short: I don't want to see full verbosity, but on the other hand, I don't want to see no verbosity at all.

But I've had an idea while writing this: How about the choice of a 'Real install (minimum verbosity)', which would display the most important verbose info (devs choice, what and where as stated above)? Although I'd prefer displaying the minimum verbosity by default.

I'll add a new setting for admins that enables execution time output during ALL runs, so that those who want it can have it, and those who don't will not. Default will be off.

I'd like to choose the style where new template will be imported to, since at least in our forums this is different to the default style setting in the vBulletin-options.

HTL 1.1 will have a drop-down option allowing you to choose what style(s) to import the new templates in. The default option will be "ALL STYLES"

Unless I'll be able to choose a single style, this would be ok for me, since installiing to all styles would make it harder to manage changes in custom templates :)