Category: Wiki Plugin (extends basic syntax)

After placing a working H5P plugin on a wiki page, an edit button will appear directly below the H5P content for admins. This is similar to what appears when displaying the H5P content from the File Gallery, where it brings up the correct dialog for editing the H5P content.

However, on the wiki page, the edit button links to 'tiki-editpage.php' instead of 'tiki-ajax_services.php'. This causes the ajax popup to show the wiki page edit dialog, instead of the controller dialog. Using Chrome, I was able to test this, and the one change in the href field was able to pull up the correct dialog.

I am not able to create a show.t.o instance right now, but will create one ASAP.

If I were to hazard a guess, the issue would be in /lib/wiki-plugins/wikiplugin_h5p.php

The plugin List (or listExecute) is able to filter by range:

{filter range="tracker_field_date" from="now" gap="2592000"}

The gap is hardcoded in the plugin filter value.
It would be nice it could be one a variable such as a value within the tracker.

{filter range="tracker_field_date" from="now" gap="tracker_field_gap"}

As an extension it would be nicer it accept a Human Readable value like days or month.
It is unlikely end user has to deal with value like "2592000" (second) in a tracker item but more with value like "30 days".

On the page: https://tiki.org/TikiFest-Virtual-2021 I can edit the tracker calendar plugin from the included page... but it failed.

Seems it is not possible to edit a plugin from an included page directly.
The edit plugin button should be hidden as a quick workaround.

{img fileId="1538" thumb="box"}

How can I move the carousel plugin to the center of the page? The plugin doesn't seem to have a center alignment as own parameter, and when I enclose it in center markup, only the image caption (!) gets centered, the container of image and caption stays on the left hand side...

Is this a feature or a bug? ;-)

In 6x, 7x and 8x, the <br /> tag is displayed when there is a line break within PluginCode when PluginCode is within PluginSplit. This can be seen at [http://doc.tiki.org/tiki-pagehistory.php?page=PluginFancyTable&preview=41#Example].

Perhaps related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3883]

{syntax type="tiki" editor="plain"}
Using the HTMLplugin in Wiki WYSIWYG. First time works fine (iniital entry and save)

if you re-edit the page, once you save, data from the plugin gets lost

This does NOT happen in normal editor

HTML meant to display literally which figures inside the body of a call to the QUOTE plugin is quietly ignored, as if it had been stripped. This happened on ticket #4235. As can be seen in [https://dev.tiki.org/tiki-tracker_view_history.php?itemId=4235|the history (version 5)], I had to give up on QUOTE to keep the code displayed.

Compare https://themes.tiki.org/Shapely and https://nextthemes.dev9.evoludata.com/Shapely . The page uses the trackerlist plugin to display theme information but at the nextthemes site the source is displaying, including HTML syntax, etc.

HTML is turned on for wiki pages and is on for the Shapely page.

This problem doesn't happen at all Tiki master (upcoming Tiki 25) sites, though.

When plugin are editable on the web page, the iframe edit-dialog is hidden behind the iframe "window".

{img fileId="655"}

Whenever I try to insert an image in a wiki page and specify its width:
{CODE()}
{img fileId="51" width=100}
{CODE}
The image doesn't display properly. All I see is the plugin icon:

https://www.evernote.com/shard/s235/sh/56d7e686-a523-41e7-9df9-5059fdd80705/cbec3e47624cc4a9c0f7a45630039d06

Yet, if I display the image without the width argument
{CODE()}
{img fileId="51"}
{CODE}
It displays properly. If I specify a width that corresponds to the actual resolution of the image file, then it also works.

I have seen this problem with different file formats.

I tried to reproduce the problem on show, but was not able to:

http://user-10156-4744.show.tikiwiki.org/tiki-index.php?page=HomePage

But here are some screen shots from my 11.x site where the problem happens:

Here is a page with an image inserted with and without the width:

https://www.evernote.com/shard/s235/sh/b0e781ca-36ed-473a-a517-6ce457b568f4/2606ea1bece64d3326a2042d54ad9da0

Here is the source of that page:

https://www.evernote.com/shard/s235/sh/e2b0b7f5-53fb-479a-95c0-3dc9cf52ed9d/271ab3a14a21da68e8294dbf91d372c5

In IE7, after double clicking an image to get the image plugin editor and making changes, a new image is created at the top of the page instead of editing the image plugin.

In IE8, the same attempt appears to make no changes to the plugin, but no new image appears either.

This works in Firefox.

{syntax type="tiki" editor="plain"}
Under certain condition the img plugin add image quality information that is breaking image transparency when using .png file.

On a Tiki 30 i have the following:
{img fileId="3254" thumb="box"}

A weird background is visible.

The plugins:
-+{img type="fileId" featured="y" class="img-fluid text-center"}+-

The HTML:
{CODE()}
<img src="dl571?display&amp;format=png&amp;quality=75" class="img-fluid text-center regImage pluginImg571 img-fluid featured " alt="Image">
{CODE}

If I remove "format=png" the image is displayed with the correct transparency.

It seems to come from here: lib/wiki-plugins/wikiplugin_img.php

{CODE()}
if (isset($imgdata['quality'])) {
$src .= '&format=' . str_replace('image/', '', $imgdata['file']->filetype) . '&quality=' . $imgdata['quality'];
}
{CODE}


Note a brand new Tiki by default (like demo.tiki.30.t.o) doesn't show the issue.
Could be file quality encoded data (on the file) or something that changed in the code.

---

I used the parameter "An image anywhere on the internet" and pointed to my file to fix the issue:
{CODE()}
{img type="src" src="display571" alt="Sovereign Offsite Backup Service" responsive="y" class="img-fluid text-center"}
{CODE}

Test on dev.t.o

{img fileId="3258" thumb="box"}

I can't upload images any more to wiki pages at doc.tw.o since upgraded to tiki4.
Using firefox 3.5.4 under GNU/Linux

Can anybody confirm on other OS or browsers?

If you you the image plugin, and specify "imalign" it produces an attribute "position=center" etc. on the a tag, but that attribute does not exist, and furthermore does not appear to do anything.

The imalign seems to e broken for SVG files, but does work nicely for other images.

At some point someone added that attribute for some kind of reason, am I missing its use or is this nothing more than invalid HTML?

just image
{img fileId="974" thumb="box"}

image with align specified
{img fileId="974" thumb="box" align="center"}

image with imalign specified
{img fileId="974" thumb="box" imalign="center"}

On a Tiki 18 I have an image displayed using
~pp~{img type="fileId" fileId="331" width="30%" responsive="y"}~/pp~

After upgrading to Tiki 21 the image plugin show a PNG default image instead of the real image.

If I change it to ~pp~{img type="fileId" fileId="331" responsive="y"}~/pp~ it work.

Update: After testing on an instance seems something very specific to a Tiki configuration. I con’t reproduce. Closing.

revision 21658: with -+~np~{img src="img/smiles/icon_smile.gif" alt=":-)"}~/np~+- I get "No image specified. Either the fileId, attId, id, or src parameter must be specified."

Since {commit id=24627}, the IMG plugin supports percentages in its width or height parameter to scale the image. For example...
~np~{img fileId="2970" width="50%"}~/np~
... would display image 2970 with its original dimensions halved.

This was unfortunately broken for Tiki 9 and later on some systems by {commit id=37006}. Setting dimensions this way is ignored, for example on French systems, which use a comma as decimal separator instead of a point.

The attached patch fixes in 2 ways. Any one is sufficient. The change to tiki-download_file.php is not quite clean as it alters $_GET.

Note that this exposes a lack of validation in tiki-download_file.php.

{syntax type="tiki" editor="plain"}
The parameter thumb="box" is not applied anymore.

The sample below should be a thumbnail not a full screen image.

{img fileId="1215" thumb="box"}

In a wiki page set an img plugin, choose, image from gallery (file), upload an image, save.
Back on the page click on the "edit plugin" icon.
File ID, click on the "image" link (picture selector) or change by hand the File ID.
Click submit, nothing change.

It took me hard time to reproduce but you got it here : http://bsfez-11581-5669.show.tikiwiki.org/tiki-index.php?page=HomePage

