Category: Wiki Plugin (extends basic syntax)

Similar to [tiki-view_tracker_item.php?itemId=1149|Pass tracker itemID as a parameter to a wiki page, to create a custom-looking tracker rendering] but for input fields.

So designers could make the layout in a wiki page (including html) and place the form elements anywhere.

Related:
*[tiki-view_tracker_item.php?itemId=943|Tracker plugin: useable to edit existing tracker info (especially user tracker)]

Commit 50912, which removes the use of jQuery cluetip, caused the mouseover option to no longer work for PluginImg. Previously, using this option the user could mouse over a thumbnail of an image and the full size image would pop up. below is an example of the usage (which won't work on this site until this bug gets fixed):

''This syntax:''
{CODE()}{img fileId="786" thumb="mouseover"}{CODE}

__Update__
After r51821 the above works, but "mousesticky" still does not as shown below (should pop up and stay up after mouseover):

''This syntax:''
{CODE()}{img fileId="786" thumb="mousesticky"}{CODE}

''Produces this:''
{img fileId="786" thumb="mousesticky"}

Typically, mouseover is to show more text over a small snippet. To save screen real estate.

So the data in the mouseover will typically be much large than the text. Plus, I may want wiki syntax parsing in the mouse over part.

It is now:
{img src=images/code.png}%%% {CODE()}
{MOUSEOVER(text=text that goes to mouseover)}
snippet that is moused-over
{MOUSEOVER}
{CODE}

It should be :
{img src=images/code.png}%%% {CODE()}
{MOUSEOVER(label=snippet that is moused-over)}
text that goes to mouseover
{MOUSEOVER}
{CODE}


Plus, this is a very cool plugin. It should be in main code base, like the THUMB plugin.

{syntax type="tiki" editor="plain"}
Plugin Mouseover in 3.0 now uses label= in the options to specify rollover text (Create a mouseover feature on some text). Text works fine but in previous versions you could use an image instead of text. Now the image displays (if you use "{img src=...}", "<img src=...>" does not work even if you have "allow html"), but no roll over text is displayed when you mouseover the image.

Note: The mouseover plugin only appears to work only if MooTools UI Enhancements is selected. Maybe this needs to be added to the Mouseover plugin documentation.

This is still an issue at r46589 - there is a worked example at my test site at www.opendev.enmoreservices.com/test+MOUSEOVER+plugin+wysiwyg+editor

(access given on request)

when this page is first shown or the page refreshed then (using Firebug) you can see that the span tag containing the pop-up content is:

<span id="mo1" class="mouseoverclass" style="width: 300px; height: 100px; background-color: rgb(255, 255, 240); padding: 5px; cursor: pointer;">

which means it is displayed in line with the link text

once you mouseover and show the pop-up and then close the pop-up the span reverts to what it ought to be ie display: none is added to the style element as below

<span id="mo1" class="mouseoverclass" style="width: 300px; height: 100px; background-color: rgb(255, 255, 240); padding: 5px; cursor: pointer; position: absolute; left: 437px; top: 551px; display: none;">

If the plugin is used with the standard wiki editor it works fine - not tested with the wysiwyg wiki editor option

Mouseover plugin is cool

Some more stuff to make it cooler:

#Now, it sticky or not. Should be possible to set a number of seconds to stay open. It should stay open as long as my cursor is over the zone.
#If contained text is too long, it overlaps to the bottom (good), but background should extend automatically.
#If body empty, don't make clickable (people mouseover and see nothing)

Using the Mouseover plugin, the popup content displays at/near the top of the page rather than at the position of the pointer. See on [https://tiki.org/Versions] (find in page: "which is the highest you can upgrade to if you have Win XP" or "IE 10 note"). This is especially problematic on long pages like "Versions" because the top of the page is out of the viewport, so the user doesn't even realize the mouseover popup opened unless they scroll back to the top for some reason. I checked with a couple of browsers.

Perm plugin is very useful and works well. It is very similar to the group plugin. It weighs just a few k and I see no advantage of putting in mods.
http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=perm

Similar to group plugin, we need "if/else" concept:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=994

So we could do things like this in wiki pages:
if tiki_p_edit "please click here to edit" else "please click here to login"

Also, group plugin is still in mods, but already in main code base so it should be cleaned out of mods.

Allow to override global setting to create toc in a specific page through PluginPdfPage
Otherwise, you get 2 table of contents in a wiki page ifyou have that parameter set globally in print control panel, and you also have toc in a long wiki page in production.

Example (where you can't override that setting):
http://seeds4c.org/Ubuntu+16.04+LTS+for+Human+Beans

{syntax type="tiki" editor="plain"}
Printing with mpdf doesn't include images in many cases including params in the plugin img call such as zoombox, or when controlling the display of images from inside a ((doc:PluginFluidgrid)) , and in other cases reproduced in the show.t.o instance indicated:

Reproduced in a show2.t.o instance from another bug report (since setting up diagram generation requires some manual steps to get the composer package installed server side)
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=Tiki-Wiki-CMS-Groupware
u: admin
p: 12345

Current code used in the show instance:
SVN (24.0vcs): Tuesday August 3, 2021 17:34:21 CEST - REV 78798 (InnoDB)

See pdf produced with pdf:
{file type="gallery" fileId="1564" showicon="y"}

See the corresponding pdf produced by a local pdf printer from the print veresion of that wiki page:
{file type="gallery" fileId="1565" showicon="y"}


Code being used for the first sections about images:
{CODE()}

{FLUIDGRID()}
5: {img src="tiki-download_file.php?fileId=5&display" width="200"} 6: {img fileId="6" width=200}
---
7: {img fileId="7"} 8: {img src="tiki-download_file.php?fileId=8&display" width=400}
{FLUIDGRID}

!!# Local Image with zoombox
{img fileId="4" thumb="box"}

!!# Another local Image without zoombox

{img src="tiki-download_file.php?fileId=5&display"}

!!# A remote image with zoombox

{img src="https://doc.tiki.org/img/wiki_up/393px-Pears.jpg" thumb="box"}

!!# A remote image without zoombox

{img src="https://doc.tiki.org/dl1480?display&x=250&y=180" }

{CODE}
---

retested today upgrading the show instance to latest 24.x
"Upgraded today (server side) to latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022) ", adn removed and reinstalled mpdf and diagram packages.
Same issue.{sign user="xavi" datetime="2022-01-22T23:32:38+00:00"}

{syntax type="tiki" editor="plain"}
When trying to multi select items to filter a tracker, the result is a display of everything BUT the selected items...

e.g. we are trying to allow for multiple selection of items in field 9 for filtering:
~np~{TRACKERFILTER(trackerId=6, filters=9/m:10:11:12:13:14/d:, fields=9:10:11:12:13:14) /}~/np~

Is there a workaround (eg. adding a NOT to the syntax to give the opposite results) that anyone knows?
Thanks,
Peter

When you use a wiki page as template (pretty tracker, pluginlist+semantic alias, etc) we have several component that refer to the template page name and not the item (title) it is displaying.

Things like Multilike, Forum for discussion, Wiki argument variables { {page} }, etc

They will refer/link to the page itself and not to the item title.

IE: I have a template page named __record tpl__ to display a tracker item contact (title:bernard) and on the page I have set Forum for discussion option to create automatically a topic in the forum to discuss about this contact: bernard.

Normally I would expect the title of the discussion to be bernard but it will be "record tpl" and also there will be only one discussion for ALL my items (as the reference is the wiki page object and not the itemId displayed).

Same goes for { {page} } it will show "record tpl" and not "bernard"

Say I have a user tracker but my users speak different languages.
tiki-view_tracker_item.php?view=+user

I want to be able to {tr} the labels but also the lists (drop-down menus and categories)

Using flash plugin for playing mp3 files was possible, as I could reproduce some weeks ago.
I also documented that on the appropiate doc.tw.o pages:
http://doc.tikiwiki.org/PluginFlash

This was a working example listed from the doc.tw.o page:
http://moviments.net/ilp/tiki-pagehistory.php?page=EntrevistaRadio4&preview=1

{CODE()}
{FLASH(movie=>"tikimovies/multiplayer.swf?url=http://usuaris.tinet.org/mikell/EntrevistaRadio4.mp3&MODE=AUDIO")}{FLASH}
{CODE}

However, after I upgraded to Tiki 2.0, that page stopped working (controls from multiplayer.swf are shown, but no mp3 is listened).

Maybe a lateral effect of all html sanitization mesures introduced in tiki 2.0?

When adding a single code plugin sectin onto a WYSIWYG page, everything is parsed and highlighted correctly. When adding a second code plugin section to that same page in the WYSIWYG editor, the first code plugin get "destroyed" - the XML tags in the code plugin etc are converted to &amp;lt; instead of <

This old mailing list thread describes the problem: http://tikiwiki.1073613.n5.nabble.com/Tiki-devel-Parser-problems-with-wysiwyg-td10967.html

Apparently this has not yet been fixed with Tiki 9.6

{syntax type="tiki" editor="plain"}
Seen in Tiki 5 and Tiki 6:

#Missing images:
The path location that Tiki generates for the Infinite carousel icons (next/previous, play/pause, etc.) is incorrect. Tiki is generating:
{CODE()}
/js/infinitecarousel/images/..
{CODE}

But the correct path is:
{CODE()}
/lib/jquery/infinitecarousel/images/..
{CODE}

#Incorrect DIV height calculated
Tiki is calculating the height of the __div id="carousel" ..__ incorrectly -- the bottom 19px of all images is clipped. There needs to be an additional __19px__ added to overall height, to account for the play/pause button & padding

#Suggestion
Tiki should close the entire __div id="carousel" ..__ within another __div__ with __overflow:hidden__ property. This way, Tiki will no longer display ''all'' images on the initial load of a page. Note, that the additional 19px will need to be added to the div's height, too, as noted in #3.

When using pluginRedirect in WYWIWYG, if a page already has a redirect pointing to it, if you try to create another redirect to it from a different page, it doesn't do anything. The js console shows -+TypeError: c is undefined+-, -+...ls(b.startContainer)&&d.contains(k)&&g.contains(h)&&h.isIdentical(k)){h.moveChil... ckeditor.js (line 319)+-

Here is a clearer example:

you have pages A, B, C

C redirects to A, when in WYWIWYG editing page B you cannot use pluginRedirect to redirect to page A, because the insert button doesn't work.

demonstrated and snapshotted. In instance I created pages A, B, C, set redirect from C to A and approved. Tried set redirect from B to A and encountered same problem. Note all this was done in WYSIWYG, and it works fine in Tiki Editor.

if you use the example of the mwtable plugin
{CODE()}{MWTABLE( wiki_classes=false )} style="width:50%", class="myclass"
|+style="font-style:italic;"|My caption
? width="30%;" ?? style="background-color:yellow;"
! style="background-color:grey;"| Name
! Address
|- style="background-color: red"
| style="color: blue;" | Bill
| The little house
|-
| Carol || The big house
{MWTABLE}{CODE}

you will get something like this:

{CODE()}<table style="" width:50%="" ,="" class="normal br">
<caption style="" font-style:italic;="">
My caption<br></caption>
<col 30%;="" width="">
<col style="">
<tbody><tr>


<th style="" background-color:grey;="">Name<br></th>
<th>Address<br></th>
</tr>
<tr style="" background-color:="">
<td style="" color:="">Bill<br></td>
<td>The little house<br></td>

</tr>
<tr>
<td>Carol</td>
<td>The big house<br></td>
</tr>
</tbody></table>{CODE}

you see that the attributes are not translated right.

as well there is a problem with a space like "color: blue"

and another addition: doesn't recognise colors in hexadecimal format (#rrggbb)

it happens in version 3.x and as well as in version 6.1 i am testing right now.

{syntax type="tiki" editor="plain"}
I am trying out the MWtable plugin.
When I preview a table on a wikipage I am alerted :

This plugin was recently added or modified. Until an editor of the site validates the parameters, execution will not be possible. You are allowed to:
View arguments
Execute the plugin in preview mode (may be dangerous)
Approve the plugin for public execution
View Details

if I click on "view details" I am prsented with the option of approving the plugin. Clicking the button, however, will transfer me to the edit-mode of the Wiki Homepage

This is probably a complex feature so I'll try to be as clear as possible.
The term __Lists__ will be used for the rest of the text to describe any structured text inside a wiki page that could be thought of as a group of text describing similar things such as bullet lists, numbered lists, tables, headers, table of contents, etc.

Why?:
Let's say you have some bullet list in a wiki page listing departments in an organization. eg
*Sales department
*Customer support
*Supplies
*Quality department, etc
That info won't change anytime soon so no need to put them in a tracker, you keep all related info in the wiki page.

Now suppose you want to create an issue tracker that can handle issues per department.
Currently you have to either define a tracker for departments and use an item link OR use a combo box,write the departments by hand.

The problem with that is when a change of departments comes, you'll have to remember where the department names are used and to update them manually.

How?:
The above "problem" could be resolved using ''named lists''.
The author could write the department list in a ''named list'' and then when designing the tracker there would be a new type of tracker field type ''named list'' where he would define the page and ''named list'' name or listID to be used.
When adding a tracker item, that field would be rendered:
*as a drop down combo box
*as a radio button list (for single selection)
*as a checkbox list (for multiple selections)
that would fetch the values from that named list.

How to implement?:
There probably are many ways to implement this but my guess is the easiest is reuse/modify existing wikiplugins so as to keep the simple lists plain.
What needed are:
*At most two new attributes for each supported plugin: name and id eg for fancylist:
{FANCYLIST(name=>"UserDefinedName", id=>tikiautoincrement)} {FANCYLIST}
*A new tracker field type ''Named list'' that would parse the defined named list
That field type would take as parameters:
**The page the named list is in
**The name or id of the named list
*Optionally a new tiki feature admin page ''named lists'' where all lists names would be listed with name, id, and page.

Proposed list of plugins to be ''named'' (in order of preference):
*PluginFancylist
*PluginDl
*PluginFancyTable
*PluginMaketoc
*PluginToc
*PluginBacklinks
*PluginSort
*PluginAnnotation (for annotations lists)
*PluginAttributes

Two aspects:

A- Alternate theme for certain browsers:
Ex.: simple theme for IE6 or pocket browsers.

B- Showfor plugin, as developed for Support.mozilla.com


Should the plugin be called SHOWFOR? (if so, it's should be quite generic).

*printer
*various browsers
*mobile versions
*users, groups, perms, upon feature check
*etc

Even if the generic plugin is not called browser, SUMO can continue to use SHOWFOR (And avoid needing to edit all the content) thanks to ((doc:plugin Alias))

See: ((Alternate content by media))

Nested footnotes do not display in footnote area.

This is because footnote content is not evaluated until after footnote area renders it. Using a second footnote area will render the footnotes correctly, in the second footnote area, but the links to those footnotes in the second footnote area no longer function.

Evaluating footnote content within the footnote plugin should fix the error.

!!!Begin Footnote Test

non footnote area {FOOTNOTE()}Footnote 1 {FOOTNOTE()}Nested Footnote 2 {FOOTNOTE} Continuation of Footnote 1 {FOOTNOTE()} Nested Footnote 3 {FOOTNOTE()}Footnote Nested Twice 4{FOOTNOTE}{FOOTNOTE}{FOOTNOTE}
text after all footnotes

{footnotearea() /}

!!!Expected Result

non footnote area {SUP()}((1)){SUP} text after all footnotes

((1)). Footnote 1 {SUP()}((2)){SUP} Continuation of Footnote 1 {SUP()}((3)){SUP}
((2)). Nested Footnote 2
((3)). Nested Footnote 3 {SUP()}((4)){SUP}
((4)). Footnote Nested Twice 4

The expected result is for each footnote to appear once, each with there own footnote number, and referenced as such in the main body of the text. Additionally, using a footnote should not create a line break in the original text.

!!!End Footnote Test

This should be discussed. Not decided if we want it.

This would be useful for the import from MediaWiki people because this is a setting in MediaWiki. Now, after import, users must go in each page and add maketoc.


This would be a site-wide setting (overrideable per workspace). Would need to have a way to turn off for a page (ex.: with a wiki syntax)

PluginWikiPages is comparable to pluginArticles. It shows a list of pages which belongs to eg. a specific category ordered by hits, relevance, date etc. should work together with pluginInclude or have the option to include wiki pages partialy (start/end/char count/# of lines) as they do not have a heading section.

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