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

When editing a wiki page, clicking on any of the toolbar icons:

{img id=102}

causes page to refresh.

Tested with FireFox 3.5 (linux) and IE 6.

If the page is edited using the edit icon (which loads the editor using Ajax), then the feature does work.

This feature works on previous version of tiki (3.x) with the same browsers.

Tiki cache was ceared. No difference.

{syntax type="tiki" editor="plain"}
I started today collaborating with translation into Portuguese language.
My first edition the page [http://doc.tikiwiki.org/tiki-editpage.php?page=Usando%20Páginas%20Wiki|Using Wiki Page (pt)]

the moment I clicked SAVE, I got an error page.
I created a PDF document from it.
As this is my first Bug report I hope I will be able to send the PDF attached to this Bug Report.

{syntax type="tiki" editor="plain"}
Issue was described here:
[http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=31233&topics_sort_mode=lastPost_desc&forumId=4]

When you insert text like:

"You should call ~np~-+intValue()+-~/np~ in ...." then that comes out as:
"You should callintValue() in ...." with "intValue()" monospaced. Note the missing space.

This is caused by the regular expression used to replace the Wiki Syntax with HTML.

The bug is in tikilib.php, line 6467.
It reads:

// Replace monospaced text
$line = preg_replace("/(^|\s)-\+(.*?)\+-/", "< code >$2< /code >", $line);

The first group captures the whitespace. But only the second capturing group is saved.

tikiwiki syntax for 'wiki-link' only works when doc-name is consists of alphabet.

just to avoid wiki syntax works on this bug report field,
currently using as follows :
DOUBLE BRACE OPEN 'WIKI_DOC_NAME' DOUBLE BRACE CLOSE
--> make hyperlink for 'WIKI_DOC_NAME'

DOUBLE BRACE OPEN 'ASIAN_CHAR_WIKI_DOC_NAME' DOUBLE BRACE CLOSE
--> parse 'ASIAN_CHAR_WIKI_DOC_NAME' as normal texts. then just print the texts.

please fix this problem soon. thanks in advance.

When adding a single code plugin sectin onto a WYSIWYG page, everything is parsed and highlighted correctly. When adding a second code plugin section to that same page in the WYSIWYG editor, the first code plugin get "destroyed" - the XML tags in the code plugin etc are converted to &amp;lt; instead of <

This old mailing list thread describes the problem: http://tikiwiki.1073613.n5.nabble.com/Tiki-devel-Parser-problems-with-wysiwyg-td10967.html

Apparently this has not yet been fixed with Tiki 9.6

If you put two (and possible more) color tags in one line (maybe to mark one word in red and the other one in blue) it doesn't work.

Example:
~~#FF0000:text~~ text ~~#FF0000:text~~

~~#FF0000:text~~ text ~~#0000FF:text~~

~~red:text~~ text ~~#FF0000:text~~

~~#FF0000:text~~ text ~~blue:text~~

~~red:text~~ text ~~blue:text~~

would produce:
text~~ text ~~#FF0000:text

text~~ text ~~#0000FF:text

text~~ text ~~#FF0000:text

text~~ text ~~blue:text

text~~ text ~~blue:text

in all red letters


an example can be found here:
http://doc.tikiwiki.org/tiki-index.php?page=UserPageDesertWolf

When there are multiple headers of the same text, for example:

!!!!Windows Media Player

stuff about WMP

!!!!!Platform availability

WMP is available in these platforms....

!!!!Adobe Reader

stuff about WMP

!!!!!Platform availability

Adobe Reader is available in these platforms....

The links by maketoc all point to the first instance of Platform availability. This is not correct.

{maketoc}

{syntax type="tiki" editor="plain"}
Multiple problems exist with TikiWiki tiki-js.js and tiki-jquery.js scripts in relation to editing wiki pages with the Wiki editor. The problems vary by IE version:

* IE requires the 'label' property to be set in 'Option' objects
* IE editing requires use of textRanges

The following (without a space between braces) does not work anymore:

~np~
you can use the ~np~{{user} }~/np~ ~np~~/np~~/np~ ~np~((doc:Argument Variables|Argument Variable))
~/np~

Instead the Argument Variable which is inside __np__ gets parsed as current user login name.

__Update:__ updated the Subject field to more reflect what is the report about

Please see:
http://www.wikimatrix.org/wiki/feature:nofollow
http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html

Hello all,

I'm running into an issue that is causing the diamond and question mark to appear. At first I thought it was an encoding issue, but after looking at this more carefully, I think the root cause is specific to how the headers are generated in HTML.

To reproduce this bug:
1. Create a header in a wiki page with multiple words in it using the wiki editor.
2. Save the page and then View Source.

If you see the header tag below, the second to last word contains " ". This happens to all the headers.

div class="icon_edit_section"><a title="Edit Section" href="tiki-editpage.php?page=CBusinessCreditReport&amp;hdr=2"><span class="icon icon-edit fa fa-edit fa-fw " ></span></a></div><h1 class="showhide_heading" id="How_to_Order_a_Business_Credit_Report"> How to Order a Business Credit Report</h1>

3. Click on Edit to edit the page and switch over to the WYSIWYG editor.
4. Make any edits to the page. I just entered text in the body.
5. Preview the page. A diamond with a question mark will appear where the non-breaking space is located.
6. If the page is saved and you try to edit the page, you'll get the error message regarding an issue with the encoding.

This issue only occurs if you are using the WYSIWYG editor. It seems to be converting that non-breaking space in the HTML to an unknown character. I was previously running 14.2 and upgraded to 15 to see if the non breaking space in the HTML would disappear, but the issue remains. At this point, this makes the WYIWYG editor unusable.

In Tiki12, it is not possible to write non-parsed things using the following syntax:
{CODE(wrap="1")}~np~<b>This should not be bold</b>~/np~
~ n p ~ < b > This should not be bold < / b > ~ / n p ~ ← without spaces
{CODE}

Which, sadly, shows this way:
~np~<b>This should not be bold</b>~/np~

Of course, the Code plugin is not an acceptable substitute, since it does not allow non-parsed content inside text.

This is a big blocker for all technical-oriented Tiki sites (like technical documentation ones, or Tiki consultants ones)

This can be reproduced in tracker fields (like here), wiki pages and blog posts at least. No need for a show instance since one can see it here, I guess.

Number in First numbered header in 2nd level lost in wiki pages with no header of first level

See show.t.o instance

http://xavi-9794-6370.show.tikiwiki.org/tiki-index.php?page=HomePage#Get_started.

if you need to login:
u: admin
p: 12345

{syntax type="tiki" editor="plain"}
Hi, I know ''maketoc'' is said not to like other ''maketoc''s on a wiki page but it obviosly does not work correct (on my REV 24736) if inserted on another page than the first one. If inserted on e.g. the third page all links to headlines of the firstpage carry "pagenum=3" in the link instead of no pagenum or "pagenum=1".

{CODE(caption="Example")}
!# first page
!! test
test test test
!! test
test test test
...page...
!# second page
!! test
test test test
!! test
test test test
...page...
{maketoc}
!# third page
!! test
test test test
!! test
test test test
...page...
!# fourth page
!! test
test test test
!! test
test test test
{CODE}

My initial intention was to put a ''maketoc'' at every end of a subpage to be able to navigate back. BTW: on my REV 24736 multiple ''maketoc''s do not cause any additional problem.

creating an in-wiki link like {CODE()}((M)){CODE} does not work, it is displayed as {CODE()}((M)){CODE}

{syntax type="tiki" editor="plain"}
Hi,
Only red color appear when editing wikis from Foreground Color icon. Wihtout any pallete of color.

Anyones know why?

working version tikiwiki 3.1

Thank in advance

It worked in 12.9 or so but since I upgraded the site to the latest 12.x LTS it stopped working. Tested in 19.x too where it does not work anymore either. Will try to make 18.x instance...

This should work and open the link in Colorbox according to the [https://doc.tiki.org/Wiki-Syntax-Links#Opening_links_in_semitransparent_popup_colorbox_|documentation]:
{CODE()}[foo|bar|box]{CODE}

Result:
[foo|bar|box]

{syntax type="tiki" editor="plain"}
Ordered lists by default are numbering the list sub-items incorrectly, I believe. But when the admin option "Multilevel style numbering for ordered lists" is activated, then the numbering is correct. I believe the numbering that the admin option provides should actually be the default, so there might be no need for the option. I suggest removing the option and making its numbering method the default. That is, all ordered list elements in wiki text should have -+list-style-type: decimal+- . Or if the admin option is retained, it could have a selector of other -+ol list-style-type+-s.

Also, when this option is activated currently, a class is added to the body tag that gives the ''body'' a left margin of 2rem. There is no reason for this class on the body tag, as far as I know, and we for sure don't want it to be adding a new margin to the whole body of the page.

See the discussion with screenshots here: https://matrix.to/#/!SLEgqpTNTlGYAhzNvK:gitter.im/$jVZB_SGxWolFLB9xOaCuzPIX50EfJqpipaNStGchSKw?via=gitter.im&via=matrix.org&via=sans-nuage.fr

the output of {maketoc} in Wiki is not contained in a special
DIV so one can not define a style for displaying it for example in a box or ...

{img fileId="1082" thumb="box"}
I have a "P~SPDE" page and I want to add an alias "Shared Project Development Environment" to it, so that by going to "Shared Project Development Environment" page I'm getting to "P~SPDE" page.
{img fileId="1083" thumb="box"}
Aliases are getting registered, however I do not understand why it is "P~SPDE (link to Shared Project Development Environment)" and not "Shared Project Development Environment (link to P~SPDE)", is not it supposed to be other way round?
{img fileId="1089" thumb="box"}
(1) Semantic Links (2) Backlinks (3) Redirectto similar wiki page (4) Redirect to page alias, if any
are all turned on as provided by doc.tiki.org
{img fileId="1087" thumb="box"}
However, when I'm looking for Shared Project Development Environment page, it replies that the page was not found:
{img fileId="1088" thumb="box"}

Page alias worked in doc.t.o in 9.x at least.

I tried with:
http://nextdoc.tiki.org/Dynamic+items+lists
http://doc.tiki.org/Dynamic+items+lists

and none of them both work. However they both are alias names from this pages:
http://nextdoc.tiki.org/Dynamic+items+list
http://doc.tiki.org/Dynamic+items+list

as you can see at the bottom of the page.

Page alias links replaced by simple wiki links when "wiki wysiwyg" is on
Let me reproduce the issue in a show instance... done. See it here:
http://xavi-9794-5518.show.tikiwiki.org/tiki-pagehistory.php?page=Community&oldver=2
u: admin
p: 12345

I just added "foo" myself in this edit, but as you can see by the history diff-info, the parser (I guess) replaced the alias link with a simple wiki link. and the alias link should stay as alias link.

{img fileId="971" thumb="y" rel="box[g]"}

Thanks

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

{syntax type="tiki" editor="plain"}
If I create a table using the WYSIWYG Editor and click on the __Source__ button, the generated code is using HTML code like this:

<table>
<tbody>
<tr>
<td></td>
</tr>
</tbody>
</table>

Instead of the real Wiki Syntax for tables ([http://doc.tiki.org/Wiki-Syntax+Tables]).

I guess a "HTML->Wiki Syntax Translation" setting must be missing.

As an example, I found out a MediaWiki WYSIWYG CKEditor that does this same translation just fine. Maybe you could check out the code:

[http://www.mediawiki.org/wiki/Extension:WYSIWYG|Extension Homepage]
[http://sourceforge.net/projects/halo-extension/files/SMWHalo%201.5.3_b36/MediaWiki%20extensions/wysiwyg-1.4.1_3.zip/download|Download]
[http://smwdemo.ontoprise.com/index.php/WYSIWYG_Sandbox|Online demo]

Thanks a lot!

{syntax type="tiki" editor="plain"}
In these last month of june or july 2011, some regression seems to have been introduced in proposals/6x, which produces that maketoc create the output twice, when sending a newsletter from a wiki page template.