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

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

{syntax type="tiki" editor="plain"}
Administration, Features, Wiki


I can enable the 'Pictures:' feature in the 'Wiki Features', however when I then edit a page the 'Upload' feature does not appear.


I found if i remove the WYSIWYG editor feature, the Picture and File Upload becomes available when editing a page.

after upgrade from 9.x to 12.x wiki pages with html code are reopened wrongly with wysiywg editor and no way to switch to normal through UI

It was rather annoying, since there was no way to revert back to a the normal plain text editor unless I appended by hand in the url the "__&mode_normal=y__" param.

I'll try to reproduce locally with the dump of the production site where this happened, and if I manage, I'll send a dbsump to a developer willing to bugfix it.

See http://doc.tikiwiki.org/tiki-pagehistory.php?page=File%20Gallery%20for%20Images&preview=10

If you use align=center inside a ~np~{img}~/np~ the image will be displayed floating in middle of the text. This is a regression, align=center used to work well in previous versions.

The current wiki syntax does not allow commas when specifying the page name for an external wiki link. This is a problem for example when trying to setup an external wiki link to a list of Bugzilla bugs. In "Admin external wikis" I can create this entry
|| __Name__ | __Extwiki__
buglist | https://bugzilla.mozilla.org/buglist.cgi?bug_id=$page||
But using ~pp~((buglist:1000,1001))~/pp~ on a wiki page does not work.

Anchor are lost after parsing. Tested with WYSIWYG and with normal editor.

insert:
{img src=images/code.png}%%% {CODE()}
<a name="myAnchor01">bla bla</a>
{CODE}

after preview or saving
{img src=images/code.png}%%% {CODE()}
<a>bla bla</a>
{CODE}

The anchor link on title (h1, h2, h3) are now always displayed even if I don’t mouseover.

Pretty ugly :)

{img type="fileId" fileId="1134" thumb="box"}

I didn’t see that on dev... Only on instance for 17.x is a weird situation...

As seen on https://tiki.org/AdministrationDev the https link in the remarksbox on the top of page renders broken:
{img fileId="1103" thumb="box"}

With autolinks on, if I do:

~np~''Taken from http://climatechange.org''~/np~

the rest of the page becomes italic (the auto conversion of link breaks the closing italic tag.

Cutting and pasting text often involves text which has paragraphs which begin with indented lines. These could be recognized by the editors and converted into paragraphs.

If text area feature "paragraph deindent" is turned on, a line which begins with two or more spaces should be converted into the start of a paragraph. In the normal editor, this text would be moved to the start of the line and a single blank line would appear as a paragraph separator. Note that multiple blank lines before the paragraph should be compressed to a single blank line. Text with indented paragraphs often does not have a blank line between paragraphs, so the code needs to ensure that a paragraph marker exists.