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

{syntax type="tiki" editor="plain"}
When you edit text using the WYSIWYG editor, extra <br /> tags are added when the text is displayed in preview or when it is saved. These break tags do not show up when you try to edit the page again, making them impossible to remove.

For example, if the markup in the WYSIWYG editor, when you view the source, is as follows:

''<p>This is some text.<br />This is some more text, on a new line</p>''

What shows up when you view the source of the page that is generated after you save/preview is as follows:

''<p>This is some text.<br /><br />This is some more text, on a new line</p><br />''

As a result of this, the spacing on pages edited by the WYSIWYG editor is bizarre and stretched out.

When one is using the WYSIWYG editor to edit text, extra <br /> tags are added after all <p> and <br /> tags when the text is displayed after save or preview. These tags don't show up in the source code in the WYSIWYG editor at all, so you can't remove them. As a result, the spacing between the text is all wrong.

For example, if you view the source of a page in the WYSIWYG editor, it would look like this:

<p>Some text<br />And more text on a new line</p>

But when you view the source of the page after you have saved it, it looks like this:

<p>Some text<br /><br />And more text on a new line</p><br />

See live example here:
http://moviments.net/cursos/IMDIG-I-Apunts

Wysiwyg editor is enabled, and those are the general wysiwyg settings on the site:
|| Wysiwyg Editor is optional: | X
... and is displayed by default: |
Reopen with the same editor: | X
Content is parsed like wiki page: | X
Content is partially parsed: | X ||

The wiki page http://moviments.net/cursos/IMDIG-I-Apunts was last edited using normal editor, keeping "allow html" checkbox as enabled on that page. When you write
{CODE()}
{maketoc}
{CODE}

The string ~np~{maketoc}~/np~ is displayed, but the table of contents fort that page.

{syntax type="tiki" editor="plain"}
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.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section.

Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button.

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not format the header (color it red) without breaking the "header" status.

Currently we have a page with a ~np~{maketoc}~/np~ at the top and a bunch of h1, h2, h3 headers. We wanted to make the text color red for one of the h1 titles so it was more visible to users. Once we did this in the WYSIWYG editor, the header is no longer listed in the maketoc AND the Edit Section button is gone next to the header text. This ''may'' be associated with another bug [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3763].

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%% the lists (numbered and unordered) have irregular spacing between lines. Edited in Wiki normal and WYSIWYG Source modes work fine.

To reproduce create the following structure in a WYSIWYG editor{CODE()}*blah zaa zaa
*This is a list
**now indenting the list
**blah
*back out
**back in
***really far in
*all the way out{CODE} %%% this example displays for us as {CODE()} blah zaa zaa

This is a list

now indenting the list
blah

back out

back in

really far in
all the way out
{CODE} %%% Sometimes there is a break, other times there is not. If I Preview while editing it looks fine. If I edit the HTML via the Source WYSIWYG view and save then it looks fine until I save it in WYSIWYG mode again.

{syntax type="tiki" editor="plain"}
When editing or creating a page using the WYSIWYG_6x editor, setting any text as a header then saving the file works correctly, however if the page is edited again, the WYSIWYG editor inserts a ! before or sometimes after the text you decided to format as a header.

Looking at the source, it appears that it is inserting the following into the page:

<p>
!</p>

Attempting to remove it by deleting the ! in the WYSIWYG editor just results in it showing up again, either immediately after saving or on the next edit of the page. This results in people not wanting to use the header feature or finding other workarounds such as larger font size.

Hello team,

this may be the same for other types of code, but I have encountered this issue with XML because that's all I use.
Whenever you add bits of XML code between {CODE} tags in wiki-syntax mode, when you save, the code is displayed correctly. However, if at any point (before saving or when editing) you switch to WYSIWYG mode, and then save again, the code is not displayed.
If you switch back to wiki-syntax mode, the code has completely disappeared and is lost.

This is an issue in the sense that I only use wiki-syntax as the main contributor to our wiki, but the users may need to complement or amend some pages for whatever reason, and they need to use the WYSIWYG editor, otherwise they get swamped in the wiki-syntax.

