Category: Wiki Plugin (extends basic syntax)

Plugin Convene should suggest by default the username of the user viewing the page as the one to be added.

With long lists of users, like in t.o, browser becomes slow due to the building of the long users list. It' would be way easier for most use cases if your own username was provided there as a suggestion (for logged in users) so that user just needed to click at "+" button.

When I use ((doc:PluginConvene)), I often have some slots that I ''could'' do but it would mean bumping another meeting, or some other annoyance.

Could we have additional options? Like "Ok, but..." and this would be worth fewer points (say 0.5).

And then, meeting organizer could make a better decision...

{syntax type="tiki" editor="plain"}
Tested in Firefox on https://tiki.org/2018-08-TAG-Meeting - clicking the edit helper icon just opens empty modal instead of showing the ((doc:PluginConvene)) options.

__Update:__ on the linked page it is working again. Not sure how it got fixed and when but I have a ''feeling'' it was only workarounded by reducing the size (see "Solution" below) of the Convene plugin data in the body. Anyway, setting "Out of date" status and putting it to pending for now... {sign user="luci" datetime="2019-11-03T06:24:54+00:00"}

((doc:PluginConvene)) is pretty cool!

See image attached to this tracker item.

But once date is picked, unless a manual operation is done like this: https://tiki.org/tiki-pagehistory.php?page=Roundtable+Meeting+2021+10&newver=42&oldver=41&bothver_idx=22 the user is left wondering: when is the meeting?

((doc:PluginCountdown)) is pretty basic, not visually appealing.

Let's move to:
http://keith-wood.name/countdown.html
https://github.com/kbwood/countdown/tree/Release_1_6_3

((doc:PluginCountdown)) a great idea. But showing time to the seconds is not a good default.

Wish:
Make options; Days, Days & hours, etc

Should be an option as to how to handle once time is passed.

__x days since__ or __the event has happened__

And locate time has no effect here:
http://tikiwiki.org/TikiFestNY

{syntax type="tiki" editor="plain"}
PluginDBReport, when doing a report with mulitple rows, will take the last "CELL ...." and make all usage of CELL the same as the last call, even across rows an header/footers. So if you have:

TABLE
HEADER
CELL "FIRST"
CELL "LAST"
ROW
CELL "this is first"
CELL "THIS IS LAST"

It will come out as a 2x2 table, with everything saying "THIS IS LAST".
Obviously host information is useful too, this is a CentOS LAMP server with php 5.2.11 and apache 2.2.14 and mysql 5.0.86 .

((doc:PluginDiagram)) in ((doc:Tiki20)) seems a very promising feature.
In my first test, I didnt' manage to make it work when choosing to save the diagram in a file gallery, I don't know why. It just doesn't display the diagram within the wiki page where the diagram was called.

