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

When the wiki page contains HTML headings, autotoc fails to display. It doesn't matter if the HTML plugin is used, or if HTML is activated for the page (and the plugin not used), in both cases the content of the page will narrow to make space for the autotoc, but the autotoc doesn't appear. If there is a combination of wiki syntax headings and HTML headings, autotoc will not appear. If there are only wiki syntax headings, then autotoc displays normally.

At the community site, just updated to Tiki 17, on https://tiki.org/Tiki%2Bvs%2BXWiki , the heading anchor icons work properly in Firefox (they are the correct size and display on hover), but they don't in Chrome or Vivaldi (they're too large and always display). (Both of these browsers, along with Opera, use the Blink rendering engine.)

From several discussions;

The learning curve of Wiki page editing, which pretty a basic need, is longer than a lot (if not most) other web application. Things require knowledge and too many clicks to be found and understandable.

Improving the way a wiki page is edited by default is mainly a design UX/UI aspect as all the code is here already.

For example and comparing to Confluence that, from users point require 15mn to have someone working;

* The editing space by default is all full-screen so you have focus on tool you are using right now and not everything your Tiki has
+ ~~#F00:and not confined in a tiny space with what’s left from a screen with menus, preview, header, footer etc~~
* The toolbar by default is a simple as possible (one line) with very clear options for not-techy first time user better comprehension
+ ~~#F00:and not configured by and for admins / techies that don’t want to customise their toolbar~~
* The "main" plugins (they call it macro) are available under a dropdown
+ ~~#F00:and not with the help menu, tab plugin, search it in a small space~~
* You can see/search all the plugin in a large space using "common" terms and big icons
+ ~~#F00:The plugin/macro name is reduced to what is does as short as possible and not a weird name someone gave to its plugin or a long list of words attached to say what it does in a tight space with small text and small icons~~

I think we should have a look at the way it is done and we could improve pretty quickly the way it work.

__Screenshot__
Full screen simple editing by default (the macro/plugin access is under the "plus" button, a dropdown for the common one and direct access to all the others);
{img fileId="1212" thumb="box"}
{img fileId="1213" thumb="box"}

The plugin/macro access is elegant and easy to read
{img fileId="1214" thumb="box"}

Please see: ((tw:CMS Landscape)) and ((tw:Wiki landscape)) and try to edit those pages without getting lost.

Now you understand what we need :-)

Also: https://doc.tiki.org/Unified+Index

This looks cool:
http://twiki.org/cgi-bin/view/Plugins/EditTablePlugin

With the code below (within the split tags) there are br tags displayed in clear.


{SPLIT(colsize="24%|2%|74%")}
Widget Company Limited
__Henry Ford__
{img src="img/noavatar.png"}

!! N hours
__Training this year__
-=2015 - _8.5 h__ =-
-=2014 - _6 h__ =-
...
-=2010 - _6.6 h__ =-


!! X
__Total Courses taken__


(Some chart here)

---
~hs~
---
{TABS(name="kbhome" tabs="New | All Courses | Mandatory Courses | Continue Watching | Favourites" toggle="n")}
^{BOX()}
List of new courses will come here...








{BOX}^
/////
{BOX()}
List of all courses will come here...







{BOX}

/////
^ List of Mandatory courses will come here...







^

/////
List of courses to continue watching will come here...

/////
List of favourite courses will come here...
{TABS}
{SPLIT}

{syntax type="tiki" editor="plain"}
If there is a comma in the URL (testet in the Wiki-Module), the link isn't complete clickable.

Only the part before the comma is linked. Everything after the comma in the URL is shown as normal text in the TikiWiki.

I know, commas should not be part of an URL, but there are many webages out there, how have this.

This bug is testet on TikiWiki 2.2 and 3.0

Here an example of a broken link:
http://this-is-a-testlink.com/foo,bar

