Loading...
 
Features / Usability

Features / Usability


Why I activated "Allow HTML" in Wiki and Articles pages

posts: 102

Part I

In another post — A more friendly "create a new page" option?:

http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=18734&topics_threshold=0&topics_offset=4&topics_sort_mode=lastPost_desc&topics_find=&forumId=4

Gary was correct to point out the need to learn the basic syntax of wiki. Damian and Sylvie helped in pointing that "Allow HTML" is possible in both the "Articles" and "Wiki" pages. Damian went further in pointing out the potential danger(s) of activating "Allow HTML":

http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=18684&topics_threshold=0&topics_offset=13&topics_sort_mode=lastPost_desc&topics_find=&forumId=4

Maybe there is a better solution, but here is a reason why sometimes I prefer the "HTML format" for a link instead of using the "wiki syntax".

Using the "wiki syntax", I can easily create a link for "Tikiwiki" using Tikiwiki approach — and then make sure that I create the actual page for Tikiwiki. The only catch is that when I use this approach, when I link to Tikiwiki, it will link to a single page — Tikiwiki.

There are many instances when I use "Tikiwiki", I may want to point the reader to Tikiwiki related pages. For example:


Is there a way accomplishing the above using the "Wiki syntax" — pointing to the above different sites, using the single "link term" — Tikiwiki?

The above is quite simple. In a template TOC for example of different geographic locations (countries, states, provinces, cities, communities, etc.), I may use the template:

  • Introduction
  • Quick Glance
  • History
  • Arts & Culture
  • Ethnic Groups and Languages
  • etc.
  • etc.


In this case, the TOC "link terms" would be used thousands or even tens of thousands of times. I would be grateful to know how the above TOC templates can be accomplished using "wiki syntax" withouht having to resort to this:

Introduction: United States, Introduction: Canada, etc.

cgc0202

posts: 102

Part II: Complications using the Wiki Syntax

Style and Wiki Syntax

In the TOC link:

Installation of a TikiWiki 1.9.1 for Newbies

