Category: Wiki Plugin (extends basic syntax)

The WikiPlugin_regex.php is broken, unless you put your regular expression on a page called "pageName"

See this forum discussion: https://tiki.org/forumthread60794?topics_offset=1

PluginManager returns this info:
icon - url - Enter a Tiki icon file name (with or without extension) or path to display a custom icon

This does not work.
You can only change the icon by editing /lib/smarty_tiki/block.remarksbox.php
switch ($type) {
case 'warning':
$class = 'alert-warning';
$icon = 'warning'; <<<You can change the icon by changing this, but see Note 1
break;
...

Note 1. This is not the icon name. It is the icon name as defined in /themes/base_files/iconsets/default.php
Ex. 'admin' => array(
'id' => 'cog',
'admin' is what you must call in the above block.remarksbox.php code, if you want to see the cog icon.
If the icon you want to use has not been defined in this file, you must manually modify the file to include your wanted definition.

I'm setting the Easy to solve? at 5 even though I do offer...
A quick 5 minute temporary fix would be to update the function info() in /lib/wiki-plugins/wiki/pluginin_remarksbox.php
* Currently it is not an option, so actually I guess it could be removed.
**But some sort of note could be made with a bit of the above info.
You must be a server admin to be able to change the icon at this point.

The longer term solution is to find out what actually caused the problem.
*Rick Sapir noted "...works in 9LTS, but not 12LTS or 15.x. Maybe a regression?..."

{syntax type="tiki" editor="plain"}
Using PluginRSS ([https://doc.tiki.org/PluginRSS]) to display information from an external Tiki calendar events RSS feed, the events display most distant (ex: October) first, then September, then August. It's more logical and more typical to display the nearest upcoming event first and the ones farther in the future after that. That's the way the display works in the Upcoming Events module, which makes sense.

I don't see a way to change the sorting of events when configuring the plugin. In particular, if I limit the number of events displayed to 1, I would like the next, upcoming event to display, not the one that's several months away. I don't see anything in the docs (Feeds, Calendar, etc.) or the feature interface about controlling this.

The order is correct (closest event is first) in https://tiki.org/tiki-calendars_rss.php But when I use PluginRSS in a local wiki page, the order is reversed (most distant event is first). This is what seems to need correcting, or at least a sorting order parameter added.

When putting a plugin onto a blog post which requires parameters, the parameters are not passed in or are passed in as an &. This happens when the => syntax is used, or quotes are used around the parameter. These are otherwise fine when in a wiki page.

Most plugins appear to be affected on my installation - which was an upgrade from 1.8.4 to 1.9.2.

They render okay when viewing individual posts, or previewing, which leads me to beleive it is in tiki-blog_view.php somewhere.

After diffing the files, the largest visible change was the addition of categories into the blog, this is however not affected by turning off the feature in admin.

I am putting this high on my own priority list as I cannot upgrade my live site to 1.9.2 (although it has had some secuirty fixes put on it) until this is solved as I do not want to break my history of blog posts using plugins.

Perhaps it is worth a shot on this site or tikiwiki.org to see if plugins are affected here as well with that.

When putting a plugin onto a blog post which requires parameters, the parameters are not passed in or are passed in as an &. This happens when the => syntax is used, or quotes are used around the parameter. These are otherwise fine when in a wiki page.

Most plugins appear to be affected on my installation - which was an upgrade from 1.8.4 to 1.9.2.

They render okay when viewing individual posts, or previewing, which leads me to beleive it is in tiki-blog_view.php somewhere.

After diffing the files, the largest visible change was the addition of categories into the blog, this is however not affected by turning off the feature in admin.

I am putting this high on my own priority list as I cannot upgrade my live site to 1.9.2 (although it has had some secuirty fixes put on it) until this is solved as I do not want to break my history of blog posts using plugins.

Perhaps it is worth a shot on this site or tikiwiki.org to see if plugins are affected here as well with that.

It is possible to discard others content when editing directly a plugin of a previous version of a page.

At : https://tiki.org/Roundtable+Meeting+2017+04
Load the page and keep it on your screen / browser (A).
Have or simulate another user that go to the page and edit the plugin convene and save their changes (B).

Go back to your screen (A) without reloading the page. (you don't see new input).
Edit, do changes and save.

The changes from the other user (B) are gone and they’re only shown in history.

Plugin edit should start with a kind of "auto-refresh the content" then edit on "updated" content.

On a Tiki Master I edit a page and using the "Choose or Upload images" icon I upload an image in the Tiki file gallery.
Then I use the "Insert" button.
The image is displayed and it works.

However if I edit the plugins settings using the "Image" modal and save, it will throw an error as the field "Image Source" is not populated anymore.
Previously (Tiki25) it was working just fine and the source of the image was set automatically.

{file type="gallery" fileId="2054" showicon="y"}

Since a few month Google is pushing/improve video content search-ability.
Now they added some verification a wiki page with a youtube tiki plugin to display a youtube video on a page will have the Search Console to report errors.

''Google could not determine the prominent video on the page
The videos on these pages aren’t indexed or served on Google as video results''

The only solution I found so far is to use an iframe
{CODE()}
<div class="iframe-container">
<iframe class="iframe-video" src="https://www.youtube.com/embed/videoseries?list=PLkjRsdmwSB14C2mEI6N9apC_wTLaoZXqD" allowfullscreen></iframe>
</div>
{CODE}

Not sure if this is a bug as it may be something we forgot, code we didn't update or Google added.

You can do this now with a ((doc:plugin alias)) but you need to change the name. Not cool.

Goal:
to be able to centrally, without changing the code, overriding the defaults for certain plugins.

Ex.: for my site, I want sticky=y for ((doc:pluginmouseover))

I should be able to edit each quadrant:
http://tikiwiki.org/SWOT

Split plugin is not working when we try to set fixed pixel width for columns. They are percentages instead, as you can see here:
http://themes.tikiwiki.org/tiki-index.php?page=TestPluginSplit


Also, there is some info here & a patch:
http://tikiwiki.org/PluginSplit

{CODE(caption="No title/text, image displayed with correct height" theme="default")}{SWIPER(fileIds="729,731,728" ...{CODE}

{CODE(caption="Title and Text displayed, but image reduced in height" theme="default")}{SWIPER( effect="slide" navigation="y" titleColor="#fff" descriptionColor="#aaa" slideContentBg="rgba(00, 00, 00, 0.5)" slideContentPostion="top:20%;left:20%" displayThumbnails="n" loop="y" autoPlay="y" autoHeight="n" slidesPerColumnFill="column" centeredSlides="n" slideToClickedSlide="n" freeMode="n" preloadImages="y" updateOnImagesReady="y")}|title:Title 1; text:Text 1; image:tiki-download_file.php?fileId=729|title:Title 2; text:Text 2; image:tiki-download_file.php?fileId=731| title:Title 3; text:Text 3; image:tiki-download_file.php?fileId=728{SWIPER}{CODE}



Update (by Mike Finko), Nov. 17, 2020):
Here is a screen cast of the 'Cube' slider incorrectly displaying -
{file type="gallery" fileId="1466" showicon="y"}

and here is the code that generates it:
{CODE(theme="default")}::{swiper fgalId="6" effect="cube" navigation="y" width="500px" autoPlay="y" autoPlayDelay="2s" displayThumbnails="n" autoHeight="n" slidesPerColumnFill="column" centeredSlides="y" slideToClickedSlide="n" freeMode="n" preloadImages="y" updateOnImagesReady="y" loop="y"}::{CODE}

{syntax type="tiki" editor="plain"}
--This does not work anymore:-- Connot reproduce on show. Seems to be some local issue :( {sign user="luci" datetime="2018-01-22T20:46:55+00:00"}
{CODE()}{tracker trackerId="8"}{CODE}

It used to work. Showed the form with all the fields when not specified by -+fields=""+- param.

The inline help even claims so:
"Colon-separated list of field IDs to be displayed in the form as input fields. __If empty, all fields will be shown.__ Example: 2:4:5"

Now just shows the Save button alone.

__Update:__ Just encountered the same issue on a site upgraded from 9.x to 21.x :( Does it need some new preference to work? {sign user="luci" datetime="2020-10-13T17:56:56+00:00"}

After submitting a tracker item using PluginTracker, the form doesn't show after the page refreshes. This is because of certain url parameters that are added when the page refreshes. For example the url upon refresh can be:
tiki-index.php?page=HomePage__&ok=y&iTRACKER=1#wikiplugin_tracker1__

The parameters in bold above cause the form to not show. If the following lines are commented out in wikiplugin_tracker.php (around line 986 in 12x) then the form will show:
{CODE()}
} else if (!empty($page)) {
$url = "tiki-index.php?page=".urlencode($page);
if (!empty($itemId)) {
$url .= "&itemId=".$itemId;
}
$url .= "&ok=y&iTRACKER=$iTRACKER";
$url .= "#wikiplugin_tracker$iTRACKER";
header("Location: $url");
exit;
{CODE}

I set the admin password for the show instance to 12345. See instructions for recreating on the home page of the show instance.

The word count limit option for the text area field is not working on the input form when inserting new tracker item using PluginTracker.

It appears the problem is that the ''~np~onkeyup~/np~'' attribute of the ''textarea'' HTML element is empty as follows:
{CODE(wrap=1)}
<textarea id="area_52d52c549d722" name="ins_1" cols="50" rows="15" onkeyup class="wikiedit"></textarea>{CODE}

In Tiki11 it works and the ''textarea'' element and ''~np~onkeyup~/np~'' attribute look like this:
{CODE(wrap=1)}
<textarea id="area_52d52c549d722" name="ins_1" cols="50" rows="15" onkeyup="wordCount(5, this, 'cpt_1', 'Word Limit Exceeded')" class="wikiedit"></textarea>{CODE}

{REMARKSBOX(type=note title=Note)}''Please note that I was not able to run the show.tiki.org instance due to Composer not having been run. Here was the error message when clicking on [http://lindon-10302-5096.show.tikiwiki.org]:

Your Tiki is not completely installed because Composer has not been run to fetch package dependencies. You need to run 'sh setup.sh' from the command line. See http://dev.tiki.org/Composer for details.{REMARKSBOX}

Say I use the plugin in on the page "Edit Publisher&itemId=1159".

{CODE()}{tracker trackerId="18" url="Publishers" wiki="Edit Publisher Template"}{CODE}

I asked it to go to the page "Publishers" after being submitted.

Instead it goes to
tiki-index.php?page=Edit+Publisher&itemId=1159&ok=y&iTRACKER=1#wikiplugin_tracker1

-----------------------

In the tiki show instance, I have created a tracker for colors and pages for displaying and editing the items.

# Go to http://hrsms-11204-5079.show.tikiwiki.org/tiki-index.php?page=Colors
#Click on "bleu". You will be taken to Edit+Color&itemId=2
#View the source. Note the url parameter is set to "Colors"
#Change the spelling to "blue" and hit save. You will be directed to Edit+Color&itemId=2&ok=y&iTRACKER=1#wikiplugin_tracker1. The edit fields will no longer be displayed.
#Click on the button provided (my workaround) to go back to the "Colors" page, where you will see the change did take effect.

Currently, after a report, the filter fields still appear at the top. This looks weird. Should be below or should be possible not to show, and you have a button "another search"


Or: send to another page?

To reproduce:
http://dev.tiki.org/Search+Wishes

# Search wishes for user "marclaporte"
# Click to sort by date

List is gone

This worked in Tiki 11.x. I use the same site each semester for my teaching course, and the system worked in 9.x, 10.x, 11.x, but not with current version (12.x, tried updating to latest svn version but no change).

I have a PluginTrackerList call with the param "view=user" in it. It used to filter items in the tracker so that only those belonging to the user where shown. Nowadays, user can not see any tracker item. And if they are granted the perm to view the tracker, they can see all items in the tracker.

Reproduced in show.t.o:
u: admin
p: 12345

http://xavi-9794-5126.show.tikiwiki.org/tiki-index.php?page=Bug_Tracker

Log in as simple registered user __user1__ and see try to see your items only:
u: user1
p: user1


I cannot find any other combination of tracker perms and trackerlist params to reproduce the same behavior. So it looks as a regression to me.

Any tip?

Reopening -- regression in 3.x. See http://doc.tikiwiki.org/PluginVersion for an example

---


Version 3 shows version 3, 2 and 1.

See http://doc.tikiwiki.org/PluginVersions and try the test which has more than 2 versions


Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=800

The ((doc:PluginWantedPages|WANTEDPAGES)) plugin will display literal ~amp~nbsp; HTML entities in the header of the display table.

The WYSIWYG plugin no longer works starting from Tiki 17 if there is no page URL parameter, for example on the homepage.
I wrote in the wiki page the usual way to have the plugin to show up:
{CODE()}
{WYSIWYG()}
{WYSIWYG}
{CODE}
I save the wiki page.
When one clicks the "Edit" button at the bottom right corner of the plugin, a JavaScript error occurs:
{QUOTE()}Uncaught TypeError: Cannot read property 'type' of null
at HTMLButtonElement.<anonymous> (tiki-ckeditor.js:188)
at HTMLButtonElement.dispatch (jquery.js:5206)
at HTMLButtonElement.elemData.handle (jquery.js:5014){QUOTE}

jqueryTiki.current_object is null.

If the homepage is accessed using relative URL tiki-index.php, the issue occurs.
If the homepage is accessed using relative URL tiki-index.php?page=HomePage, the issue does not occur.

Tiki 16 does not have this issue.

I can't make a simple ((doc:PluginWysiwyg)) call to work as expected in Tiki18 (afaik it worked as expected up to Tiki16 at least; I didn't try in Tiki17).
{CODE(ln=1)}
{WYSIWYG()}
foo
{WYSIWYG}
{CODE}

Using wiki plain text editor.
Unluckily, I have NOT been able to reproduce the issue in a show.t.o instance
http://xavi-9794-6661.show.tikiwiki.org/tiki-index.php?page=Community
(it works as expected there)

And I've noticed that if I clone the same page contents from my production site to a page in the show.t.o instance, the issue can't be reproduced: admin user can open the wysiwyg editor coming from the plugin wysiwyg.
And if I add perms to the page in my production site so that anons can edit the wiki page, the issue vanishes
Odd, after adding and removing perms in that page in my production site, I can't reproduce the issue any more. :-/

Ok, I'll close this bug report, with a tag "works for me". Who knows what was going on.

See this section of a plugin trackerlist that should produce a table of tracker items:

Failing to load in 17.x:
https://dev.tiki.org/Profiles-Wizard#Closed

Working in trunk:
https://nextdev.tiki.org/Profiles+Wizard#Closed

Error in the inspector :
{CODE()}
Uncaught TypeError: Cannot read property 'childNodes' of null
at qa (min_main_8586bd0….js:sourcemap:176)
at Ja (min_main_8586bd0….js:sourcemap:176)
at a.fn.init.append (min_main_8586bd0….js:sourcemap:176)
at a.fn.init.<anonymous> (min_main_8586bd0….js:sourcemap:176)
at T (min_main_8586bd0….js:sourcemap:176)
at a.fn.init.html (min_main_8586bd0….js:sourcemap:176)
at Object.format (Profiles-Wizard:3748)
at Object.processOptions (min_main_8586bd0….js:sourcemap:7026)
at Object.getOptionSource (min_main_8586bd0….js:sourcemap:7024)
at Object.buildSelect (min_main_8586bd0….js:sourcemap:7032)
{CODE}

There are warnings before the error:
{CODE(theme="default")}min_main_8586bd006813c3eea36df705ff53807c.js:6888 Tablesorter Warning! "table.config.widgetOptions.resizable" option not recognized
validateOptions @ min_main_8586bd006813c3eea36df705ff53807c.js:6888
setup @ min_main_8586bd006813c3eea36df705ff53807c.js:6713
(anonymous) @ min_main_8586bd006813c3eea36df705ff53807c.js:6892
each @ min_main_8586bd006813c3eea36df705ff53807c.js:175
each @ min_main_8586bd006813c3eea36df705ff53807c.js:175
$.fn.tablesorter @ min_main_8586bd006813c3eea36df705ff53807c.js:6892
(anonymous) @ Calendar:28998
j @ min_main_8586bd006813c3eea36df705ff53807c.js:175
k @ min_main_8586bd006813c3eea36df705ff53807c.js:175
setTimeout (async)
(anonymous) @ min_main_8586bd006813c3eea36df705ff53807c.js:175
i @ min_main_8586bd006813c3eea36df705ff53807c.js:175
fireWith @ min_main_8586bd006813c3eea36df705ff53807c.js:175
fire @ min_main_8586bd006813c3eea36df705ff53807c.js:175
i @ min_main_8586bd006813c3eea36df705ff53807c.js:175
fireWith @ min_main_8586bd006813c3eea36df705ff53807c.js:175
ready @ min_main_8586bd006813c3eea36df705ff53807c.js:175
S @ min_main_8586bd006813c3eea36df705ff53807c.js:176{CODE}

This affects the wishes alias.

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