Category: Wiki Syntax (text area, parser, external wiki, etc)

Tracker fields textarea content wiki parsing doesn't work the same as wiki page content parsing when using a page as a Smarty template with the ''wiki'' Smarty block. For example consider we have a textarea field and this wiki syntax in the page named "User Profile TPL":
{CODE()}{wiki}{$f_358}{/wiki}{CODE}

The code above indicates we want the field value to be wiki parsed using the Smarty wiki block.

This is the code to reproduce using PluginTrackerlist (I know it is not PluginList ;-) ... but the wiki parsing should behave everywhere in Tiki the same no matter what you prefer to use):
{CODE()}{trackerlist trackerId=38 list_mode=csv view=user wiki="User Profile TPL"}{CODE}

__The input:__
{CODE()}Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit "amet libero" vitae turpis mattis eleifend.

* meh 50%
* 123
* blah blah

Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.{CODE}

__The expected result:__
{HTML()}<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit "amet libero" vitae turpis mattis eleifend.</p>
<ul>
<li>meh 50%
<li>123
<li>blah blah
</ul>
<p>Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.</p>{HTML}

__The actual result:__
{HTML()}<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit """"amet libero"""" vitae turpis mattis eleifend.<br /><br />* meh 50<br />%* 123<br />* blah blah<br /><br />Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.{HTML}

__Reproduced on the show instance__: http://luci-199-7045.show.tikiwiki.org/
(use show:show as user:password and for admin login use admin:12345 to play with it)

{THUMB(id=17,url="show_image.php?id=17")}{THUMB}

{mediaplayer src="display1914"}

{syntax type="tiki" editor="plain"}
Seen problem on ! and ^

Ex.:
http://dev.tikiwiki.org/tiki-index.php?page=WYSIWYG

{syntax type="tiki" editor="plain"}
__Wiki / Translate / Translate this page to a new language__

When creating a tranlsation of a wiki page by way of the "Translate this page to a new language" button, the following is automaticlaly inserted above the untranslated text trabsferred fromn the original page to the new page:

^Translation of this page is incomplete.^
I assume this is designed for the benfit of people reading the page (rather than those editing it) and as such I find it very useful for the following two reasons:

If you are using a site in one language, say English, and a page appears in another, say French, its very useful for the reader to understand that:
* nothing is wrong e.g. they haven't mistakenly navigated to the wrong page or changed their language settings, and
* the site editors are aware that the content requires translating.

The problem is that it displays in the wrong language (e.g.in our example above in English when the reader may only understand French). The reader needs to see "Translation of this page is incomplete." in their own language regardless of the language of the untranslated text beneath it, otherwise the benefits above are lost.