I wanted to capitalize the "W" in Tikiwiki, (i.e., TikiWiki). The above however will result into two different linked pages (not what's desired):

TikiWiki and Installation of a Tikiwiki 1.9.1 for Newbies because TikiWiki is a link format based from "wiki syntax".

What's the solution to avoid this from happening, without having to be satisfied with "Tikiwiki"?

I may have not reached that portion of the Documentation, yet.

However, the symbols for "asterisk", "double asterisk", open-close paired (brackets, parenthesis, etc.) and others used in the "wiki syntax" have specific key uses in mathematical formula and common writing style.

How can the "wiki syntax" be "inactivated", when it is necessary to do so?

cgc0202

posts: 4656 Japan

> Part II: Complications using the Wiki Syntax
>
> Style and Wiki Syntax
>
> In the TOC link:
>
> Installation of a TikiWiki 1.9.1 for Newbies
>
> I wanted to capitalize the "W" in Tikiwiki, (i.e., TikiWiki). The above however will result into two different linked pages (not what's desired):
>
> TikiWiki and Installation of a Tikiwiki 1.9.1 for Newbies because TikiWiki is a link format based from "wiki syntax".
>
> What's the solution to avoid this from happening, without having to be satisfied with "Tikiwiki"?

The best is to probably not activate ))WikiWords((. Use only double parentheses to indicate wiki page links.

> I may have not reached that portion of the Documentation, yet.

Right. No offense, but I think your posts here could have been titled "Why I activated 'Allow HTML' in Wiki and Articles pages instead of reading the docs". wink

> However, the symbols for "asterisk", "double asterisk", open-close paired (brackets, parenthesis, etc.) and others used in the "wiki syntax" have specific key uses in mathematical formula and common writing style.
>
> How can the "wiki syntax" be "inactivated", when it is necessary to do so?

Again, check the wiki syntax descriptions to see how to deal with these things. There are various ways, such as the np, pp, and code tags for such cases.

-- Gary - zukakakina.com


posts: 102

Part III Targetting where a link will open up.

Aside from the complications already discussed above, try to click, for example, on the link. TikiWiki. The latter interpreted as %22mashed two independent words%22 is automatically interpreted as %22wiki link%22.

The resulting "TikiWiki link" will replace this "existing page". How is it possible to trigger the "TikiWiki link" so that it will pop-out into a different window? This is readily achieved using the %22target%22 specification in %22HTML scripting%22.

Note also that in this post, I did not want to use the paired "open-close" brackets to underline the sentence(s). How can this be avoided?

cgc0202

posts: 4656 Japan

> Part III Targetting where a link will open up.
>
> Aside from the complications already discussed above, try to click, for example, on the link. TikiWiki. The latter interpreted as %22mashed two independent words%22 is automatically interpreted as %22wiki link%22.

Not necessarily. If you don't want "WikiWords" to be made links automatically, don't activate this feature. If you want to use them but want exceptions, use this syntax: ))WikiWordsNotALink((.
>
> The resulting "TikiWiki link" will replace this "existing page". How is it possible to trigger the "TikiWiki link" so that it will pop-out into a different window? This is readily achieved using the %22target%22 specification in %22HTML scripting%22.
>
> Note also that in this post, I did not want to use the paired "open-close" brackets to underline the sentence(s). How can this be avoided?

Square brackets are used to create external links; if you want to use square brackets for other purposes do it like [[this]. This like other "problems" you're talking about, are described in the wiki help at the bottom of every wiki editpage or elsewhere in the documentation.

-- Gary - zukakakina.com


posts: 4656 Japan

>...
>
> Maybe there is a better solution, but here is a reason why sometimes I prefer the "HTML format" for a link instead of using the "wiki syntax".
>
>...
>
> Is there a way accomplishing the above using the "Wiki syntax" — pointing to the above different sites, using the single "link term" — Tikiwiki?

Yes, use the ((page|desc)) syntax for local pages and [URL|link_description] for external links. This way, just like with HTML, what appears on the page ("desc" or "link_description," respectively) can be anything you want it to be, and the actual wiki page name or external URL is in the href tag but not visible on the page.

-- Gary - zukakakina.com


posts: 102

Hi Gary,

Thanks for being patient.

I allude to your response:

"Right. No offense, but I think your posts here could have been titled "Why I activated 'Allow HTML' in Wiki and Articles pages instead of reading the docs". "

in another thread.

So, I have a related question, instead. What is the reason then why "Allow HTML" is a feature in both the Articles section and the "wiki sections"?

Thanks.

cgc0202



posts: 4656 Japan

> ...
> So, I have a related question, instead. What is the reason then why "Allow HTML" is a feature in both the Articles section and the "wiki sections"?

It's there so that Tiki users have the option. Especially in the earlier versions of Tiki the wiki syntax and plugins were rather limited, so HTML was available for things they didn't cover. But the syntax and plugins have come a long, long way and are much more extensive, so there is a lot less need to use HTML.

I think the idea for wiki syntax to begin with was that it'd be easier for new users to use than HTML is, fewer tag characters to input, and so on.

Apart from the complexity of HTML for people not familiar with it, the problem with using it in the wiki is that, if enabled for non-admin users or outside of a trusted environment, there is much more potential for malicious code on the server, security problems, etc. Most forums, wikis, etc. either limit HTML to text-styling and link tags or don't allow it at all, for this reason.

-- Gary zukakakina.com

posts: 102

> > ...
> > So, I have a related question, instead. What is the reason then why "Allow HTML" is a feature in both the Articles section and the "wiki sections"?
>
> It's there so that Tiki users have the option. Especially in the earlier versions of Tiki the wiki syntax and plugins were rather limited, so HTML was available for things they didn't cover. But the syntax and plugins have come a long, long way and are much more extensive, so there is a lot less need to use HTML.
>
> I think the idea for wiki syntax to begin with was that it'd be easier for new users to use than HTML is, fewer tag characters to input, and so on.
>
> Apart from the complexity of HTML for people not familiar with it, the problem with using it in the wiki is that, if enabled for non-admin users or outside of a trusted environment, there is much more potential for malicious code on the server, security problems, etc. Most forums, wikis, etc. either limit HTML to text-styling and link tags or don't allow it at all, for this reason.
>
> — Gary zukakakina.com

Yes, I thought it would be something like that Gary, especially about the security. Sylvie also pointed that in another feature that I really wanted — the use of "includes" — in another thread.

I realized that early enough and I decided that the Articles will be used mainly for "final materials" so that the usual html features may be activated, but quite restricted in editing access.

However, using "html" with the Articles will limit the power of allowing more people to participate in the editing of a page file — which is the very essence of the collaborative environment in wiki pages. Also, as I pointed in another thread — the drawback that I found in the "Articles" is that it did not have the "history" feature.

In theory therefore, a malicious Editor can essentially erase an Article, or may modify a "final" Article — that may not be as good as the previous version, but without the "history" feature, there is no way to recover (roll back) to a previous version.

It does not even have to be malicious. In one incident, I wanted to quote a Wikipedia definition, exactly as contained in their page — with proper citation, of course. Unfortunately, I believe Wikipedia has built-in encryption mechanism, or something else. It erased not only the definition, but the entire content of the page. So, I lost the whole thing — even if the quoted Wikipedia definition was a small component of the entire page.

Do you think there is a possibility that Tikiwiki will incorporate the "history" feature in the Articles section? Sylvie stated that "Tikiwiki" has not found a need for it, but as you may realize from the aforementioned, there is a need for this feature in the Articles section.

In the meantime, is there a stop gap measure (other than making a copy in my computer) to avoid the aforementioned deletion, unwanted editorial changes, etc.?

For the above reasons, I have decided that the bulk of the site I am helping develop will be using more of the "wiki" and allow more people, i.e., registered users — to participate in the development of each page file.

The only drawback is that I have to unlearn my tendency to use html markups. The other thing, as I stated before, many of the applications that I intended for Tikiwiki websites that I plan to develop make use of the "symbols" that Tikiwiki have decided to use for its syntax.

For complex mathematical equations, for example, the solution you are suggesting to escape wiki syntax markup is not very satisfactory. Try doing that with a mathematical equation with more than a dozen terms — using "asterisks", "double asterisks", square brackets, brackets, etc. within each term — is difficult enough to follow. If you add to that the "reversal" or to "unwiki" those symbols become a nightmare.

Is there a much simpler way? Like the use of "" and "" in when one does not want to use html markup?

cgc0202

posts: 4656 Japan

> > > ...
>
> However, using "html" with the Articles will limit the power of allowing more people to participate in the editing of a page file — which is the very essence of the collaborative environment in wiki pages. Also, as I pointed in another thread — the drawback that I found in the "Articles" is that it did not have the "history" feature.

You can submit a feature request at dev.tikiwiki.org and maybe it'll be added to a future version.

When there isn't a feature that you want — something like history for articles, then you can improvise. Dynamic content blocks have the same "problem" — no history for particular blocks. So I made a wiki page for that purpose. I write the the new block content on that page, then paste it into the dynamic content textarea. It's an extra step, but works fine. All the previous versions of dynamic content blocks are stored on the wiki page.

>
> In theory therefore, a malicious Editor can essentially erase an Article, or may modify a "final" Article — that may not be as good as the previous version, but without the "history" feature, there is no way to recover (roll back) to a previous version.

Right, so a history for articles would probably be a good thing. In the meantime, the cardinal rule of computer use applies: Back up your data.

> ...
>
> Do you think there is a possibility that Tikiwiki will incorporate the "history" feature in the Articles section? Sylvie stated that "Tikiwiki" has not found a need for it, but as you may realize from the aforementioned, there is a need for this feature in the Articles section.

See above.

> In the meantime, is there a stop gap measure (other than making a copy in my computer) to avoid the aforementioned deletion, unwanted editorial changes, etc.?

Either save a local copy or make a wiki page at your website for back-up copies of things. Especially for long articles, I do them as wiki pages first; these are working drafts. Then when an article is ready for publication, I copy and paste it into the article edit textarea.

> For the above reasons, I have decided that the bulk of the site I am helping develop will be using more of the "wiki" and allow more people, i.e., registered users — to participate in the development of each page file.
>
> The only drawback is that I have to unlearn my tendency to use html markups.

Humans are adaptive creatures. wink

>The other thing, as I stated before, many of the applications that I intended for Tikiwiki websites that I plan to develop make use of the "symbols" that Tikiwiki have decided to use for its syntax.
>
> For complex mathematical equations, for example, the solution you are suggesting to escape wiki syntax markup is not very satisfactory. Try doing that with a mathematical equation with more than a dozen terms — using "asterisks", "double asterisks", square brackets, brackets, etc. within each term — is difficult enough to follow. If you add to that the "reversal" or to "unwiki" those symbols become a nightmare.
>
> Is there a much simpler way? Like the use of "" and "" in when one does not want to use html markup?

* ** [] {{}} [[ ]]
I suggest using wiki no-parse tags around the whole equation, not around each individually.

-- Gary zukakakina.com

posts: 102

Thanks Gary,

It is amazing. What you have suggested about wiki copy of article is what I am doing now. I am creating wiki pages then when it is more or less developed, from other people's feedback, edits and additions, then I will create Articles for them.

With the old Articles, I have now, I will try to create wiki for them, as you suggested, when I am done with creating the Demon Manual. For now, I will make a copy of the Articles, as you suggested.

If you could do me a favor Gary, would you consider submitting the request also for new feature about "history" for Articles. I will at some point submit it also. However, they may listen to you better, as you are part of the core team?

Thanks again.

cgc0202

N.B.

It is good you mentioned about Dynamic content, I like what I read about it, also ephemerides, so when I am more conversant with Wiki, that will be my next stuff to investigate further.

posts: 4656 Japan

>...
> If you could do me a favor Gary, would you consider submitting the request also for new feature about "history" for Articles. I will at some point submit it also. However, they may listen to you better, as you are part of the core team?

No, I'm not part of the core team. I'm on the dev list but that's because I've been an active user, submitting bug reports, making themes and so on. I just asked a lot of questions in the beginning, did quite a bit of experimenting, and wanted to contribute to the project in the ways that I can. Anyway, I think feature requests are considered on their merits, not who submits them.

-- Gary - zukakakina.com

posts: 102

> >...
> > If you could do me a favor Gary, would you consider submitting the request also for new feature about "history" for Articles. I will at some point submit it also. However, they may listen to you better, as you are part of the core team?
>
> No, I'm not part of the core team. I'm on the dev list but that's because I've been an active user, submitting bug reports, making themes and so on. I just asked a lot of questions in the beginning, did quite a bit of experimenting, and wanted to contribute to the project in the ways that I can. Anyway, I think feature requests are considered on their merits, not who submits them.
>
> — Gary - zukakakina.com

Thanks Gary,

I will send the request myself then, some time soon.

cgc0202