Category: Wiki Plugin (extends basic syntax)

{syntax type="tiki" editor="plain"}
Any text generated by a plugin is having it's backslashes doubled. Looks like "addcslashes" is being called somewhere it shouldn't. Eg: Put a single slash into a CODE plugin block, and examine the output.

From several discussions;

The learning curve of Wiki page editing, which pretty a basic need, is longer than a lot (if not most) other web application. Things require knowledge and too many clicks to be found and understandable.

Improving the way a wiki page is edited by default is mainly a design UX/UI aspect as all the code is here already.

For example and comparing to Confluence that, from users point require 15mn to have someone working;

* The editing space by default is all full-screen so you have focus on tool you are using right now and not everything your Tiki has
+ ~~#F00:and not confined in a tiny space with what’s left from a screen with menus, preview, header, footer etc~~
* The toolbar by default is a simple as possible (one line) with very clear options for not-techy first time user better comprehension
+ ~~#F00:and not configured by and for admins / techies that don’t want to customise their toolbar~~
* The "main" plugins (they call it macro) are available under a dropdown
+ ~~#F00:and not with the help menu, tab plugin, search it in a small space~~
* You can see/search all the plugin in a large space using "common" terms and big icons
+ ~~#F00:The plugin/macro name is reduced to what is does as short as possible and not a weird name someone gave to its plugin or a long list of words attached to say what it does in a tight space with small text and small icons~~

I think we should have a look at the way it is done and we could improve pretty quickly the way it work.

__Screenshot__
Full screen simple editing by default (the macro/plugin access is under the "plus" button, a dropdown for the common one and direct access to all the others);
{img fileId="1212" thumb="box"}
{img fileId="1213" thumb="box"}

The plugin/macro access is elegant and easy to read
{img fileId="1214" thumb="box"}

I tried to understand if it was possible and how to use the tablesorter with tracker filter plugin.

The trackerfilter modal is NOT user-friendly.
Too long list of things the user may not necessarily needed (menu child accordions would definitely help reducing the tremendous amount of information visible there)
The explanation have been copied and pasted as is from another place and hardly make sense.
Fields are not grouped together, naming is not helping (table sorter is hardly if ever found in the options and parameters list or help)... It is a mess and it took me 30mn of test to make a sample visible here : https://doc.tiki.org/PluginTrackerFilter#Trackerfilter_with_table_sorter_setting_to_perform_calculations

{syntax type="tiki" editor="plain"}
Tiki Wiki has a plugin named Layout : https://doc.tiki.org/PluginLayout
"Create out of the box unique landing pages by turning off header, footer, and site columns."