[http://this-is-a-testlink.com/foo,bar|this is my link with comma]

But when you use "external Link Icon" with ~091~ Link~124~ Descripton ~093~ That will work.

TheDayAfter

{syntax type="tiki" editor="plain"}
In a new master clone that I connected to an existing up-to-date master database, wiki pages are showing some issues.

Images aren't displaying. Instead, there is this error: "Image(s) having Ids not found." This can also be seen at https://next.tiki.org/Get-Tiki.

Wiki text content is also slightly broken. I copied some text from themes.t.o to my local master (a fresh clone). The page wiki source starts like this:

-+ {DIV(class="lead")}Tiki continues to evolve +-

When I save the page edit, the HTML page source looks like this:

-+ <div style=" background-color: ; width: ;" class="lead" id="&lt;em"> onclick=role=""&gt;Tiki continues to evolve +-

The -+ onclick=role=""> +- displays in the page content. This can also be seen at [https://next.tiki.org/Roundtable-Meeting-2024-11]. In my localhost master, I turned off "Allow plugin-specific edits" and "Allow section-specific edits" because it looked to me like edit icons might be involved in this problem, but that didn't make a difference.

When an H5P project is inserted into a wiki page, the browser url takes on the name of the H5P project application. Specifically with SEF url enabled.

For example, if I create an H5P project, then I insert it into a wiki page by
{CODE(theme="default")}{h5p fileId="1373"}{CODE}

The browser tab no longer shows the wiki page name such as Wiki|Fubar Page
Instead the browser tab will display Wiki|h5p_file_name

Here is a screen capture of my user case, I created an H5P project for collages. I name my new H5P project home_page_collage and saved it to the file gallery.

Using the syntax above, I inserted the collage into my wiki home page to display a group of images. Once the H5P project was inserted and saved into my home page wiki, the browser tab started displaying the H5P project file name, instead of Wiki|HomePage. See screen capture of error in browser tab.
{img fileId="1121" thumb="box"}

Calendar can not be linked to from a Wiki page. The Wiki Syntax parser for URLs does not recognize Calendar URLs, so they do not get linked. Apparently the brackets in such URLs cause problems: tiki-calendar.php?calIds[]=1

I can't add an SVG image.
Even with HTML enabled, it will add an tag into my <object> tag preventing me from using SVG images.

With SVG already being an important element on the web, this is unexcuseable and needs to be fixed asap.

If you write in a wiki page the following code:
~np~[http://website.com|~~#FF0000:Site~~]~/np~

Your link will not be colored as it should.

This has been tested on 1.9.7 and 1.9.10.1

It should work as with wiki links.

If you write this:
~np~((HomePage|This (example) doesn't work))~/np~
It gets displayed as is instead of having a link with parentheses in its text.
The bug exists on 1.9.7 and 1.9.10.1 at least.

This was working well with 1.8.x

When nesting pretty trackers inside a wiki page, the trackerlist for the inside pretty tracker should be able to accept "metadata" from the outside pretty tracker, specially {$f_itemId}, to use as a filtervalue for the inside pretty tracker.

However this results in the following error:
trackerlist: Pretty tracker reference "$f_itemId" could not be replaced in plugin "trackerlist".

This is true with all of the pretty tracker "metadata" such as:
{$f_created}
{$f_status_input}
{$f_status}
{$f_itemId}
{$f_lastmodif}
{$itemoff}
{$tr_offset}

Note that items such as {$f_xx} where xx is the field id and items such as {{page}} work correctly. The issue seems to be limited to using the pretty tracker "metadata" inside the trackerlist of the inside pretty tracker.

An outline:

Three trackers: one for Movies, one for Actors, and one for Cast using two "Item link" fields to link movies and actors.

Three Pretty Trackers: one for Movies, one for Actors, and one for Cast

Wiki page for "Raiders of the Lost Ark":
- Calls trackerlist using the Pretty Tracker for Movies with page=view to show details for this specific movie such as release date, studio, poster, etc.

Wiki page for "Harrison Ford":
- Calls trackerlist using the Pretty Tracker for Actors with page=view to show details for this specific actor such as birth date, birth place, etc.

Pretty Tracker for Movies:
- Contains a trackerlist using the Pretty Tracker for Cast that should have filterfield="xx" where xx is the Item Link field for the Movies tracker and filtervalue={$f_itemId}

Pretty Tracker for Actors:
- Contains a trackerlist using the Pretty Tracker for Cast that should have filterfield="yy" where yy is the Item Link field for the Actors tracker and filtervalue={$f_itemId}


Using the {$f_itemId} in the Pretty Trackers results in the error:
trackerlist: Pretty tracker reference "$f_itemId" could not be replaced in plugin "trackerlist".



Workaround:

Make both the Cast fields Page Selectors and use either filtervalue={$f_xx} or filtervalue={{page}}

It works, but this approach loses the relational benefits of using Item Link. Also, instead of using drop down selectors to select the Movie and Actor for the Cast tracker, the names themselves are required to be typed in, which can be cumbersome and error prone.


Setting "Importance" to 8 based on multiple discussions of nested pretty trackers over the past 7 years:
https://tiki.org/forumthread63281
https://tiki.org/forumthread61654
https://tiki.org/forumthread60207
http://tikiwiki.1073613.n5.nabble.com/Nested-trackerlists-td18465.html

And also this reported bug: https://dev.tiki.org/item5084

Additionally, I believe this simple fix would greatly enhance the possibilities for Mediawiki-type of infoboxes, such as outlined here: https://dev.tiki.org/item1843

Setting "Easy to solve?" to 8 based on the idea that it should be fairly simple to solve since the Pretty Tracker already allows {$f_xx} and {{page}} etc., it's just a matter of including the "metadata" fields into that group.

{syntax type="tiki" editor="plain"}
Sorry I cannot find "wiki-pages" to check in the report-a-bug-form.


1. I edit a wiki page
2. I move the mouse over the save button
3.! I get a help-cursor and the text in the textarea scrolls to the very bottom
4.! I click on save, but nothing happens

I got this behavior REV 24514 and on your REV 24503

I get the same behavior on Firefox, Chrome and WinXP-Safari.

best regards
Thomas

I am using tikiwiki 1.9.4 together with xampp 1.5.3a for windows. When I try to save a wiki page with a large ~pp~ block like:

~pp~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
~/pp~

the page cannot be saved. If I split the block into:

~pp~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
~/pp~
~pp~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
~/pp~

things work as expected.

The page can be previewed but not saved so I suspect it has something to do with the database.

See the problem in action:
I copied an url of a tracker item:
{CODE()}
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=97&show=view&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=26&filtervalue[26]=check
{CODE}

onto another tracker item report, but adding wiki syntax:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=97&show=view&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=26&filtervalue[26]=check|see tracker item]

There is some trouble with __~np~&filtervalue[26]=check~/np~__ form the url when used as external link between square brackets.

Tiki smileys are so 90s... It look very bad.

:)
;)
(:santa:)
(:twisted:)

Really ?

--drsassafras begin--
This seems related to : https://dev.tiki.org/item6191 and https://dev.tiki.org/item6189

I looked into the issue not so long ago. Almost all browsers now support emoji. Desktop and mobile. If we enable the saving of emoji in our database, they will all show nicely, and will always be kept up to date with the OS/Browser.

A little emoji selector could be made for users who dont have a emoji keyboard set up, and the existing similes used here could be integrated.

Although, it might be easier to replace the emoticons with new ones in the mean time.
--drsassafras end--

Since wiki page names should avoid special characters, we'll need to think about maybe using character substitutions in page names (a instead of à, _ instead of ') and use the description field for the exact format.

Please coordinate here: ((Character substitutions))

{syntax type="tiki" editor="plain"}
The symptoms are:
- backlinks work sometimes only
- when deleting a page it does not always become a wanted page
- others ???

The result is:
- unpredictable behavior
- negative impact on the user acceptance

The problem is, that the syntax of the links change:
Example:
1) Type "Page 1" in the WYSIWYG mode and save
-> "Page 1"
2) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1" title="Page 1">Page 1</a>~/np~
3) save again in WIKI mode
-> ~np~[tiki-index.php?page=Page+1|Page 1]~/np~
4) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1">Page 1</a>~/np~