XSS Sanitizations seems to amend some input strings in the wiki / blog editor with an ~np~~/np~. The ~np~~/np~ is filtered out again when the text is being displayed to a user.

This works for normal text, but not when a reserved word appears in a link.

Example:

[http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/eval|eval|nocache]

~np~[http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/eval|eval|nocache]~/np~

The ~np~"eval"~/np~ string in the link will also be changed to ~np~"eval"~/np~, but the ~np~~/np~ will not be removed when the link is being displayed, so it doesn't point to a valid destination anymore.

Expected result: The link is displayed correctly.

Using URL-Enoding on the affected strings as a workaround is possible, but a nuisance.

This happens regardless of whether the HTML Purifier function is active or not.

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.

I have found that most emoji cause page cutoffs on wiki pages. It seems to be that all 4 bytestring unicode causes this most unfortunate error (including the smiley face)

3 bytestring unicode seems to be fine, including: ☺ ☹⛅

I created a pastebin http://pastebin.com/DVf7S1AK with a few common emoji that will promptly kill your wiki page while saving an edit. These are easily usable by just about every mobile phone made since 2010 when unicode 6.0 came out. Desktop usage is also becoming more popular.

My first thought was that it was a HTML Purifier issue. I visited the HTML purifier website and there demo handles 4 bytestring unicode just fine. Then I thought it might be that some software of ours was using the Legacy CJK encoding, but 3 bytestring would not work if that was the case, so we are probably fine there.

That is as far as i have gotten. It wold be really nice if tiki could handle this now popular form of communication.

Emoji Unicode Implementation Info: https://gist.github.com/mranney/1707371
Unicode Lookup: http://unicode.scarfboy.com/

Hi,

After upgrading my web site from tiki 7.0 to 7.2, I've noticed that the non-parsed wiki feature in the wiki pages is not working correctly anymore.
Indeed, from the tests I've done, it seems that in case of multiple use of the non-parsed wiki feature on the same line, only the last one is taken into account.

For exemple, for the following wiki text, only the second ~np~--css~/np~ is taken into account, the first one not so the text is striked through.

***use the ~np~--css~/np~ option (ex: ~np~--css~/np~ test)

Regards,
Yannick

--------------------
Ticket update:

Note that the problem occurs mainly in fancytables.
I've enabled "Allow HTML" for the problematic pages. That also corrected the problem with non-parsed wiki syntax. (:eek:)

The full screen button in the new interface at Tiki5 for wiki page edition doesn't keep the ful screen mode more than a few seconds.

Reproduced with Google Chrome 5.0.x and Firefox 3.6.6 on GNU/Linux.

Example here:
http://tikiwiki.org/tiki-editpage.php?page=TikiFestBarcelona2

{syntax type="tiki" editor="plain"}
This has happened to me seldom on different tikis (3.x, 4.x and nowadadays, even 5x!) on different servers, and it's very annoying for users or admins, since after you make a simple edit to some page, for some reason, it gets the content duplicated after saving your small edit. And it can be repeated 3 times, if you edit again, 4 time if edit again,. ..... I could only avoid it by rollbaking to the last version whithout those duplications.

Confirmed that this bug (related to the collapsible headings) is not fixed either yet in 5.0rc2. It seems to show up in some pages were collapsible headings; I mean:
{CODE()}
!!-

!!!-

etc.
{CODE}

