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

Adding wiki syntax in a custom modules will broke it:
* Changes are not always saved (editing is lost)
* Throw error
* Reload the page

Check http://bsfez-11581-7774.show2.tikiwiki.org
Try to add/edit one of the top message module.

Tikiwiki is unable to properly parse the following syntax:

~np~((Somelink))-((Otherlink))~/np~

The expected output is two wikilinks separeted by the hyphen. Instead the output is (tested on svn branches 3.0 and 4.0):

((Somelink-Otherlink))

{syntax type="tiki" editor="plain"}
in older versions eg. 2.4, it was possible to use wiki page links with ampersands ( &) and also different color in the link text

for instance : "Look & feel" gave the link like <a href=./Look_and_feel> look & feel </a> does

or {CODE()}((Look_and_feel|~~#00F:Look and feel~~)){CODE} gave the link in blue color

Both works with external link syntax {CODE()}[./Look_and_feel|~~#00F:Look and feel~~]{CODE}

most probably it's the same error as describe in bug #3585


if it's helpful : I'm willed to give a bonus to the person who will fix the bug

Try this:
{CODE()}
{GROUP(groups=>"xyz")}
{PLUGIN(that takes long) /}
{ELSE}
{ANOTHERPLUGIN(that takes long) /}
{GROUP}
{CODE}

The parser goes through both plugin and another plugin.

Related: 3134
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=3134&trackerId=5&show=view

Is the parser improvement already on the TW6.0 blockers' list?

It is rather difficult to write plugins that embed other plugins. The reason is the wiki syntax of the plugins not expressing if it is a beginning or an ending clause. The default is the "{X} body {X}" syntax.
Instead, {X} body {/X} should be used.
While this latter syntax as well as the {X /} are accepted by $tikilib->parse_data, it does not process the embedded calls. E.g {X} {X /} {/X} does not work. It returns an empty body instead of {X /} or the result of {X /}.

# enable Slideshows feature on Wiki Admin panel
# log out
# click on the Slides button under HomePage content; tiki-slideshow.php?page=HomePage&slide=1 displays fragments of plugins as ~np~{DIV}~/np~, ~np~{ELSE}~/np~ and ~np~{GROUP}~/np~ (in other words it doesn't parse the plugins properly)

Wiki syntax is not enabled in Tracker comments on this site. May be usability bug in later Tiki versions.

This would permit more parameters.

Ex.: make invisible

{CODE()}
{alias page=oldpagename visible=no}
{CODE}

There should be a conversion script so every time Tiki detects the old syntax, it converts to the new one.



Related: {wish id=wish2450}

A plugin like this:
{img src=images/code.png}%%% {CODE()}
{BACK()}{BACK}
{CODE}

Thats does this:
{img src=images/code.png}%%% {CODE()}
<input type=button value="Back" inhibited_Click="history.go(-1)">
{CODE}

{syntax type="tiki" editor="plain"}
It would be great feature I think if you could quickly mention someone in the wiki pages and anywhere else using syntax like -+@johndoe+- and after page is saved it would make a link to their user info and send a notification to them that they were mentioned on the object.

It should also respect the "show realName" preference when enabled.

Requirements:
* Needs to check if the @ is at the beginning of line, or surrounded by whitespace to not catch regular e-mail addresses
* Needs to match only one @ followed immediately by the username (login name)
* Optionally it would be nice if it matched also mentions in common parenthesis like -+(@username)+- without need to surround them by space

See also ((Freeform Relationships)) with the idea of @@group

In the Quicklinks, there are two table links (one for the old wiki-table syntax, and one for the new).

On the Wiki table syntax in effect (from tiki-admin.php?page=wiki) should appear.

In templates/tiki-edit_help.tpl, this is already done with:

{if $feature_wiki_tables eq 'new'}

---
On second thought, since the new table syntax is so much better, and it's now the default on new installs. All references to old syntax should be phased out. People should only use it if they have large amounts of legacy data that they don't want to take the time to convert.

Wiki syntax parsing for tables is broken

Following two things are supposed to work. These are just copied from the offered quicktags.

||r1c1|r1c2
r2c1|r2c2||

||r1c1|r1c2||r2c1|r2c2||

First one works, but the second ones ends the table at the || and then just prints the text " r2c1|r2c2|| ".

Ok, just saw that Trakcer-Items are Wiki-parsed, too. Good thing! As you can see the effect live! :)

Hmm, everything gets saved, when editing a Tracker except for the feature.... I really have to start working with them.... and search for bugs... sorry for three mails about this, if you are subscribed!

Following code inserted into wiki page is causing problems.

{file name=attached_file_name}

In TikiWiki 1.9 was name of file shown with link to file. In TikiWiki 2.x only single closing bracket (i.e. '}') is shown instead.

Following wiki code gives expected result in both 1.9 and 2.x versions (please note space before closing bracket)

{file name=attached_file_name }

File tag is parsed in file lib/tikilib.php in function parse_data(). Tag file is translated to call of ATTACH wiki plugin. It seems that essential is call of split_tag() method with cleanup parameter set to FALSE (in tikilib.php revision 1.801.2.92 it's line 5474). In branch 1.9 was cleanup hardcoded to TRUE in split_tag() body. Setting cleanup to TRUE 2.x gives expected result.

I can see that optional cleanup parameter of split_tag() method was introduced in tikilib.php revision 1.602. At the same revision was cleanup value in file tag parsing section set to FALSE. Commit comment says "Minor tweak to preserve ' in {file ...} links.". I don't know idea behind it so I'm not able to correctly fix file tag rendering issue. Simple change of cleanup parameter to TRUE would probably cause regression of another bug.

In Tiki 3.1, the wiki syntax for text color breaks when there are two colors on one line. See http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=&comments_parentId=33947 for the forum post reporting this, and examples of the problem.

(Edited to check "watch" feature.)

{syntax type="tiki" editor="plain"}
__Tiki:__ 6.1
__Firefox:__

Wiki text returned by the SQL plugin is not translated. I used the "Quote" plugin to verify if this problem exists for all plugins returning Wiki text and the value translated as specified in the data passed.

We make fairly extensive use of the SQL plugin on our internal department site. A technique for implementing this plugin we use is to enclose the return value of a column in double parenthesis. This enables us to have a web page reference for each of the returned rows.

This technique is used in several circumstances. One is that we select from our database stored information on hundreds of servers making the server name a link to a detailed info page. The example below is used to link to project detail pages describing individual active projects.

{CODE(caption="Example SQL",wrap="0")}
select
concat( '((', p.project_name, '))' ) as "Project Name",
u.user_username as "Project Owner",
tdv.value as "Project Status"
from
projects p,
departments d,
project_departments pd,
tsi_dp_valsets tdv,
users u
where p.project_id = pd.project_id
and pd.department_id = d.dept_id
and d.dept_name = 'TSI-KPHC'
and u.user_id = p.project_owner
and tdv.ID = p.project_status
and tdv.value != 'Archived'
and tdv.value != 'Complete'
order by tdv.value;
{CODE}

This issue is not restricted to link specifications as bold (double underscores) no longer work when returned by SQL either.

I have rated this a "9" strictly from a personal importance perspective and not as a definition of impact to the overall Tiki project. The customers of our department rely on these returned links for information and updates.

I have been all through the Administrative areas hoping to find a feature flag to turn on wiki text parsing of plugins (before trying the above referenced "Quote test") and am also unable to find such a flag specific to the SQL plugin.

--Steve

The capability to include (recursively) with parameters is probably the most powerful and content factorizing feature of our best competitor MediaWiki.

It make not only produce content much faster and in a much more modularised way.

The references :
* [http://en.wikipedia.org/wiki/Transclusion]
* [http://www.mediawiki.org/wiki/Help:Templates]
* [http://doc.tikiwiki.org/PluginInclude]

You can see the effect of Wiki-syntax getting parsed differently with the ~np~ ~np~ ~/np~ tag and the~np~ {CODE()} ~/np~ -plugin.

~pp~
~np~text here~/np~ - strips all linebreaks out of "text here" - ~pp~ works

{CODE(caption=>test)}
text here and some enclosed in <these brackets> here
{CODE}

The text between the <>-brackets doesn't get shown at all.
~/pp~

Also, (just in case it's related): tiki-view_blog.php complains to admin user about a division by zero by split plugin (tiki 1.9.2):
* {CODE()}
Warning: Division by zero in /var/lib/gforge/chroot/home/groups/gclub/htdocs/lib/wiki-plugins/wikiplugin_split.php on line 74
{CODE}
* This warning message was not present with 1.9.1. (Xavi - xavidp)

The blogs were htmlspecialchar()ed, too - it looks like fixed in CVS now!

When a wiki page is renamed, all links in Wiki pages are fixed. Excellent!

However, menu items are not updated. This would be a nice to have. Same thing for wikilinks in forum posts, trackers, etc

I guess it could get tricky because some use links like tiki-index.php?page=blabla, but some just but blabla and use the .htaccess

If you enter following code in a wiki-page ~np~ ...page... ~/np~ there is a bug in the interpreter. The preview-mode is working right and shows ...page... as plain text, but when you save the page wiki-parser interprets it as a tag and shows the pagenavigation-bar.

plugin include does not work on Tiki18 as reliably as on Tiki15

start and stop parameters are not respected

-+start="~tc​~ includeon ~/tc~" stop="~ tc​~ includeoff ~/tc~"+-

Typing a WikiWord does not result in a wiki link. You must enclose the word in (()), even if the feature is turned on.

On a multilingual Tiki 22 with "Prevent special characters in page names" enabled and "Wiki link format" set to relaxed. (multilingual is important factor here, it is because you have many languages with accent or non-latin characters)

This is working ((Tiki and Virtualmin interop))
This is not working ((Tiki, Virtualmin intérop and more and m’ore and זה או זה))
''On dev "Wiki link format" is set to complete" so it is correctly displayed'' ?

{img fileId="1470" thumb="box"}
{img fileId="1471" thumb="box"}

Having a comma or a quote in the title of a page will break future usage of the page name as link. (wiki link)
The user has no warning about this and it gives a very bad user experience.

# Warning on edit/rebname
When renaming or naming (edit) a page the editor should be warned: "you are about to save this name for the page and it contains xxxx those character(s) may forbid..."
# Warning on using wiki link syntax
It should be forbidden (or at least a warning) for an editor to create a wiki link in a page that contain such characters to prevent breakeage and bad user experience.

Instance is coming

{syntax type="tiki" editor="plain"}
if you enter the <-character in a text (e.g. for an arrow like -->) the following lines have no linebreaks anymore

This bug is seen by our IE 8 clients. We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

When our users try to edit their pages either in WYSIWYG or normal mode, their editor text box is half the width that it should be. They need to use the dragger to make it wider. If we edit in Firefox then the editor is the correct width.

Since IE is our corp standard our users need to be able to add files using that browser. Also, this is the same problem we had in Tiki 5.x and we were hoping 6.x would have fixed it.

Thanks,
Tim