This makes 3 1/2 different representations of a link to 'Page 1'

Just recently (the last few days) I did post some answers in the forum and did need the CODE plugin to show some code.

The plugin seems to be broken, as most of the HTML code between the CODE text
{CODE()}{CODE()}HTML will disappear after saving{CODE}{CODE}
is stripped out of the wikipage source - just disappeared including the plugins end tag.

It is not a matter of misstyping, cause I did try several times.

I did not find time to reproduce yet, but it occures at tiki.org/forums.

Torsten.

See video

This was discovered as part of {wish id=4728}
---
The same issue happens when you add line numbering in PluginCode sections.
Reproduced also here:
http://dev.tiki.org/Web-based+source+code+editor#Bugs

The Foreground Color popup in the Wiki editor has broken in the last week, both on my site and right here on dev.tikiwiki.org. Instead of bringing up a box of colors for selection, it brings up a black line.

I suspect that the vertical size of the box was corrupted in a recent update.

When editing a page on dev.tw.o, I will have proper grammar and punctuation, but after I save it, it appears that all of my commas "," are stripped out in the display. When I go to edit (or even a preview from an edit), the commas also disappear from the edit window.

While not really a high priority, bad, this will crash the app bug, I think it's pretty important for someone who typed in text with proper grammar to have that show up.

*** Also noticing in the tracker, that when I submitted this ticket I had selected something in the Data Type, Feature, and Version sections, but they didn't save, as well as Area and Related Project. ****

When you enter comments in wiki page sources, they should not get rendered.
https://doc.tiki.org/Wiki-Syntax-Text explicitly states that:

{CODE(Colors="Tiki")}
~tc~ this is a tiki comment ~/tc~
Will be kept in the Wiki source file but not seen when the HTML page is generated or HTML page source is viewed
{CODE}

But actually, everything between the two tilde tc tilde marks ''is'' being rendered... Nasty if you want to "comment out" a feature you only want to temporarily disable and not delete it's coding...

If the content of a remarksbox __which is part of a list wiki syntax__ contains a line (carriage return) the part below it is displayed outside the remarksbox.

{img type="fileId" fileId="1257" thumb="box" desc="Plugin content"}

{img fileId="1258" thumb="box" desc="Plugin display"}