It seems it is something to do with the hebrew text in the fancylist.

When using the ImgPlugin with "mouseover" or "mousesticky" and have aligned teh thumbnail to be right, after a mouseover or a click, the thumbnail moves to the left.

Example:
{CODE()}
{img type="attId" attId="1" thumb="mouseover" imalign="right" alt="Image1"} __mouseover__ Full size image appears when thumbnail is moused over;.
{CODE}

{CODE()}
{img type="attId" attId="1" thumb="mousesticky" imalign="right" alt="Image1"} __mousesticky__ Full size image appears when thumbnail is clicked. full size image stays open as long as no further click happens.
{CODE}

I've seen the gorgeus work done with jquery to allow re-sorting data in tables at wiki pages when using the ((doc:PluginFancyTable))

That would be also awesome if enabled in the ((doc:PluginTrackerList))...

This way, we would even allow the conflict between cache and sorting for anons... (see this other report [bug2898] )

Hello,

When you want to create a form to embed a tracker you need to put the trackerId and the fields Id. I improved them in a more user friendly way in order to avoid to remember the ids.

__Before__:
{img fileId="1114" thumb="box"}

__After__:
{img fileId="1115" thumb="box"}

I have uploaded the files modified.

The modified files are:
*lib/wiki-plugins/wikiplugin_tracker.php
*lib/jquery_tiki/tiki-trackers.js
*lib/jquery_tiki/tiki-jquery.js
*lib/tiki-js.js

You will found the modified code tagged inside
// NOTE: Start Modification
......code....
//NOTE: End Modification

Suggestion taken from doc.tw.o authors forum:
[http://doc.tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=1&comments_parentId=427]

{QUOTE()}
Re: Styles and Themes
en: Dm 19 de Jun, 2007[05:06] respon
> Use this thread to discuss the page:: ((doc:Styles and Themes))

About the new content here, I think it might be better not to duplicate the themes.tw.o information at this site. As I understand it, the information at each Tiki site (tw.o, doc.tw.o, etc.) should be unique and just linked to if it needs to be available to users at another site. When putting themes.tw.o together, some content was moved from tikiwiki.org to there, to avoid having it in two places.

Pages duplicated at different sites will become out of sync when one side is updated. If we want to actually display the information at more than one site, is it possible to have an intertiki include plugin so updates are automatic?

I believe the focus of doc.tw.o is how to use the standard Tiki package. That means info on extending the default Tiki would be at mods.tw.o, themes.tw.o, etc.

-- Gary
{QUOTE()}
Re: Styles and Themes
en: Dv 22 de Jun, 2007[11:52] Editar respon
Hi Gary,

I agree. My my reason to add a copy of documentation work in themes.tw.o is that is included in next pdf file produced from doc.tw.o Documentation structure with the rest of documentation (there was a big lack of information in current documentation site about the state of the art of themes and styles available in Tiki community...)

A solution could be using SNARF plugin, but it's not available at doc.tw.o right now, and some coders don't like to allow snarf splugin to be available for registered users, since the regex param can be dangerous to allow control of your tiki site to others...)

So the best solution "could be" (from my point of view) having a modified version of SNARF plugin like this:

1. allowing registered users to call it (and snarf'ed content viewable by anonymous), but having the regex param restricted to editors or admins (through adding a new perm tiki_p_snarf_regex or similar, assignable to some groups and off by default for registered).
2. having a new optional param to avoid getting lateral columns for tiki sites. (maybe allow avoiding header and footer from content snarfed from tiki sites, also?)


This way, content could be evolving in the source sites, and being automatically updated at view time in doc.tw.o.

But we need help from benevolent coders to make this happen...

^
Btw, current documentation is (only) at:
[http://tikiwiki.org/PluginSNARF]

And an example of usage [http://gclub.ub.es/tiki-pagehistory.php?page=prova&preview=5|here], showing the problems when snarfing tiki sites like doc.tw.o with left column...
^
{QUOTE}
{QUOTE}

Found an bug where including multiple excerpts from the same page would only display the first excerpt. Any subsequent includes would display empty text.

On attempts after the initial one the get_page_info() function is not called.

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