Category: Wiki Plugin (extends basic syntax)

We are still at 2.25:
http://sourceforge.net/p/tikiwiki/code/46914/tree/trunk/composer.json#l14

The updated zip is at:
http://codemirror.net/codemirror-3.16.zip

In 2023 it should be possible to drag a file over a text area in a wiki page and having Tiki to understand what to do (IMG, Mediaplayer, etc...).

Using a Tiki at tiki-admin.php?page=login you can set the user to receive an email to validate its account or as welcome.
This work fine.

You can also use a tracker plugin in a wiki page to fill a tracker item and set that this include a registration.
However the user then doesn't receive any email or validation email.

There is a parameter "Validate users" (y/n) that override only part of the process:
"Here one can overrule the default validate users by e-mail preference"

Setting to Y, users are validated automatically.
They don't receive the registration validation email or anything else (all process is overruled) .

Setting to N, users are not validated.
But, they also don't receive the registration validation email or anything else (all process is overruled) .

sort and group parameters used together in th userlist plugin results in an error. The page says "An error occured while performing the request."

Example:
{USERLIST(sort=asc,group="Registered") /}


This error was traced to the order of the SQL query.

{syntax type="tiki" editor="plain"}
Using a Tracker with an Attachment field with the TRACKER plugin:

If the user __does not__ have permission to attach files to tracker items (but can insert/create new tracker items), Tiki will, nevertheless, allow the user to select a file to submit with the tracker. Upon submission, there is no notification to the end-user that their attachment was not really included.

{syntax type="tiki" editor="plain"}
Using code box in combination with split places <br /> behind every line in code box

{SPLIT(colsize=50%|50%)} text text text ---
{CODE()}
text
text
text
{CODE}
{SPLIT}

Serious problem with IE8 since it is still a major browser for many users ie they haven't generally upgraded PCs for a while and are still running XP so cannot use IE9 and may not be allowed to use another browser.

An error occurs for lots of individual plugins - eg BOX, FILE, IFRAME, INCLUDE etc., etc., when trying to open the plugin editor in the wysiwyg edit screen.

The simple IE8 debugger says:

/lib/ckeditor_tiki/tikiplugins/plugin.js?t=D3NA, line 37 character 6

Error: 'null' is null or not an object


Plugin editor opens OK when accessed direct from the wiki page using the edit icon.

FIXED

Tested with 1.10 SVN from June 20, 2008...

When using the TRACKER plugin on a wiki page, if the user submits the tracker successfully, Tiki scrolls to an anchor in the tracker from to display the success message.

However, if the tracker was not submitted successfully (such as missing a mandatory field), the page is redisplayed at the top of the page -- Tiki does not scroll down to the form to show the error message. The user will be unaware that the tracker was not submitted.

To test:
1. Create a long wiki page.
2. At the bottom of the wiki page use the TRACKER plugin to add a form
3. Attempt to submit the form (using invalid data).

{syntax type="tiki" editor="plain"}
* show page header not respected
* all levels of heading shown as H1 (and trigger a new slide, would be nice to pick which level of heading does that)
* non-standard icons don’t work (I.e. type=brands) because standard font awesome font-face is hard coded to apply to ‘’all’’ -+span+- elements (which is insane right?)
* there may be more…

Version Plugin is broken: or at least it's not working on tikiwiki.org. Example:
http://tikiwiki.org/TikiLiveCD (version 0.3, the default) and
http://tikiwiki.org/TikiLiveCD?tikiversion=Version+0.2 are showing the same