Reproduced recently here:
[http://r-help-es.ourproject.org/tiki-pagehistory.php?page=Bienvenidos&history_offset=0&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Comparar&newver=0&oldver=18&tra_lang=ca&paginate=on&history_pagesize=25|r-help-es.ourproject.org]

I just editted the
{CODE()}
{rss id=1}
{CODE}

to change it for
{CODE()}
{rss id=1:2}
{CODE}

as far as I remember, after a few previews and changes in the content before saving.

Then, the content was saved twice.

See the diff above and the resulting page:
http://r-help-es.ourproject.org/tiki-pagehistory.php?page=Bienvenidos&preview=19

This site is using tiki5.0rc2 , no ajax, and wysiwyg editor enabled, even if not used on that page.

I can provide admin access to that site to any coder willing to check this issue.

---
Initially reported as a comment to this other similar bug report:
http://dev.tikiwiki.org/bug2727

Wiki links (not external links) get a title in a tooltip that has the same content as the link text, so if you hover over a link to "HomePage", there'll be a tooltip saying "HomePage". This isn't helpful and also gets an accessibility warning error, I guess for cluttering the interface with redundant text. This doesn't happen with links made by WikiWords (camelcase links) but does happen with links made with double parentheses, which is the more common method these days probably.

Looking for info about this at doc.t.o, I noticed some wiki links had helpful titles that turned out to be the page description text of the target page, which does a good job as the link title. These can be seen at, for example, [https://doc.tiki.org/Wiki-Syntax-Links#Wiki_Pages] in the "Result" column of the table.

But it seems like most wiki pages don't have anything in the page description field, or maybe that feature isn't even turned on, so I think it would be best, if the feature is off or if there is no page description input for the target page, the link shouldn't have a link title. This would be better than redundantly showing the link text.

Add the new preview tab to other text areas, as seen in {gitlab id=4dc05f6d}

I could be nice to have the "preview" button at tracker item submission time, to preview the parsing of wiki syntax, and to avoid submitting and editting later on for simple wiki syntax errors... (It happened to me, for instance, with bug report:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=184&show=view&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=54 )

When creating a wiki link ~np~((foo)))~/np~, Tiki uses the target pages's ''description'' as the the link's TITLE attribute. It would be nice for external links to also have a TITLE attribute. Tiki could use the link's description, or a generic text. For example:

~np~[http://foo.com|my link]~/np~ would become:
<a href="http://foo.com" title="External link: my link">.....

and

~np~[http://foo.com]~/np~ would become:
<a href="http://foo.com" title="External link">.....

In the wiki syntax the following code
{CODE()}
# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
* Is it important to solve this
* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations
{CODE}

Will produce this (the not expected result):
# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
* Is it important to solve this
* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations

This is bad as it is breaking the page format and the heading numbering system.
To prevent this I have to add indent for each block between a line feed (+) and so this code:

{CODE()}
# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
+When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
+* Is it important to solve this
+* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
+* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations
{CODE}

Will produce this (the wanted result):

# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
+When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
+* Is it important to solve this
+* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
+* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations
That is pretty dumb in 2021 and as long as I’m between 2 heading Tiki should understand it has to indent the text accordingly.

1- "Upload image for this post" is not offered at first post. Only after I save and come back to edit?

Html is offered:
{img src=images/code.png}%%% {CODE()}
<img src='tiki-view_blog_post_image.php?imgId=44' border='0' alt='image' />
{CODE}

It should be wiki syntax:
{img src=images/code.png}%%% {CODE()}
{img src=tiki-view_blog_post_image.php?imgId=44 }
{CODE}

Related: [tiki-view_tracker_item.php?itemId=1492|It's too difficult to re-use image gallery images in wiki pages, trackers, etc]

I noticed this while using the tiki reference plugin. Thought it was something in the plugin creditor interface that was broken, but I now see that the plugin was successfully added. So there is nothing functional broken. However. The UI surrounding the adding of a plugin is certainly broken.

My original report:

Adding a tiki reference appears to be broken now. I get as far as adding a reference, but when I try to create one it just hangs on a grey screen. Then nothing.

Steps to reproduce:
Enable "Wiki references" preference
Edit a wiki page
Click the "Add Reference" icon
Add a Biblio Code and click save.
The screen now "hangs" on a greyed out screen.

{syntax type="tiki" editor="plain"}
[http://profiles.tikiwiki.org|Profiles] are cool
[http://www.yaml.org/|YAML] is cool
[http://qbnz.com/highlighter/|GeSHi] is cool.
[http://doc.tikiwiki.org/PluginCODE|The CODE plugin] is cool.

Now, when making profiles using YAML, it would be nice to have GeSHi Syntax Highlighter in the CODE/YAML/Profiles definitions.

Reference:
http://sourceforge.net/tracker/index.php?func=detail&aid=1648006&group_id=114997&atid=670234