(Of course, the same should all apply to Articles but they don't seem to have the "Translate this page to a new language" feature yet - only the ability to link to another already created Article at present).

When trying to highlight text with an URL, it does not work well:
{CODE()}__For more details see https://tiki.org/License__{CODE}

Result (everything below the next line gets bold and messed up):
__For more details see https://tiki.org/License__

UI of Feature External Wikis in 14.x shows 2 extra unrelated fields, compared to previous versions, such as with Tiki 12.
See:
http://xavidp-1553-5654.show.tikiwiki.org/tiki-admin_external_wikis.php
u: admin
p: 12345

When editing new wiki page (normal edit mode) and trying to insert a wiki plugin from the Help plugins icon it does nothing when finding the plugin you want and clicking the plugin icon.

Type in wiki page:
^
~pp~
!test test
1111
~pp~
2222
3333
~/pp~~/pp~
^
Work fine:
^
__test test__

1111

2222
3333
^
if type russian heading:
^
~pp~
!тест тест
1111
~pp~
2222
3333
~/pp~~/pp~
^
Result is break:
^
__тест тест__

__2222__
__3333__

__3__
~pp~~/pp~~/pp~
^

This does probably affect (all) previous Tiki versions, too.

When creating links to pages that have some kind of wiki syntax in them, the wiki syntax will be interpreted and therefore break the links. I noticed this when using links to Germany's premier law website, e.g.:

Here without anything: http://www.gesetze-im-internet.de/bfdg/__2.html
Here as no parse: ~np~http://www.gesetze-im-internet.de/bfdg/__2.html~/np~
Here as a link with no parse: [~np~http://www.gesetze-im-internet.de/bfdg/__2.html~/np~]

The last one is a working workaround, but it's a bit sick to say the least. I think Tiki shouldn't parse URLs as wiki syntax at all.

I could also reproduce the same behaviour with other wiki syntaxes as for example the one for italics: http://example.com/my''weird_link.html

Images that are added using the wiki editor (anyway the normal editor, I didn't check the wysiwyg editor yet) don't have a default class. This is the simple case of no containing box or anything added along with the image. Therefore it isn't possible for them to have a default style such as margin or border unless it is added manually by the page author. Or if it is specified by the stylesheet (.postbody img or .wikitext img, etc.) then ''all'' images in those divs get the treatment, including smileys and external link icons, etc.

I suggest adding a default class like "contentimage" to enable a default style. Page authors can always add a second class if needed.

Wiki "((doc:edit by section))": Nice feature added, thanks heaps to those who made that possible! :-)

BTW, I found that it doesn't allow concurrent edition of different wiki sections of the same wiki page.
Tried on doc.tw.o on June 8th 2008, using Mittwoch and also Tikinewt.css (After clearing tiki cache) , and it didn't work for me on any of both cases.

doc.tw.o page needs to be updated once fixed.
http://doc.tikiwiki.org/edit+by+section

wiki (wysiwyg) inline editor transforms page alias links into standard wiki page link on save (alias lost)

See it reproduced here:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

The homepage has at the bottom the standard code for an alias at teh page "HomePage" to be accessed also from "Casa" alias page name.
{CODE()}
(alias(Casa))
{CODE}

Therefore, you can access to the homepage also with:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=Casa

However, if you open that wiki pade for edition with "Inline wiki editor", make some changes, and saved the page through the inline wiki editor (click again at that button that you used to open the inline editor), then the alias link is gone. If you edit the page with the standard wiki plain text aditor, you will see that the code at the bottom is replaced with a standard wiki link pointing to "HomePage" and using "Casa" as label.
{CODE()}
((HomePage|Casa))
{CODE}

2022-10-17: I (marclaporte) added PluginCode on examples below because it causes issues on index rebuild.

When using Wiki argument variables within a Wiki plugin, the combination of the curly braces and the quotation mark (e.g. {{itemId}__}"__)prematurely ends the plugin's options syntax.

Example:
{CODE()}
||__Plugin__|TrackerFilter
__Plugin Field__|url
__Field Value__|"Edit+Compound&itemId={{itemId}}"||
{CODE}

The following is an example of what I can see when editing the text of a wiki page:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}"} ~/pp~ ||
{CODE}

This is what should be shown:
{CODE()}
||~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"} ~/pp~||
{CODE}

If you keep on editing the plugin using the edit icon and saving without making any changes, it will keep adding on any options that proceed the argument variable, like thus:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}" silent="y"}}"} ~/pp~ ||
{CODE}

On Tiki25 I can set on a page a List plugin filtering "this" object title - the page title.
Then the results can be used in a wiki template (with other wikiplugins) and if I use ~np~{~/np~{page}} inside the template (or other wikiplugins).
The code will know what page (title) I'm talking about.

On Tiki26 this is not enough and the page (title) is "unkown" or picked randomly based on last list result of all the wiki pages even if there is only ONE results (obviously you can have only one page with a title - duplication is not allowed).

See my solutions.

---

It is on a customized Tiki with a List => Smarty template => Wikiplugin Include AND it work in multilingual.
This to allow a user without page editing permission (test typing only) to edit/translate content of blocks in the page without modifying it.

So I set the importance to low however it may be something we have to look at in the future and other cases.

{mediaplayer src="display2088"}

The Wiki Help page lists [carat] ^a box^ [carat] to generate a box. But it doesn't generate a box in the WIKI entry, nor in the Help page.

When use only ASCII in SEFURLs is enable and the user use non-ASCII characters it broke the link without warning and create wonky url.

{CODE()}
* ((שלום))
* ((ברנארד))
{CODE}

Once save I’m redirected to the HomePage with a strange error as the page url and then page wiki link will be malformed (it include only the list number element)

I couldn't reproduce on show as it is not set to work with SEFurl.
I can't confirm it was working properly before.