If I choose to save the diagram within the wiki page, then everything works as expected.
If I manyally get the xml code from the diagram created in the file gallery, and place it inline within a new call of plugin diagram in the wiki page, the diagram displays as expected.
If I click at edit the diagram from the wiki page (even If I don't see the diagram displayed in the wiki page, I see the button to continue editing it), I can see it and edit it in the diagram ui editor, as expected.

Only issue is (apparently) to display in the wiki page the diagram stored in a file gallery.

HTH

PluginFade shows nothing in 16.x. It works as expected in 15.x, and in trunk, a new param has been added (bootstrap=y) which allows the plugin to at least show up.

Workaround? backport that ENH of param to fix PluginFade so that at least there is a way to make it work in 16.x

I create a demo on the instance {sign user="Bsfez" datetime="2016-12-31T06:54:06+00:00"}

The wiki plugin, PluginFade, no longer fades out, but still fades in.
Observed in Tiki6 for IE 8 and Firefox 3.6


!!!!{FADE(label="Click to Reveal, Then to Hide")}

~~#F00:__Reveal works, but Hide Does not work__~~

~~#00C:Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus nec mollis erat. Morbi cursus nunc quis metus semper euismod. Ut facilisis est ligula, eget lacinia metus. Nulla tempor semper risus ut viverra. In faucibus purus et eros consequat pharetra. Fusce mattis arcu lorem, non hendrerit erat. Nulla eu mauris urna. Pellentesque nec velit mi, eu rutrum eros. Quisque nec leo enim, id rutrum metus. Mauris luctus sapien nec nulla scelerisque ultrices. Cras sodales, justo nec elementum imperdiet, elit nulla sagittis ante, at tempus ante risus ut nunc. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi nec risus eu ante pellentesque adipiscing vel eget risus. ~~

{FADE}

PluginFiles: form to upload files below that table reports error due to defective indexing (file seems to be uploaded indeed, despite the error message).

I'm using that code in a wiki page:
{CODE()}
{files galleryId="8" showthumb="y" showaction="y" showupload="n" sort="lastModif_desc" showname="n" showfilename="y"}
{CODE}

The error shown is:
{QUOTE()}
Error
Indexació no en processar "AjBCN - Estació Lliure KUbuntu" (tipuswiki page) amb l'error "Could not perform index modification: Data too long for column 'contents' at row 1"
×
Error
Índex de cerca no es va poder actualitzar. El lloc està mal configurat. Poseu-vos en contacte amb l'administrador.
Could not perform index modification: Data too long for column 'contents' at row 1
{QUOTE}

Please, note that the wiki page "AjBCN - Estació Lliure KUbuntu" had nothing to do with the Wiki page where the Plugin Files call was present ("CityOS"), so it seems as if that form attempts to index a wrong object, and also, failing due to "Data too long for columns contents"?.

Addenda:
For your information, uploading the same file through the file gallery upload form no error is shown at all:
{CODE()}
{button href="tiki-upload_file.php?galleryId=8" _text="Puja-hi arxius" _icon_name="arrow-up" _type="primary" }
{CODE}

{CODE()}
{FONT(size="30")}This is OK
This is OK
This is OK
This is OK
{FONT}
{CODE}
will generate:
{FONT(size="30")}This is OK
This is OK
This is OK
This is OK
{FONT}

But

{CODE()}
{FONT(size="30")}This is OK
This is OK

This is not OK
This is not OK
{FONT}
{CODE}
will generate:
{FONT(size="30")}This is OK
This is OK

This is not OK
This is not OK
{FONT}

The bars that show when -+show_bar="y"+- all look the same size and they look more like dots. Also, it doesn't seem to make a difference whether -+percent_of+- is set to -+site+- or -+groups+- - the percent shown seems to always be based on the number of site users.

{syntax type="tiki" editor="plain"}
I just updated a master clone that hadn't been updated since July, but I find that PluginImg images aren't responsive anymore, that is, they don't have the img-fluid class so they overflow their parent div or other containing element. This is definitely a regression, or if there was a decision to remove this class, there definitely should be an admin preference option controlling this, with the default being 'responsive'.

See: https://tiki.org/TikiFestStrasbourg

Wiki plugin, when using with start and stop parameters does not include any text.

It only includes the text when used without these parameters.

Using
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

In using tiki 6.2 the problem persists.

{img type="src" src="tiki-download_item_attachment.php?attId=837"}

((doc:PluginMaketoc)) is cool.

1-It should be more like other plugins. ex.: in ((doc:Plugin Help))

2- There should be an option (perhaps default?) to float right like in
http://themes.tikiwiki.org/PluginMaketocbox

I did set up an example of Plugin MiniQuiz following the documentation https://doc.tiki.org/PluginMiniQuiz ,

but in Tiki15 it doesn't show the strings next to the radio buttons corresponding to the non-right options.

{img src="display1036"}

Reproduced in 12.x here:
http://xavi-9794-5872.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 67890

tracker2 holds the tracker items (questions)

===Summary===
The plugin for inserting modules into a wiki page has a bug where it crashes whenever it encounters custom modules. The following JS applies some duct-tape to the issue, and prevents the crash. I didn't get too deep into the workings of it, just got it to work. Someone who has worked on it before probably has a better understanding of the whole system, and could determine if this was the way to do it or not (the change could have cascading effects on behavior of pluginModule and how it deals with custom modules?)

Note: crash outputs the following error in js console: -+Uncaught TypeError: Cannot read property 'params' of undefined tiki-js.js:1304+-

===Procedure===
To fix the issue, one can do the following:

Modify -+lib/tiki-js.js+- line 1303. Change the else statement to an else if, checking for the undefined object which would break things.

Note that the code in the examples below if from tiki 10, not 11, and may be a little bit different in 11, but the problem remains in 11 and the line changed is the same, and fixes it in 11 too.

So, in this block

{CODE()}//For PluginModule, add selected module parameters to the plugin edit form
if (type == 'module') {
//isolate the module parameter object so it will be shown first in the form
var onlymod = {"params":{"module": meta.params.module}};
//user has not changed the module selection since opening the form
if (typeof selectedMod == 'undefined') {
//pick up the parameters of the saved module parameter
if (typeof pluginArgs.module != 'undefined') {
//this orders the module parameter first, module related parameters second, other PluginModule parameters besides module last
meta.params = $.extend(onlymod.params, tiki_module_params[pluginArgs.module].params, meta.params);
//Use the module description
meta.params.module.description = tiki_module_params[pluginArgs.module].description;
//otherwise pick up the parameters of the first module option since that will be selected automatically
} else {
meta.params = $.extend(onlymod.params, tiki_module_params[meta.params.module.options[0].value].params, meta.params);
meta.params.module.description = tiki_module_params[meta.params.module.options[0].value].description;
}
//user has selected another module while the form was open - pick up parameters for the selected module
} else {
meta.params = $.extend(onlymod.params, tiki_module_params[selectedMod].params, meta.params);
meta.params.module.description = tiki_module_params[selectedMod].description;
}
}{CODE}

change this statement

{CODE()}
} else {
meta.params = $.extend(onlymod.params, tiki_module_params[selectedMod].params, meta.params);
meta.params.module.description = tiki_module_params[selectedMod].description;
}

