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

Unless I'm missing some new admin change, Japanese wikitext support in trunk is broken. At both a 3.1 site upgraded to trunk, and a fresh install of trunk, Japanese text shows as either garbarge characters or question marks. (I know it's a long way until Tiki 4, but trunk is supposed to stay close to releasable.)

When I’m editing a wiki page were there is a plugin, the last existing last double quotes (") of a plugin is changed to right double quotation mark (R21) and it is breaking the plugin when using Safari on Mac. (may be others are affected).

https://dev.tiki.org/tiki-pagehistory.php?page=Tiki14Upgrade&oldver=1
To reproduce, open the page on Safari, edit, add a return at the end of the text. The quote should be changed.

It may be something specific coming from Safari as I tested this on:
Tiki14 svn
Tiki14Beta
Tik13.2

Hi All,

I’m working on the Tikiwiki 2.2 with a LDAP authentication.

In the login option, I see it is possible to automatically give someone access in the Tiki if this person is in LDAP directory.

My question is: Is it possible to define access with a Distribution List group and not with the entire LDAP directory?

On another note, do you know why “LDAP Member is DN” can not be set to “yes?”

Thanks for your response

Tiki supports headers of various importance. A line starting with a single exclamation mark ("!") will generate the title for a main section, using HTML h1. A line starting with "!!!!!!" will generate the title for a level 6 section, using HTML h6.

Unfortunately, level 7 and above sections are not supported. This is because HTML only defines 6 levels of headings (h1 to h6). On one of my Tikis, at least one user would like to use level 7 sections. But 7 consecutive exclamation marks will be displayed literally (the parser ignores them).

Since my upgrade to 21.2 from 17.x, I have noticed the use of a forced line break (~np~%%%~/np~) in side a standard Wiki table (~np~||1r1c|1r2c... ||~/np~) no longer works. This is best evident in your own documentation page promoting its use this way. See http://doc.tiki.org/Wiki-Syntax where the ~np~%%%~/np~ are now appearing as text in the table entries where used -- including the one promoting its use in tables!

(I should add I had great difficulty getting back to this file-a-bug form as some cookie and security issues kept preventing me reaching the page.)

Please see:
http://dev.tikiwiki.org/tiki-pagehistory.php?page=TikiTests&source=40

There is:
{CODE()}~~#FF0000:This is a great start! I think automated testing will be an important ingredient in the future, to keep TikiWiki stable.

That said, it seems to me that TikiTests still falls short of meeting many of my needs as a Test Driven Developer. I want to start ussing automated tests on Tiki ASAP, so let's figure out what's missing, and how to best support those needs.
~~{CODE}

This used to produce colored text. In a recent upgrade, it no longer does.

Is this a regression bug?
Or was this an accidental but never official feature?

Related:
{wish id=2496}

{syntax type="tiki" editor="plain"}
I have started a blog using Tiki, where I talk about what I have learned over the years on Agile Software developement in a Research and Development context.

In the three weeks I have been doing this, I find myself pointing to Wikipedia pages over and over, whenever I need to refer to a specialized concept that my readers might not understand. The way I do it now is like this. Say I want to refer to the concept of Code Refactoring. Then I will write ~np~((code refactoring))~/np~. Then I will create a wiki page __code refactoring__, and put a redirect plugin on it, so that it forwards automatically to this page:

http://en.wikipedia.org/wiki/code_refactoring

Then, whenever I need to refer to code refactoring, I can just write ((code refactoring)).

It occurred to me that it might be useful to have a special wiki link syntax to make this easier. For example, I could write (wikipedia(code refactoring)), and this would be rendered as if I had typed: ~np~[http://en.wikipedia.org/wiki/code_refactoring|code refactoring]~/np~.

I can see other application of this concept for other well known sites that provide information about known entities. For example: {CODE()}(facebook(Marc Laporte)){CODE} would point to this page:

http://en-gb.facebook.com/marc.laporte.name

From tiki-devel. This is a blocker in my view.

{QUOTE(replyto=)}>> A user added a link to a comment, and now any page that tries to show the link (e.g. the wiki page or the comments admin page) gives me a sql error. My code is up to date to about a week ago ‑ has this been spotted and fixed? A quick search didn't turn anything up for me.
>>
>>
> No, I can reproduce this on current trunk. Here's the stack trace:
>
>> * /var/www/tiki/trunk/tiki‑index.php : 0 ‑> {main}(array ( ))
>> * /var/www/tiki/trunk/tiki‑index.php : 427 ‑> runSetups(array ( ))
>> * /var/www/tiki/trunk/lib/wiki/renderlib.php : 89 ‑> setupPage(array ( ))
>> * /var/www/tiki/trunk/lib/wiki/renderlib.php : 310 ‑> get_parse(array
>> ( 'page' => '\'HomePage\'', 'canBeRefreshed' => 'FALSE', ))
>> * /var/www/tiki/trunk/lib/wiki/wikilib.php : 375 ‑> parse_data(array (
>> 'data' => '\'{BACKLINKS()}{BACKLINKS}\\r\\n((nouvel escape
>> test))\\r\\n((Home
>> ))\\r\\n{YOUTUBE(movie="http://www.youtube.com/watch?v=_wesmkqvUPI")}{YOUTUBE}\\r\\n!!{img
>> src=pics/icons/star.png alt="Star"} Get started.\\r\\nTo begin
>> configuring your site:\\r\\n{FANCYLIST()}\\r\\n1) Log in as the
>> __admin__ with password __admin__.\\r\\n2) Change the admin
>> password.\\r\\n3) Enable specific Tiki features.\\r\\n4) Configure the
>> features.\\r\\n{FANCYLIST}\\r\\n\\r\\n!!{img src=pics/icons/help.png
>> alt="Help"} Need help?\\r...\'', 'options' => 'array (\'is_html\' =>
>> \'0\')', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 6370 ‑> cache_links(array (
>> 'links' => 'array (0 => \'http://info.tikiwiki.org/Learn+More\', 1 =>
>> \'http://info.tikiwiki.org/Help+Others\', 2 =>
>> \'http://doc.tikiwiki.org\', 3 => \'http://www.tikiwiki.org/forums\',
>> 4 => \'http://info.tikiwiki.org/Join+the+community\')', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 3505 ‑> cache_url(array (
>> 'url' => '\'http://info.tikiwiki.org/Learn+More\'', 'data' => '', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 3739 ‑> queryError(array (
>> 'query' => '\'insert into `tiki_link_cache`(`url`,`data`,`refresh`)
>> values(?,?,?)\'', 'error' => 'NULL', 'values' => 'array (0 =>
>> \'http://info.tikiwiki.org/Learn+More\', 1 =>
>> \'\\n\\n\\n\\t\\n\\n\\n\\t\\t\\n\\t\\t\\n\\t\\t\\n\\n\\t\\n\\n\\n\\t\\t\\n\\t\\t\\n\\t\\t
>>
>
> cache_url unconditionally calls queryError(). I don't know what
> queryError() is supposed to do (and certainly didn't hope to find this
> documented), but the following code from Bridge.php is odd:
>
> function query( $query = null, $values = null, $numrows = ‑1,
> $offset = ‑1, $reporterrors = true ) // {{{
> {
> return self::get()‑>query( $query, $values, $numrows, $offset,
> $reporterrors );
> } // }}}
>
> function queryError( $query, &$error, $values = null, $numrows = ‑1,
> $offset = ‑1 ) // {{{
> {
> return self::get()‑>query( $query, $error, $values, $numrows,
> $offset );
> } // }}}
>
> Calling self::get()‑>query() with in turn $values or $error as second
> argument is strange. I figure queryError is probably meant to call
> self::get()‑>queryError() instead.
>
> This code was introduced in r20205.
>
{QUOTE}

Different browsers have a different behavior so ideally the Tiki plugin accepts the file path and produces what is needed for each browser.

* http://stackoverflow.com/questions/5317834/workaround-for-href-file-in-firefox
* http://stackoverflow.com/questions/192080/firefox-links-to-local-or-network-pages-do-not-work


{CODE(caption="link to a file")}W:\00 - Project Management\01 - Project Plan\GLOBAL PLAN.pdf
{CODE}

{CODE(caption="link to a folder")}W:\00 - Project Management\01 - Project Plan\
{CODE}

{syntax type="tiki" editor="plain"}
In Tiki 3.5 when you want to link to a page with ~np~((somepagename))~/np~ within the __;__-Part of a definition list, the definition gets formatted as the question.

;help ((fixing)) this: defintion

When the Wiki feature is disabled, some links are created pointing to nowhere.

Example:
http://www.vic-fontaine.com/forum/tiki-view_forum_thread.php?comments_parentId=13&topics_sort_mode=lastPost_desc&forumId=1

First link points to:
http://www.vic-fontaine.com/forum/tiki-index.php?page=Fw: LOVE WORDING WALLPAPERS

"This feature is disabled: feature_wiki"

Similar in articles:
http://www.vic-fontaine.com/forum/tiki-read_article.php?articleId=1

A link to is automatically created for the key word TikiWiki:

http://www.vic-fontaine.com/forum/tiki-editpage.php?page=TikiWiki


Test user/password: smarty

I'm trying to list wiki pages using the new distance filter. This is the code I am using in the wiki editor:

{CODE()}{LIST()}
{filter distance="50000m" lat="153.601290" lon="-28.645920"}
{LIST}{CODE}

I have posts located within the distance of the specified coordinates but the command throws the following error when I visit the wiki page:

{CODE()}
Error
Expression not supported: Search_Expr_Distance
{CODE}

Tiki's syntax ((doc:Wiki-Syntax lists|allows paragraphs with ordered or unordered lists)). For example, the following dummy list items are inside this first paragraph:
*Dummy item 1
*Dummy item 2

Unfortunately, since {commit id=28616}, parsing such a paragraph generates an HTML P element followed by a distinct HTML UL or OL element. These are rendered as distinct elements, split by as much space as 2 distinct P elements. This can be seen for example in [http://philippecloutier.com/blogpost81-Timex-T128-alarm-clock-Imperfect-but-certainly-smooth|this blog post], stored in Tiki 15 as of 2018-07-31.

Ironically, this problem happens when feature_wiki_paragraph_formatting is enabled, and not when it is disabled. But there is still a problem when feature_wiki_paragraph_formatting is disabled, because as pointed out by Jonny Bradley, the p element cannot contain list elements in HTML 5. This is explicitly documented in the second note of https://www.w3.org/TR/html5/grouping-content.html#the-p-element

As reverting the change would make HTML invalid, the proper solution would be to either hack some CSS which avoids the p element's bottom margin when it is followed by some lists, or to use the div element instead of the p element, as shown in the HTML specification.

Hi,

Can someone try to connect to the tv site and tell me you have difficulty?

https://tv.tiki.org

I'm unable to log in and the slider dissapeared.

Is it just me?

Daniel.
---
Good Catch, Daniel, issue confirmed. Maybe there is some interference with PluginSlider, or maybe a regression coming from somewhere else.
You can log in through the direct login url:
https://tv.tiki.org/tiki-login_scr.php

Once there, if you go to the homepage, you can see the slider working in the homepage. But once you logout again, the slider is gone, and clicking at the login link in the header does nothing for me.

No idea how to solve, or where the source issue comes from.
{sign user="xavi" datetime="2014-07-14T09:01:03+00:00"}
---

LTS Regression: images not shown if align=center as param (reproduced in doc.t.o)

See this thread were it's explained:
https://tiki.org/tiki-view_forum_thread.php?forumId=2&comments_parentId=60647&threadId=60648&thread_sort_mode=commentDate_asc#threadId=60648

reproduced, also, here in doc.t.o, fixed by hand with that change:
https://doc.tiki.org/tiki-pagehistory.php?page=Newsletter+Admin&history_offset=1&paginate=on&history_pagesize=50&tra_lang=sq&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=31&confirmAction=

I mass replaced
{CODE()}
{img align="center" src="img/wiki_up/
{CODE}

with
{CODE()}
{img src="img/wiki_up/
{CODE}

in doc.t.o, but other tikis might be affected by that issue too. (I thought images were gone in some migration between servers or something when I first saw that)

When including a maketoc into a page, the titles in the page are still parsed for WikiWords and Hotwords. This breaks HTML, links, and may decrease the readability of page TOC-s.

The maketoc plugin displays multiple TOC's (one from each Language displayed) on the left hand side when the international "all languages" feature is used.

{img fileId="752"}

A small collection of related issues with maketoc:

^{maketoc} -=Maketoc issues=-^
!!! ''TOC and heading type sizes''
* This is an issue that seems to crop up repeatedly on tw.o. Users would like to be able to easily control type size of both the TOC itself and headings created by maketoc. Type size for both seems to be theme-dependent now, with many themes using very large type size for headings, some with a type size for TOC entries that is too small for users with only slight vision loss. It would be a Good Thing if TOC and heading type sizes could easily be set globally, per object type, and by category, with switches available to vary those settings on a per page or object basis.
!!! TOC and heading character attributes
* It would help reduce inconsisistencies in TOC and heading character attributes (as in this tracker item) if the attributes could be set globally, per object type, and by category, with TOC switches available to vary those settings on a per page or object basis. However, the ability to manipulate emphasis within a single TOC/heading entry should be retained, so that for example, a single word could be italicized in a TOC/heading entry.
!!! Vertical linespacing between headings and text
* Under some themes, vertical linespacing between text and headings is too much for taste, or as in the theme affecting this tracker item, too small for taste. This is another setting that should be unleashed from the themes and made easily selectable by a Tiki admin through global, category, and object type settings, with switches for per page or object variation.
!!! ''Backlinks from headings.''
* Links from the TOC to headings are now 1-way. For larger pages, maketoc would be much more user friendly for those viewing pages if clicking on a heading would take you back to the TOC.
!!! Outline numbering.
* TOC formatting and heading formatting would be friendlier to the eye if both could be assigned numbering schemes such as 1., 1.1, 1.1.1, 1.2 or I., A., 1., a., II, etc. Settings might be implemented as described for ''TOC and heading formatting.'' If developed, this might be implemented for lists as well.
!!! Headings indentation.
* Many power users in the word processing and outliners worlds expect headings to inherit the indentations of the corresponding TOC entry. This would help break up the visual clutter that happens when many headings are close together vertically as a result of short text elements separating them, as in this tracker item (but it is far worse when there are subtopics and corresponding subheadings). Settings might be implemented as described for ''TOC and heading formatting.''
!!! Text indentation
* Many people used to word processors' outlining or stand-alone outliners expect text to be left-indented one tab more than its heading. Relevant settings might be implemented as described for ''TOC and heading formatting.''
!!! Associated features
* Display current settings in editor, change current settings from editor. Make changes to settings made from the editor apply only to the object being edited, so that users do not accidentally apply per object settings to other objects. Admins should have option to disable deviations from admin-set settings.
* maketoc is commonly used in conjunction with list features. Any changes to maketoc should not unintentionally impact the list feature and ''vice versa.''
* Need to ensure that all enhancements suggested render correctly when Tiki objects are exported as PDF.
!!! Future options
* Future options might be kept open by maintaining compatability between Tiki objects containing maketoc elements and various formats used by outliners such as OPML, XOXO, OML, or OpenDocument XML. (See corresponding Wikipedia articles.) E.g., it might be feasible at some point to directly export an outline file to Tiki where it is imported as a wiki or blog page and ''vice versa.''

__The message below was edited.__ {sign user="Chealer9" datetime="2018-06-08T15:57:21+00:00"}

We are running into an issue of maketoc appending onto itself if more than one maketoc appear per page. for starters, our server is TikiWiki 3.2, Windows Server 2003, apache 2.2.13, mysql 5.1.39, php 5.3.0, Multiwiki setup.

We are seeing this in ((doc:Multiprint)). What I am seeing is that if I have Tikipage A with a ~np~{maketoc}~/np~ at the VERY top and headings 1, 2, 3 and Tikipage B with a ~np~{maketoc}~/np~ at the VERY top and headings 4, 5. When I Multiprint using the Pages selector (both Tikipage A and B) there will be 2 TOCs displayed in the resulting print page. The first TOC will show 1,2,3 and further down the page will be 1,2,3,4,5 (when I expected only 4,5). We are trying to Mulitprint hundreds of pages (and most have their own maketoc) so the very last TOC takes up 15 pages itself (after accumulating TOCS over 100s of wiki pages). Big problem for us as our nurses need to have a hardcopy/offline copy on hand in case our systems go down.



So it is the parsing of the maketoc that is causing the appending of subsequent TOCs. I found a bug by "larryg" where he tries to fix a similar issue (cf {wish id=2781} and [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=2&comments_parentId=34791]) but his fix did not work for me. I think that he is on the right track. Does anyone know of a fix? Has anyone experienced this? Is it fixed in 4.x?

Thanks in advance,

Tim

XML files are cool for data interchange.

For example, you can create an xml file to feed a Flash animation. However, you still need to update that XML file via FTP. What if you could edit a wiki page (with permissions, history, etc) and have the Flash animation get the data from it as if it was xml?

Or maybe a button on a wiki page "save to .xml", which would save on the filesystem WikiPageName.xml? (where the Flash would know to look for it)

Related idea:
* {wish id=467}
* {wish id=3103}


Louis-Philippe Huberdeau --will look into-- used [http://www.yaml.org/|YAML] --to see if this could be useful-- and it is very useful for the ((Profile Manager))

Hello,

While trying to convert some blog posts to Tiki by using Markdown plugin I noticed several problems...First one is that when using quoted text, Tiki does not parse it properly.

Here is the text snippet:

-+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Mauris pharetra et
ultrices neque. Id consectetur purus ut faucibus pulvinar elementum
integer enim. Sed euismod nisi porta lorem mollis. Dui nunc mattis enim
ut tellus elementum sagittis vitae et. Porttitor eget dolor morbi non
arcu risus quis. Aliquam purus sit amet luctus venenatis lectus magna.
Ipsum suspendisse ultrices gravida dictum. In mollis nunc sed id semper
risus in. Arcu risus quis varius quam.

> Mattis rhoncus urna neque viverra justo nec. Aliquet nec ullamcorper
> sit amet. Sit amet venenatis urna cursus eget nunc. Maecenas accumsan
> lacus vel facilisis volutpat est. Consequat ac felis donec et. Aliquam
> vestibulum morbi blandit cursus risus at.

> A diam maecenas sed enim ut sem viverra. Consequat nisl vel pretium
> lectus. Ultricies integer quis auctor elit sed vulputate. Scelerisque
> in dictum non consectetur. Scelerisque eleifend donec pretium
> vulputate sapien nec sagittis aliquam.

A diam maecenas sed enim ut sem viverra. Consequat nisl vel pretium
lectus. Ultricies integer quis auctor elit sed vulputate. Scelerisque in
dictum non consectetur.+-


Here {img fileId="1295" thumb="box"} you can see how does it look like.

{syntax type="tiki" editor="plain"}
Rendering of mixed un-numbered and numbered lists has issues in tiki wiki pages, e.g.,

```markdown
* unnumbered level 1
* unnumbered level 2
1. numbered level 3
* unnumbered level 4
2. numbered level 3
```

should be rendered like

```markdown
* unnumbered level 1
* unnumbered level 2
1. numbered level 3
* unnumbered level 4
2. numbered level 3
```

but tiki actually renders it to

```markdown
* unnumbered level 1
* unnumbered level 2
1. numbered level 3
2. unnumbered level 4
3. numbered level 3
```

Apart from "unnumbered level 4" item getting numbered (I get unintended numberings of list items quite a lot in tiki),
the actual spaces before each bullet point/number seems to not follow any common convention but appears to be basically random.

To best of my knowledge, two blanks before the first numbered item below an unnumbered item should be used
to make it align properly under the text of the unnumbered item above.
But tiki renders the above with an unintended huge indention for the "unnumbered level 4" item.

commonmark renders this just fine, see

https://spec.commonmark.org/dingus/?text=*%20unnumbered%20level%201%0A%09*%20unnumbered%20level%202%0A%20%20%20%20%20%201.%20numbered%20level%203%20%0A%20%20%20%20%20%20%20%20%20%20*%20unnumbered%20level%204%20%0A%20%20%20%20%20%202.%20numbered%20level%203%20%0A%60

There seems to be no way to properly include code blocks here. I will try show2.tiki.org...
...does not work either "Lost Tiki database connection".

Please check the source of this post to better understand the issue.
Thanks.

When switching a "wiki" format page to the wysiwyg editor, wiki markup not converted into HTML.
Likewise switching an HTML page to the normal editor, HTML markup not converted to wiki.

For many people, Wikipedia (powered by MediaWiki) was their first contact with wikis. MediaWiki has a very nice interface and has done an amazing job to get Wikis known to the public, via Wikipedia. MediaWiki/Wikipedia is probably the best thing that happened to the Wiki world since Ward Cunningham invented the wiki in 1995.

MediaWiki is excellent to make an encyclopedia. However, it is not designed to be an Intranet/corporate wiki with an advanced permission system. Also, MediaWiki is "only" a wiki. It doesn't have extra features like forums, trackers, blogs, etc. Maybe these features will eventually be added to Mediawiki, but it doesn't seem imminent.

Users which want more can use some glueware to combine a Wiki and an existing full featured CMS (ex.: Drupal + MediaWiki or Xoops + MediaWiki) or they can choose Tiki Wiki/CMS/Groupware.

There are apparently millions of MediaWiki installs. In contrast, there are "only" tens of thousands installs of TikiWiki. While this number is very good, we can expect more & more people will want to migrate from MediaWiki to TikiWiki. Even if a small proportion of MediaWiki installs migrated to Tiki, it would still be a very large influx of users.

Tiki can already look like WikiPedia:
http://themes.tikiwiki.org/Tikipedia

One important step for Tiki's future is to have a converter from MediaWiki to TikiWiki so users can have a painless upgrade path and gain access to more features.

http://dev.tikiwiki.org/MediaWiki+to+TikiWiki+converter

Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]

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