Here a small video to show you.
It should be addressed because user may be not be aware of Admin decision and setting (and they can't be blamed for it).

A check and a warning should be good enough:
You have to name your new page using only ASCII char (A to Z no accents or non latin characters) ... Or it is not possible to create a wiki link or a page using non-ASCII characters (A to Z no accents or non latin characters)
Ask admin... :)

{youtube movie="G77vnbddlK8" width="700" height="520"}

{syntax type="tiki" editor="plain"}
A wiki link in combination with a equation tag parses falsely.
This editor entry

{CODE()}((Fire weather index|{EQUATION()}FWI{EQUATION})){CODE}

displays the text output:

<img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle">§1a7e9ee2385aa1db7956a7f63689955f§

In HTML code:

<a class="wiki" title="Fire weather index" href="tiki-index.php?page=Fire+weather+index">&lt;img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle"&gt;§1a7e9ee2385aa1db7956a7f63689955f§</a>

The same in version 4.2 which is correct:

<a class="wiki " href="tiki-index.php?page=Fire+weather+index" title="Fire weather index"><img align="absmiddle" alt="FWI" src="lib/equation/pictures/04d4e88879dbf4f876f4b62fea56172f.png"></a>

If I enter:
~np~
((pagename(something_in_brackets))) or ((pagename|description(something_in_brackets)))
~/np~

The pagename or the description will not have the closing bracket included. It should.

When creating a link like this

((test - test))

to link to a page named 'test - test' then the created page is missing the hyphen. Additionally the pages is always shown as non-existent, meaning that the question mark behind the source link is always there, even if th e page was manually renamed. It is a real blocker.

In addition to smilies and text formatting like bold, add syntaxes for commonly uses markers in text.

Please see some nice examples here:
http://wikifeatures.wiki.taoriver.net/TextFormattingRules

Which are inspired by :
[http://moinmo.in/HelpOnSmileys|MoinMoin]

I like:
/!\ warning
(./) check
{OK} thumbs up
{i} information
{1} {2} {3} for nice numbering

We currently use images at doc.tikiwiki.org and it's cumbersome.


From #wiki (freenode)

(11:20:53) TheSheep: marclaporte: btw, if you need some icons, there are some I drew at http://sheep.art.pl/Icons
(11:21:10) TheSheep: marclaporte: especially the hand icons can be... uhm... handy
(12:16:35) marclaporte: hehe
(12:17:52) marclaporte: for icons: is license compatible with LGPL?
(12:18:15) marclaporte: I wish we had a license compatibility grid for CC vs GNU
(12:19:58) TheSheep: marclaporte: I can relicense it for you
(12:20:17) TheSheep: marclaporte: although using gpl for something that's not software is weird for me
(12:33:22) marclaporte: yes, but icons have to in the app, no?
(12:42:45) TheSheep: marclaporte: but icons are also distributed when somebody merely uses the web app
(12:43:00) TheSheep: marclaporte: would you want to force them to provide the source code?
(12:44:49) marclaporte: I just don't want any trouble
(12:45:02) marclaporte: and to respect author's wishes
(12:45:51) TheSheep: marclaporte: I can promise I won't give you any trouble, just tell me what you need to use them :)
(12:46:01) marclaporte: hehe
(12:46:13) TheSheep: marclaporte: it will also help me to release my future works in a way that is friendly for developers
(12:46:22) ***marclaporte is adding on todo list

Hello,

Recently upgraded to 3.0..

Thought I'd turn on the "Discuss pages on forums." option.. Created a forum for the purpose.. Went to the Wiki admin page and selected the option.. Picked the forum from the popup that appeared.. Pressed "Change preferences."..

No change.

Tried several times in different ways on different browsers.

No change.


How can I enable this option?



Thanks in advance,

Karl

After using the fullscreen icon while editing a wiki page and then going back to normal mode it breaks the whole usability of the form; textarea is too wide (some icons out of viewport), some b0rked parts appear. (Wrong forced CSS caused by wrong jQuery usage?)

Last time I saw it working correctly was in Tiki 9.

Content Templates are an easy and comfortable way to change the look and content of wiki pages. It would be nice to be able to define such a template as your default for wiki pages, instead of having to choose it every single time you create a new wiki page, or changing the template of wiki pages in general.