Is it too soon for Feature Suggestions?

[minute]

*Hyperlink the words in the definitions to entries in the directory

Install was easy. Looks like fun. thanks.

[David]

Alright, the first post!
Actually, we had another forum that got overrun by spammers, so I had to move it over here.

[seothatworks]

Btw. David, I have just spotted the Mortgage Dictionary demo site is not working.

[Wazoo]

Content visible to registered users only.
Actually I was hoping that you were going to move the non-spam posts from that forum to here .... apparently not ...

[amateur]

I have more than a dozen suggestions for feature enhancement. But most of them are specific to my own project (I will post here when ready).

But, I thought that it is pertinent here to post two or three of my suggestions.

The first is related to htmlesc function utilizing built-in htmlspecialchars function. This function strips all html code off from the descriptions, comments, etc. thereby depriving the script of its great potential for a more enhanced look and functionality for the shake of security. For example, such html codes as bullets, lists, bolds, italics, etc. would feel more professional. Dictionary creator/editor should be able to add bold, italic, etc. to the text. I think that simply cancelling the htmlesc would solve this problem, but at the same time would pose a security risk.

The second one is also related to the above function: Ability to include links in the body of text either to other definitions, or to images, etc. as the case may be. For example, one can add an illustration to the definition, a link to other terms in the database (see also, compare, etc.) or an external link to some other sources, etc.

And yet, another closely related feature suggestion (this may be difficult, I admit): auto crosslinking. Such a feature would be a revolutionary improvement, imho. What I have in mind by auto-crosslinking is this: A function would check the words in text of the definition against the database, and automatically generate links to other terms included in the database. This would save the dictionary creator from the burden of manually editing thousands of crosslinks. For example, I have a comprehensive dictionary of some 6,000 terms specific to a certain field of science. And it has more than 15,000 crosslinks (see also, see, compare, contrast, etc.).

I myself try to add a "see also" and "compare" sections with additional fields, but as I said in another post, I am a newbie, and it is a difficult task for me. Even if I can manage this, it would be a rudimentary solution.

What do you think David? I paid my first $25 for the script. And I am ready to pay another $25 for such feature enhancments.

[David]

Hi, I can discuss this with one of my staff and see what we can do for you.
First of all, let me ask this:
Last I checked tags like a, b, i, li and ul are allowed.
For example, take a look at this comment with a link in it:
http://www.mortgage-dictionary.com/PITI.html
So please answer this, and then we'll see what new features can be added.

[amateur]

Hi David,

Thank you for your quick response.

I just checked if it shows bold, italic, etc. To this end, I pasted the same (html coded) strings to both description field and comments field. Also, I cancelled htmlesc function for "word_descr", while retaining it for "word_comments." The end result is that word_descr (with htmlesc) displays the text with html codes, i.e., html codes are visible as a part of the text string. But word_comments field displayed the text with properly functioning tags. I.e., a, b, i, li and ul tags are not functional with htmlesc.

Kind regards,

[amateur]

I am sorry for misleading the visitors, since I realized that originally the LNtoBR is used for word_descr and word_comments fields.:o Therefore, David is right in saying that the html tags are functional in these fields. I should have replaced LNtoBR by htmlesc for security concerns (as I plan to enable visitors to contribute to the dictionary).

Eventually, an elaborate function is required that would selectively filter out certain code patterns (such as javascript) from the text, and yet allow basic html tags for formatting and styling the definitions and/or comments.

[David]

I have a new release ready. I'll try to post it later today.