{CODE}

to
{CODE()}
} else if (typeof tiki_module_params[selectedMod] != 'undefined') {
meta.params = $.extend(onlymod.params, tiki_module_params[selectedMod].params, meta.params);
meta.params.module.description = tiki_module_params[selectedMod].description;
}
{CODE}

===Context===
The issue is caused because the module plugin tries to get the parameters for the object to display in the interface, but for custom modules there are none. The tiki_module_params object stores a parameters object for each module as the value for an attribute named after the module (e.g., -+tiki_module_params~np~[mymodule]~/np~+- would return the params object for -+~np~[mymodule]~/np~+-). The problem is that the if there are no parameters for the object, it sets the value for the module attribute to false, and the unmodified else statement above from -+lib/tiki-js.js+- will try to read the attribute .params from the false object, which will fail, and the js will crash.

Another possible solution to this issue could be to populate the value as an empty object instead of false, in -+tiki-jsmodule.php+-.

{flash type="url" movie="display292" width="589" height="633"}

"Lead, follow or get out of the way" is a common saying.

However, there are some subtleties.

* __Lead__ implies "I agree and will put my energy where my mouth is."
* __Follow__ implies "I am ok with it but I won't lead"
* __Get out of the way__ implies "I don't agree but I won't object (perhaps it doesn't affect me or I will just accept or leave)

There is also:
* __Go along__ (I am not thrilled by the proposal, but I have nothing better for which I will offer leadership)
* __Block__ this is just bad, and I will actively oppose.


In ((doc:PluginProposal)) currently, "undecided" implies, "I'll think about it more and I'll change my vote later". Whereas people that are OK with any proposal are not really counted properly. This will be useful to know if we have enough eyeballs to go ahead.

3 for, 1 opposed is not the same with 0 or 10 __I am OK with any__

The proposal plugin is very cool:
http://doc.tikiwiki.org/PluginProposal

1- It makes it quick to vote and tally votes
2- The proposal and the votes are kept in the wiki page so it's still possible to improve the original proposal and to change the votes (there is wiki page version history so everyone can see the evolution)

Suggestion:
# To have a text box next to the vote where people can add a short comment. When people vote, there can be a +1 if..., -1 unless...
This lets people qualify their vote

PluginR is a mods, and mods should be shut down.

Now that licensing issues have been resolved, please move to the main code base.

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