Category: 11.x

Menu Wiki 'List Pages' and 'Create a Wiki Page' are two tabs on one page.

After visiting 'Create a Wiki Page' the focus stays on this tab when visiting 'List Pages'. Average expectation is assumed to refocus to the new tab.

Module months_links is expected to show links to the months in the last year where posts occurred, but also display a link to the previous years, so that the user can click to the previous year to list the months that hold posts, etc.

The user expected to be able to list all months where there were posts, from the previous years, but it only display posts from the last 12 months.

The rows param by default gets the value 10 (like month october, our current month by the time of this writing)
Increasing the value shows more links (from previous years). However, it seems that Value max="-1" (show all posts, with no max limit) doesn't fetch them all.

When using pluginRedirect in WYWIWYG, if a page already has a redirect pointing to it, if you try to create another redirect to it from a different page, it doesn't do anything. The js console shows -+TypeError: c is undefined+-, -+...ls(b.startContainer)&&d.contains(k)&&g.contains(h)&&h.isIdentical(k)){h.moveChil... ckeditor.js (line 319)+-

Here is a clearer example:

you have pages A, B, C

C redirects to A, when in WYWIWYG editing page B you cannot use pluginRedirect to redirect to page A, because the insert button doesn't work.

demonstrated and snapshotted. In instance I created pages A, B, C, set redirect from C to A and approved. Tried set redirect from B to A and encountered same problem. Note all this was done in WYSIWYG, and it works fine in Tiki Editor.

Visiting nextdev.t.o (trunk 12.0) in mobile mode (using chrome for android), I can't click in the watch icon, for a tracker item.

I can't either on the printer icon on each tracker item.

when I visit nextdev.t.o in mobile mode (using chrome on android), the wiki pages show up in non-mobile mode (the string "Loading..." shows up in clear text at the top of the screen).

When I move from wiki pages to tracker items, then mobile mode works as expected.

---

Fixed, thanks Jonny. {sign user="xavi" datetime="2013-11-17T08:43:01+00:00"}

The following (without a space between braces) does not work anymore:

~np~
you can use the ~np~{{user} }~/np~ ~np~~/np~~/np~ ~np~((doc:Argument Variables|Argument Variable))
~/np~

Instead the Argument Variable which is inside __np__ gets parsed as current user login name.

__Update:__ updated the Subject field to more reflect what is the report about

{img fileId="310"}

To reproduce, do a preview of a document in AJAX (so above) and use the toolbar (ex.: bold)

Hello
If you use this plugin,:


{REMARKSBOX(type=>Tip, title=>Version 11.x)}
...page...
{REMARKSBOX}

It will not produce a page break.

Since a demo reproduces this bug, I will not use screen capture to demonstrate it. See:

http://demo.tiki.org/11x/Page+Break

The ~np~...page...~/np~ appears broken in 11.0. It should break the page into sections.

See demo: http://demo.tiki.org/11x/tiki-index.php?page=Page+Break

In 12.x LTS when -+~np~…page...~/np~+- syntax is enabled and used in a wiki page __where collapsible sections are present__ ( -+~np~!!-Foo Bar~/np~+- syntax) it breaks the column layout of the site badly.

Show instance created and reproduced it there.

See http://luci-199-6471.show.tikiwiki.org/tiki-index.php?page=HomePage&pagenum=3

To login use __admin 12345__.

Steps to reproduce:
#go to tiki-admin_modules.php?edit_assign=1&cookietab=2 and assign module to the left column
#go to tiki-admin.php?page=wiki and enable Wiki Pagination under the Features tab (-+wiki_pagination+-)
#edit a wiki page and add some collapsible sections (using the collapsible heading syntax) separated by -+~np~…page...~/np~+-
#go to 2nd or 3rd page (after second collapsible section it seems to start break) and see the left column modules wrap down under the main content of wiki page

{flash type="url" movie="display540" width="633" height="571"}

Using ...page... doesn't work on 11.x, but is working on trunk.

Maybe a missing backports

