Category: Wiki Plugin (extends basic syntax)

Plugin List fails to find a match for the category Profiles Wizard (292) in dev.t.o

This item
https://dev.tiki.org/item6374 - "Can't apply a Profile from the Profiles Wizard! (only through profiles control panel): ticket missing?"

is categorized against category 292: "Wizards - Profiles Wizard"

This wiki page has a plugin list call to show items in this category (with equivalent syntax that it's working with no problems - apparently - in other pages in dev.t.o):
https://dev.tiki.org/Profiles-Wizard

and it fails to list that tracker item (and any others tagged against that category, if any).

I use the GUI for the plugin List add a filter type on tracker (tested with other) BUT if don’t switch at least one time to the "Source" view, nothing will be saved.

I have used the Plugin Edit helper icon on the List plugin on the page ((Tiki20)) to edit some labels (I wanted to add "Status" to the status column label and to change "Volunteered" to "Volunteer to solve") and as it uses the GUI I edited them in the fields named "Label" and then clicked Save but the changes I made were not saved. Instead some not relevant change is indicated in the page history.

As you can see in the history here:
https://dev.tiki.org/tiki-pagehistory.php?page=Tiki20&newver=41&oldver=40

Plugin List GUI minor improvements

--(1) expose the GUI through the modal popup also when through help icon--
So far, when you use the popup helper for the list plugin (through the help icon in the toolbar of a textarea) you cannot use the GUI (com jq missing or not working properly?), but only when you call the list plugin with no params and save the wiki page or tiki object with the textarea, in which you see some sort of jq in action showing the GUI controls and a way to switch back to "source" mode for the body.
{CODE()}
{list}
{CODE}

(2) Not easy to indicate "show me everything from tracker 1"
I couldn't find a way to indicate the trackerId as a first step to get a preliminary report. I was offered to select any from all the tracker fields, but how to indicate all the items from one tracker?

Ideally, the use would like to indicate first the type of tiki oject (wiki pages, one or many trackers, etc), and after that, narrow down which fields or which conditions need to be met, etc.
I couldn't find an easy way to do such task in my first experience with the list GUI. It seems as if tracker_id is missing from the dropdown of values for the filter field, since syntax seems that it should be.

{CODE()}
{filter field="tracker_id" content="1"}
{CODE}

(3) When you search for GUI in the control panel search box for admins, you no results, even if the pref seems to be called "GUI for the list plugin", and pref. filters are set to Advanced, and include Experimental, and the index has been rebuilt just in case.


To reproduce:
http://xavi-9794-6390.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

HTH

Plugin List or TrackerList unable to show tracker items with category 50 (PDF) in dev.t.o
AFAIR, this used to work in previous Tiki versions (at least Tiki12 and presumably Tiki15)
See the edits I did on this page ((PDF)) :
https://dev.tiki.org/tiki-pagehistory.php?page=PDF&newver=0&oldver=17

However, in both cases, there were no results shown. There were items in the past assigned to category 50 (PDF), as shown here:
https://dev.tiki.org/cat50

See also this one added today:
https://dev.tiki.org/item6407

Every function of plugin list pages is working except for the zipping function.
{img fileId="1076" thumb="box"}

I have pages that are related to another and are name as follow;

HomePage
text_HomePage_sectionA
text_HomePage_sectionB
text_HomePage_sectionC
text_HomePage_sectionD_en
text_HomePage_sectionD_fr
text_HomePage_sectionD_he

Etc.

Using Tiki25 and ElasticSearch, when I use a filter with the "exact" parameter like this:
{filter field="title" exact="HomePage"}

Only the page "HomePage" will be returned.

Using Tiki26 and Manticore, using the pages and filter __all the pages__ are returned and not only "HomePage".

On a Tiki25 I have the following working plugin List

{CODE()}
{LIST()}
{filter field="tracker_id" content="3"}
{filter field="tracker_field_parentsGroup_text" multivalue="Team OR Boss"}
{output template="debug"}
{LIST}
{CODE}

On Tiki26 the page displays:
"strpos(): Argument #1 ($haystack) must be of type string, array given"

(Editing the page and saving it goes to an error 500)

The reason is the multivalue parameter.
{CODE()}{filter field="tracker_field_parentsGroup_text" multivalue="Team OR Boss"}{CODE}

If I change it for
{CODE()}{filter field="tracker_field_parentsGroup_text" content="Team"}{CODE}

The page is working fine.

{syntax type="tiki" editor="plain"}
In a Tiki26 I have a tracker with a field specifications.

In a wiki page I use a __first__ smarty template to display the results.
To send the wiki parsed content of the field with the right language, I use:
{CODE()}{FORMAT(name="specifications")}{display name="tracker_field_productssolutionSpecifications_fr"}{FORMAT}{CODE}

In this __first__ smarty template I setup a second wikiplugin List and use again FORMAT to pass the content of the $specifications variable.
{CODE()}{FORMAT(name="specificationsInner")}{display name="{/literal}{$row.specifications}{literal}"}{FORMAT}{CODE}

In the display I can see the content of the field as expected but it is surrounded by a -+No value for ' .../... '+- warning
{img fileId="2145" thumb="box"}
''expected'' mean that's the value I want to see, but I understand it has been passed into the $name of the FORMAT, instead of its content.

This comes from the file "lib/core/Search/Formatter/ValueFormatter.php"

{CODE()}
// ugly exception for wikiplugin - TODO better?
if ($format !== 'wikiplugin' && (! isset($this->valueSet[$name]) || is_null($this->valueSet[$name]))) {
return tr("No value for '%0'", $name);
}
{CODE}

May it is possible to improve this "ugly" exception to avoid this false error ?
Or... a better verbose to help solving ?

If the admin setup a plugin List (ListExecute, CsutomSearch) with a Wiki Variable (IE: {filter field="tracker_field_userUsername" content="{{user}}"}) BUT "Wiki Argument Variables" is not enabled he will see : No results for query.

The admin should be warned he is trying to use a feature that is not enabled when saving the page.

It is not possible to use the plugin ListExecute to send an email that contain a tracker field type file. If you do so it will send different kind of un-useable code.

There is a debate about inserting a file in an email and maybe this will be fixed/changed one day. In the meantime it will be cleaner to display proper error or warning something like "it is not possible..."

On a freshly updated Tiki25.x (from previous Tiki25.x), I have a tracker with 19 items.
When I use the plugin list I see 19 items.
When I check in the database I see also 19 items.

When I use the plugin listExecute there are much more items with "empty" values.

I believe (not checked) the plugin list filter is not working properly and it displays other items.
Those items don't have the expected pernamame field and so the plugin sees those field as empty value.

{mediaplayer src="display1922"}

{syntax type="tiki" editor="plain"}
The drop-down menu inserts a "|" character causing failure.

{IMG(src="http://www.slaveservers.net/tiki-download_file.php?fileId=5&display")}{IMG}

{syntax type="tiki" editor="plain"}
The mouseover plugin works well on its own, similarly, the tabs plugin works well too. But when a TAB includes a MOUSEOVER, the offset of the mouseover box shifts to the end of the page.

I tried to correct this by setting the offsety to a negative value, but apparently, a negative value is not accepted by the mouseover offset command. In fact, even if it did, it wouldn't matter, because the offset shifts as the page gets longer.


For example, this syntax:
{TABS(tabs=Tab1|Tab2)}
*{MOUSEOVER(label="Some label 1")} asdasdasdasd {MOUSEOVER} blah blah blah.....
/////
*{MOUSEOVER(label="Some label 2")} qwertqewrtqwe {MOUSEOVER} blah blah blah.....
{TABS}

results in the mouseover box appear down under the page end.

From tiki 12 on (I think)
The plugin mouseover's tip has a too big offset in both vertical and horizontal position
Example can be seen on this page:
[http://doc.tiki.org/PluginMouseover]

Plugin mouse over is missing this files inside:

wiki-plugins/mouseover/wiki-plugins/wikiplugin_mouseover.php
lib/wiki-plugins/wikiplugin_mouseover.php

it only contains th*.info.txt file.

So it can't install (neither from cvs _mods, neither from admin mods interface (mods.tikiwiki.org )

Fixed by jonny with 58231 - thanks !


In a number of plugins that have text fields (I suspect all of them that do) e.g
- MOUSEOVER for the label parameter or the
- INCLUDE plugin for the nopage_text field,

If these are edited in wysiwyg wiki pages (the full HTML wysiwyg version) and you add text that has single quotes in it, then some sort of ‘escaping’ seems to be happening.

Every time you edit the page more and more \ characters are added in front of the single quote character so a simple MOUSEOVER label that is supposed to say:

''__Hover over here to show a wiki syntax ‘sticky’ pop-up__''

Ends up as:

''__Hover over here to show a wiki syntax \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\‘sticky\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\’ pop-up__''

Where there can be hundreds of \ after a couple of edits, and opening the wysiwyg editor takes longer and longer – presumably because it is repetitively ‘escaping’.

The first issue is that I received the notice to approve the plugin even though I already approved the plugin at the site after editing the page. This is a regression.

The second issue is that the email message is malformed. It says:

"Plugin html is pending approval on Shared_t_o_footer."

And the text "Shared_t_o_footer" is supposed to be a link to that page, but it isn't a link. What should be the URL is actually the data from the body of the plugin, that is, the entire wiki page content in this case.

Using {rcontent id=1} in an assigned module causes WSOD.

according to luciash in chat:

this "seems conflict between plugin {RCONTENT() /} and {rcontent} wiki syntax to me, because recently the syntax was made more universal and plugins can be called using lowercase {pluginname} syntax too"

placing {rcontent id=1} into an assigned module causes WSOD.

this was a big problem for me on upgrade, because I had rcontent in my 2.x installation, upgrade to 3.1 gave me WSOD. Lack of access (because of WSOD) made fixing the problem much more difficult for me, as an end-user.

According to luciash in chat:
seems conflict between plugin {RCONTENT() /} and {rcontent} wiki syntax to me, because recently the syntax was made more universal and plugins can be called using lowercase {pluginname} syntax too




note, sorry if this posts twice...

note, I posted this twice before, but with the problem code in the post,

http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2797

http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2799

and both of those now show the WSOD that I saw. So again, here we go, this time I won't post the code as I used it, as it appears to be causing the same problem on those tracker pages. So...

using rcontent in a module causes a WSOD in 3.x

according to luciash in chat:

seems conflict between plugin RCONTENT and rcontent wiki syntax to me, because recently the syntax was made more universal and plugins can be called using lowercase {pluginname} syntax too

I could not find a way to make a redirect from a page named ''foo'' to page ''foo (target)''.

When activating the preview in article ''foo'', the plugin gives out a message:

REDIRECT plugin: The redirection to 'foo (target' is disabled in preview mode.

This seems to indicate that the plugin takes the first closing parentheses to stop parsing.

When trying to save this anyway tiki complains about producing an orphaned page.

It would be nice to be able to escape the parentheses in the name of the target article.

The ultimate feature of Amazon and all the e-commerce shopcart systems is the one known as "Customers who bought this item also bought .." or "were also interessted in ..".
The feature would show objects or items that were viewed or bought by previous users in conjunction with the actual item or object.

Idea:
Applied for tiki a new plugin "Relation By Views" would allow to list related wiki pages (or even other objects) in a page likewise to existing backlinks and alias plugins as well as semantic links.
Though, the information is based on previous view counts / his of wiki pages (or other objects) that have been hit by users wihtin the same session as the actual wiki page / object.

The enhancement is obvious: we would make a step further to get implicit relations between pages / objects based on user behaviour.
Just as the advantage in ecommerce is crossselling, we would provide cross-links and encourage readers to have a look to further pages / objects.
In regard to enhancements of the basic shopping cart feature in Tiki 5, this plugin could even be used as a real "customers were also interessted in" feature.

__Not to be confused with PluginSign!__

In Tiki23 Plugin signature allow a user with editing permissions to save inline (inside the plugin code) a signature: "stored within the plugin content as image/png base64"
https://doc.tiki.org/PluginSignature

While this is visually nice, it doesn't really fit possible use case where a user signature is needed as acceptation or approval of "things" like terms acceptance, money transfer, administrative documents approval, administrative authorisation, etc.

We don't want to give the user the right to edit the page.
We need a new permission: "can use plugin signature". So a user can only sign without changing or viewing the code.

In Tiki23 Plugin signature allow a user with editing permissions to save inline (inside the plugin code) a signature: "stored within the plugin content as image/png base64"
https://doc.tiki.org/PluginSignature

While this is visually nice, it doesn't really fit possible use case where a user signature is needed as acceptation or approval of "things" like terms acceptance, money transfer, administrative documents approval, administrative authorisation, etc. Saving plugin code into the page has a tendency of helping page and plugin content breakage (like with the plugin convene).

The signature should be save as a file in the file galleries.

With it, Tiki admin should be able to add essential parameters to make the feature useable (not only nice to see but to fit real life case).
For exemple if the signature is used as formal approval or authorisation and need to be matched later with a user acceptance we certainly need things like:
* Username
* Date of acceptance (file creation or lasted)
* IP address used
* What document/object it is attached to
* ...

So later a Tiki admin or the owner of the Tiki can match document (version) and signature (user) and is able to prove "this" user with IP xx.xx.xx.xx signed this document on the xx/xx/xx.
Information exist in log more of less (username, action, ip, date, etc) we need it to be stamped with the signature file.

It would be nice this "stamped" information can be displayed easily.
IE: This signature was used by "username/ip" for "object" (version?) on the "xx/xx/xx at xx:xx"

A mechanism to reuse or forbid reusing is something we can think of.
IE : One signature for page, item and account approval.
Counter-IE: It should not be possible to reuse a signature (twice or later or after a document is changed)


By extension the file and approval can be then attached to an object (not only I a wiki page plugin body) and can be used for tracker items (important for forms, shopping, registration, etc) calendars event or other feature, etc.