{syntax type="tiki" editor="plain"}
When using the __Versions__ plugin, Tiki incorrectly merges the first line of each "version" within the Version navigation bar. This causes problems when parsing wiki syntax for items that must begin at the start of the line (such as the numbering # syntax).


Example:

[http://tikiwiki.org/tiki-index.php?page=UserPagericks99&pagenum=2#Versions_plugin]

This broken numbered procedures, when Versions plugin is used to differentiate software versions (such as on doc.tw.o or ''Smarties'').

Versions plugin is showing version 3 + 2 + 1 instead of just version 3:
http://tikiwiki.org/tiki-index.php?page=PluginVersions&tikiversion=version+3

Same problem here:
http://tikiwiki.org/tiki-index.php?page=StylesList&tikiversion=Sirius


related: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=838

the SORT plugin works perfectly when set up using the standard wiki editor eg

~np~{SORT(sort="asc")}~/np~
rabbits
cats
dogs
tigers
zebras
pigs
lions
horses
~np~{SORT}~/np~

produces:
{SORT(sort="asc")}
rabbits
cats
dogs
tigers
zebras
pigs
lions
horses
{SORT}

But if the same 'code' is set up in the wysiwyg editor it does 'sort' the list but does not display the result on separate lines ie it produces:

cats
dogs horses lions pigs rabbits tigers
zebras

CentOS 6.3
APC 3.1.13
PHP 5.4.11 (apache2handler)
MySQL 5.5.30-log

Tiki 12, new/clean install

I use inline Plugin Tools, Wanted Pages, to display it, but failed, such as:

http://giprs.org/wiki/Project(external link)

http://giprs.org/wiki/Issue(external link)

There is an option in tiki-admin.php?page=wiki about ->
"Accept dashes and underscores in WikiWords".

This option works nicely in wiki <span style="color:black; background-color:#ff9999;">pages</span>. However, it is not respected in the <span style="color:black; background-color:#ffff66;">Wanted</span> <span style="color:black; background-color:#ff9999;">Pages</span> plugin.

{syntax type="tiki" editor="plain"}
To reproduce, on a Tiki30 on a wiki page add a new plugin.

~np~Near the bottom you will see: 0="[object Object]"~/np~

{syntax type="tiki" editor="plain"}
Plugin invocations with no arguments (e.g. SUP) when edited with the wikiplugin_editor, and without the hack in place get name value pairs such as:

$family
each
clean
associate
link
contains
extend

(see attachment)
{img src=tiki-download_item_attachment.php?attId=183}


This seems to come about from lib/mootools/mootools.js

Affects tikilib.php and tiki-js.js

Workaround is in the code. Grep for "//TODO HACK: See bug 2499"

Twice now, I have thought there was a Tiki bug because TableSorter decided to hide stuff.

Idea: have a little + where columns are hidden

{syntax type="tiki" editor="plain"}
You can set "0" as a value for the ALTERNATE parameter in a plugin list.

-+{ALTERNATE()}0{ALTERNATE}+-

Won't display anything.

If you use the plugin as counter of things that's a problem.

2022-10-17: I (marclaporte) added PluginCode on examples below because it causes issues on index rebuild.

When using Wiki argument variables within a Wiki plugin, the combination of the curly braces and the quotation mark (e.g. {{itemId}__}"__)prematurely ends the plugin's options syntax.

Example:
{CODE()}
||__Plugin__|TrackerFilter
__Plugin Field__|url
__Field Value__|"Edit+Compound&itemId={{itemId}}"||
{CODE}

The following is an example of what I can see when editing the text of a wiki page:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}"} ~/pp~ ||
{CODE}

This is what should be shown:
{CODE()}
||~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"} ~/pp~||
{CODE}

If you keep on editing the plugin using the edit icon and saving without making any changes, it will keep adding on any options that proceed the argument variable, like thus:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}" silent="y"}}"} ~/pp~ ||
{CODE}

On Tiki25 I can set on a page a List plugin filtering "this" object title - the page title.
Then the results can be used in a wiki template (with other wikiplugins) and if I use ~np~{~/np~{page}} inside the template (or other wikiplugins).
The code will know what page (title) I'm talking about.

On Tiki26 this is not enough and the page (title) is "unkown" or picked randomly based on last list result of all the wiki pages even if there is only ONE results (obviously you can have only one page with a title - duplication is not allowed).

See my solutions.

---

It is on a customized Tiki with a List => Smarty template => Wikiplugin Include AND it work in multilingual.
This to allow a user without page editing permission (test typing only) to edit/translate content of blocks in the page without modifying it.

So I set the importance to low however it may be something we have to look at in the future and other cases.

{mediaplayer src="display2088"}

The syntax "div align='center'" isn't valid in HTML5. CSS needs to be used instead, something like "style='text-align: center'".

{syntax type="tiki" editor="plain"}
The plugin section of the wiki help is listing the plugins aplhabetically based on their english name. When it is translated to another language the sorting remains based on the english name, it is quite confusing and looks a bit chaotic in other languages in my opinion. Is there a specific reason why the code here is written this way? If not, can this be fixed for Tiki 4? I dont know how to do it but would appreciate it :)

It is not possible to open several times the help modal {icon name="question-circle"} when editing content.
You need to use it once, save, reload the page and re-use it... and so on.

This is not way to edit content something that should be trivial for Tiki !

Since upgrading dev.tikiwiki.org the "submitted by" is not recorded in bug reports

Can not reproduce the problem. Can you give an url ?
This url http://dev.tikiwiki.org/tiki-view_tracker_item.php is working for me