{CODE(caption="This text behaves OK in 6x, but not in 9,10,11")}! Three ways to search

A. To search for a bug/feature request you can use the search bar in the upper right.

B. Use the Keywords way down on the right column over there -->

C. You can also search the main tracker using the form below.
{CODE}


{img fileId="258"}

Permission from category are not applied for tiki_p_edit (Can edit/create pages) even if group "Default category assigned to uncategorized object edited by a user with this default group" is set.
Unless GLOBAL permission for tiki_p_edit is set (which is wrong as user of this group will be now able to create and edit any page anywhere without being locked in their category:structure).

Real life case:
I have a tiki with several section (shop, store, marketing).
I create a category for each section.
For each section i also create group of user so each each group can edit is own section only.
I set 3 structures so user can also create page in his structure/category/section.

In group preference, i set each group to have "Default category assigned to uncategorized object edited by a user with this default group" with the relevant category (group_shop to category_shop, etc).

As things should work.
If a member of group_shop create a (child) page from a page in structure_shop having tiki_p_edit checked for category_shop, tiki should understand that the new page should inherit from the same category permission (category_shop) and create/edit the page.

But this is not happening. Tiki see the new page to be create has "non-categorised" yet therefor doesn't allow the creation for a usergroup with tiki_p_edit uncheck in global permissions.

Summary: When creating a new page, tiki should check user group category permission and apply them prior the page exist (applying inheritance on a create state page - not saved yet).

There was a missing check to make sure users had the permission to switch permission.

This commit was to address this:
http://sourceforge.net/p/tikiwiki/code/46963

However, now, it's not possible for anonymous uses to switch perspectives, even if they have tiki_p_perspective_view

Using wysiwyg, full screen plugin dialog are hidden under the page (not in full-screen the dialog is on top).

{youtube movie="http://youtu.be/rzg355BRNVk" width="320" height="280" allowFullScreen="y"}

This request is related to another: http://dev.tiki.org/make+a+wish+-+thank+you?itemId=5053

My goal is to provide my users a consistently-formatted view of the tracker, and hide from them any internals of the tracker itself.

I currently list the items on a wiki page using pluginTrackerFilter. A wiki template page is specified for formatting.

The template includes edit and delete links. The edit link is to a wiki page using pluginTracker. The pluginTracker also uses a template page for formatting, and uses the URL field to return the user to original wiki page that lists the items using pluginTrackerFilter.

But I could not find a plugin that would allow deleting an item. The best I could do was to link to \tiki-view_tracker.php?trackerId=X&remove=Y (where X and Y are the tracker and item IDs). This is the URL I found for the delete icon in the tracker view page. Upon confirming the action the user is taken to the standard view tracker page where the remaining items are listed in the standard tabular form.

Per my stated objective, I would prefer my users to be returned to the original wiki page that lists the items using pluginTrackerFilter. So, the feature request is for either
a) a "remove" option on pluginTracker, or
b) a new pluginTrackerRemoveItem, with a URL parameter such as the one pluginTracker already has

Thanks.

This request is related to another: http://dev.tiki.org/make+a+wish+-+thank+you?itemId=5052

I am trying to hide the internals of my trackers from the users as much as possible. In particular, I do not want them to have to understand how item-list fields work.

Say:
Tracker 1 includes an item-list field.
Tracker 1 has items a, b, and c
Tracker 2 includes an item-link field that points to tracker 1
Tracker 2 has items d, e, and f. Items d and e point to item a.

If the user deletes item (a), (d) and (e) are ophaned, so to speak. As the admin, I can go search for these and delete them on occasion, but it would be far better if these linked items were removed at the same time.

So the feature request is for a plugin that searches for orphaned items and deletes them. You might consider the following fields:

===PluginTrackerRemoveOrphans===
{DL()}
trackerId : ID of tracker in which to search for orphaned items
fieldId : Delimited list of fields to search (field is ignored if not an item-link. All item-link fields searched if no ID specified). If the value is for an item that no longer exists, linking item is removed.
Bool : If false (default), any item-link field pointing to an non-existent item will cause the item to be removed. If true, all fields (or all fields in fieldId parameter, if specified) must point to non-existent items before the item is removed.
URL : Page to which the browser will be directed after the action is performed. If not set, will go to tiki-view_tracker.php&trackerId=trackerId
Confirm : If true, Text , action button, and abort button are displayed. Otherwise the action is executed without user interaction. Default is true.
Text : Text to display to the user regarding the action that is about to take place. Default: "You are about to remove table items referencing other items that no longer exist.
action : Text for button that executes the command. Default is "Continue".
abort : Text for button that aborts the command. Default is "Cancel".
{DL}

How I would use this:

I list the items of tracker 1 on a wiki page using pluginTrackerFilter. Let's say it is named "Catalog". A wiki template page is specified for formatting.

The template includes edit and delete links. The delete link is to a wiki page using pluginTracker or pluginRemoveItem (see http://dev.tiki.org/make+a+wish+-+thank+you?itemId=5052) to remove the item in tracker1. The URL field for this plugin points to a third page that uses PluginTrackerRemoveOrphans. The trackerId field is set to the ID for tracker 2, the confirm field is set to false so the action takes place without user action, and the URL field is set to "Catalog" so that the user returns to the original list of item - {PluginTrackerRemoveOrphans(trackerId="2", confirm='false", url="Catalog") \}.

The user has removed the item from the catalog and all items that linked to it, without knowing anything about the internals.

Thanks.

The file description text is always present if the object name (stored name, not actual filename) is selected to be displayed. Selecting to display the object name automatically displays the description.

{syntax type="tiki" editor="plain"}
Please see:

http://doc.tiki.org/Changelog+1.8
http://doc.tiki.org/Changelog+1.9

__Update__: still present in 18.x :( {sign user="luci" datetime="2018-04-03T07:29:30+00:00"}

See: https://tiki.org/TikiFestStrasbourg

===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+-.

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 behavior for browsing categories has changed, and not to my liking. If this was not intentional, then it is a regression (as I've listed it). If this was intended, then please consider this a "wish" to restore the old behavior or (perhaps better yet) provide a plugin that allows me to control the display.

I have two versions available for viewing. They are not show.tiki.org, but they should do for demonstration.

11.2-
http://www.hrsms.org/home/cat74?deep=on&type=wiki+page&sort_mode=name_asc

9.2-
http://www.hrsms.org/home9/cat74?deep=on&type=wiki+page&sort_mode=name_asc

I like that in 9.2 it only shows the current category, and without watch links.

In 11.2, all categories are shown, with watch links (which in my opinion just add clutter to the page), and the category listing is expanded to the last viewed, not the current. To see this:
a) Browse categories on this site
b) Expand "How To-->Hulls"
c) On left menu, select "Models-->By Nationality"
d) Note that the results displayed are for nationality, but the category listing is still expanded to "how to--> hulls". Confusing to the viewer.
e) Change current URL from ..\home\.. to ..\home9\.. to see how "nationalities" looked in the old version. I much, much, much prefer this way.

I tried using PluginCategory for the same purpose, but I could not get the desired results. Indeed, I'm not even certain I get the results that should be expected. Based on my understanding of the parameters, I would expect the categories AND sub-categories to be displayed, and the results split when the category changes. That does not happen. You can see that here:
http://www.hrsms.org/home/Models

{CODE()}{category id="4" types="wiki" sort="name_asc" split="y" sub="y" showdescription="y" showname="y" showtype="n" one="y" showlinks="y" categoryshowlink="y" maxRecords="1000" showTitle="n"}{CODE}

{syntax type="tiki" editor="plain"}
Background info:
http://tiki.org/tiki-view_forum_thread.php?comments_parentId=46281

So when you visit http://doc.tiki.org/Features, the actual list of features comes and goes.

You can see from the video below (I put a watch alert on that page) that it has been going on for months:
{flash type="url" movie="display251" width="1126" height="528"}