It is almost very hard to figure what is the purpose of a plugin named "Layout" (https://en.wikipedia.org/wiki/Layout) in Tiki without looking at the documentation and even reading it may confuse the reader. (landing page ?)

While there will be a tons of interpretations we should find a better name that allow people to understand what, simply put, this plugin can do.

We already have:
* ((doc:PluginTrackerStat))
* ((doc:Computed Tracker Field))

But we would need something additional for the following use case:

We have a tracker with a list of tasks. Each task has typical values:
*Open/Pending/Closed (tracker status field)
*Name (text)
*Description (text area)
*Assigned to (user)
*Assigned by (user)
*Priority (drop-down of 1 to 5)
*Creation date (system generated field)
*Last modification date

This is very similar to:
http://profiles.tikiwiki.org/Simple+Bug+Tracker

((doc:PluginTrackerStat)) could provide some stats on how many tasks are in each priority.


Now, imagine each task has 3 additional values:
*Original estimate (do not change the value of this field)
*Hours spent so far
*Time remaining estimate.

((doc:Computed Tracker Field)) could calculate 2 additional values.

* ''Current estimate'' would calculated by ''Time remaining estimate'' plus ''Hours spent so far''
* ''How on-target are we?'' would calculated by ''Current estimate'' divided by ''Original estimate'' times ''100''

So far, so good!

However, we would like to know:
*The total number of all hours of work remaining.
*The overall ''How on-target are we?''

((doc:PluginTrackerList)) coudl be extented to have a report of the total number of hours, with certain filters.

Then, Tiki could be used to manage a Tiki Sheet:
http://profiles.tikiwiki.org/Time+Sheet

In the future, we could generate ((doc:Graphics and Charts)) from this data, like we do in the ((doc:spreadsheet))

Trunk BBB integration doesn't seem to work with new version of BBB 0.81

This same configuration has been tested on an older version of Tiki 9 and it worked

Creating a new page containing the CODE initial tag and then the CODE close tag
and inside this having a $0 produce a 500 internal server error

Reproduced on two different migrated tikiwiki sites (from 1.97 and from 1.9.9)
(working well BEFORE upgrade) and on the feature/usability tikiwiki forum site itself.

Adding a comment on the 4929th line in lib/tikilib.php you can see it again, but without
proper substitution

The problem is blocking ($0 is several times used inside linux script tipically contained
into CODE tags)

The bloglist plugin ignores the permissions.

If no view blog permissions are assigned to (say) registered users, attepting to view the blog is blocked correctly.

However, if the same blog is shown using the bloglist plugin, on a page the user has permission to view, the blog posts are displayed anyhow.

Old:
On a page that has a Bootstrap Tour (Tour wikiplugin), if the page has inline edit icons and the pointer hovers over one even quickly, the tour popover disappears, ending the tour.

New:
Sorry but I'm seeing this behavior again in a recent revision of branch 15 (r57769). I'm not sure when the problem reappeared.

Newest:
Fixed.

When an H5P project is inserted into a wiki page, the browser url takes on the name of the H5P project application. Specifically with SEF url enabled.

For example, if I create an H5P project, then I insert it into a wiki page by
{CODE(theme="default")}{h5p fileId="1373"}{CODE}

The browser tab no longer shows the wiki page name such as Wiki|Fubar Page
Instead the browser tab will display Wiki|h5p_file_name

Here is a screen capture of my user case, I created an H5P project for collages. I name my new H5P project home_page_collage and saved it to the file gallery.

Using the syntax above, I inserted the collage into my wiki home page to display a group of images. Once the H5P project was inserted and saved into my home page wiki, the browser tab started displaying the H5P project file name, instead of Wiki|HomePage. See screen capture of error in browser tab.
{img fileId="1121" thumb="box"}

{syntax type="tiki" editor="plain"}
When I create a button using Tiki29 several parameters (not all) are duplicated in the plugin syntax.

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

Found a bug in the Button plugin, when using the colorbox feature. It just redirect to the href link, instead of opening the page in a colorbox

Can be seen in doc.tiki.org in https://doc.tiki.org/PluginButton , and also in https://doc.tiki.org/ColorBox

Thanks

Button plugin is asking for plugin approval on templates each time a page is open for the first time.

This is a pain when you use a template to display items, customSearch, etc.
It is like I have to scan all the Tiki possible pages and mass approved the plugin changes.

I’m extensively using wiki page as template (list, listExecute, customSearch) and have several project built that way (not using smarty templates).

It has been discussed that this was introduced in Tiki16 and so far not fixed.

The wikiplugin buttons labels are not translated.
This force users to add more code to manage it.
* Use the HTML wikiplugin and use duplicate set of buttons for each language.
* Use the LANG wikiplugin with duplicates set of buttons per language.

Not very elegant...

I noticed that all the calls to the SQL plugin were killing my intranet website when going to version 4.x. Digging deeper I've narrowed it down to the ADONewConnection call of the wikiplugin_sql.php file. On that line of code PHP dies and I am left with a white page. I have tried playing with the call itself and even going to PDO which worked well enough to complete the page without dying, however I don't know enough about the PDO paradigm to actually retrieve data and rewriting the entire data retrieval strategy seems a bit extreme.

Upon learning of dbreport, the only other plugin I know of to also use ADONewConnection plugin, is also failing I've decided this might be an issue in the plugin engine itself which is beyond me to resolve. One black box at a time is my general approach to things and this now relates to ADO and the plugin engine.

I will continue to look at this issue, however assistance from bigger brains for PHP than my own would be a good thing.

I tried to add my name to the schedule created with plugin convene in ((Tiki11)) and clicking at the "Add user" button (or Add date) did nothing when I was visiting the page with mobile interface. Same with the button to edit choices.

Same issue with Chrome or Firefox on Android.

---

To reproduce:
http://xavi-9794-4778.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage

u: admin
p: 12345

Change to mobile (link in module in the right column)
Click at "Add user" button (or Add date)
Nothing happens

Tried on 12, 15, 16 and 17 to create a plugin alias based on : https://doc.tiki.org/Plugin+Alias

Work only in 12x.

I created an instance.

In a new post in the t.o forums I tried to set a plugin img using the help icon;

#Uploading an image at t.o didn’t work (cross error on elfinder)
#Using an image anywhere on internet didn’t work the plugin wasn't saved on the post
#Writing the plugin syntax (manual) was saved but the result is a broken image and a correct image (image 1 on 2).

https://tiki.org/forumthread68989-Tracker-List-Image-Display-Params-Have-No-Effect?topics_offset=1

{syntax type="tiki" editor="plain"}
Sorry I cannot find "wiki-pages" to check in the report-a-bug-form.


1. I edit a wiki page
2. I move the mouse over the save button
3.! I get a help-cursor and the text in the textarea scrolls to the very bottom
4.! I click on save, but nothing happens

I got this behavior REV 24514 and on your REV 24503

I get the same behavior on Firefox, Chrome and WinXP-Safari.

best regards
Thomas

See the example on https://doc.tiki.org/PluginList-output-control-block?latest=1&no_bl=y#Example
The Carousel formatting output is messed up (arrows under the images, both images shown, no carousel look).

When trying to use a tracker category field as a filter, only the value "Any" is displayed.

The very useful wiki plugin catorphans only works with wiki pages.

The documentation suggests it is sort of set up to deal with different types of uncategorised objects by setting the objects=> parameter to various values ie wiki|article|blog|faq|fgal|forum|igal|newsletter|poll|quizz|survey|tracker.

But looking at the plugin code, the code comments make it clear that the development is not yet complete and only the 'wiki' object has been coded.

The documentation has been updated to make this clear - but extending this plugin to the other features would be very useful now that Categorisation is the major permission/access control mechanism in Tiki

If you create a {CODE()} {CODE} block in a
wiki page or blog post which contains a "$" followed by a digit somewhere on the page, the page will not be rendered correctly. In fact, the text "($10), $0" will prevent the entire page from being rendered at all. In a blog post it can make the entire blog inaccessible.

Seen in v2.3.

Sounds identical to this closed tracker item: [http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=218&highlight=code|Wiki: CODE block may not contain "$0"]

{syntax type="tiki" editor="plain"}
This bug is seen by our IE 8 clients. We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

Our users are editing in the CKEditor WYSIWYG and try the Code plugin from the toolbar. The Code window opens as expected and the users enter their code in the correct field. On pressing Insert (or Replace) the code plugin is added in the editor but there is no contents in the plugin. If I open the normal editor it displays as%%%~np~{code caption="MyCode.java"}~/np~%%% which is completely the wrong syntax.

If I try using the Code option in FF then it opens a new window and I can add the code just fine. I view from the normal editor and it reads%%%~np~{CODE( caption="MyCode.java")}public class MyCode {
//testing a point
}{CODE}~/np~%%% which is correct.

Since IE is our corp standard our users need to be able to add files using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

Thanks,
Tim

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