Category: Conflict of two features (each works well independently)

# enable Slideshows feature on Wiki Admin panel
# log out
# click on the Slides button under HomePage content; tiki-slideshow.php?page=HomePage&slide=1 displays fragments of plugins as ~np~{DIV}~/np~, ~np~{ELSE}~/np~ and ~np~{GROUP}~/np~ (in other words it doesn't parse the plugins properly)

It is not possible to place a hyperlink to this -valid- URL:
{CODE(Colors="Tiki")}
https://www.stadt-zuerich.ch/kultur/de/index/institutionen/nonam_indianer_inuit_kulturen/fuehrungen---freizeitangebote/let-s-talk---mari-boine--die-stimme-des-nordens.html
{CODE}

If you place this in square brackets or use the insert external link GUI function, Tiki will show the URL instead of a given alternative text, and interpret the double dashes as strikethrough.

Tiki should NEVER interpret Wiki syntax in URLs...

It changes the syntax.

It would be time to rewrite the ((Wiki Parser))

On Tiki24 I found out we have 2 wikiplugins Signature.
We should have a different name for different things the sooner the better.

A tracker has been categorized (using admin category add cat to the tracker). (16 = 2019)
The same tracker has a category field for the same category selection. (16 =2019 or 17 = 2020, radio button or dropdown)

On the item level, in the field category the tracker category is forced ''displayed'' even if it is not select in the field. While it make sense on the code/configuration level, it is pretty weird visually for the admin or the user.

In the screenshot below, all the items are categorized (17) 2020
But they show on the list both category (the one from the tracker (16) 2019, the one from the item field category (17) 2020.
{img fileId="1446" thumb="box"}

Login, Captcha; If set together, Use reCAPTCHA (Google) and CAPTCHA questions are conflicting and don't allow registration.

On a Tiki 24 and the master instance.
* Enable registration
* Enable Anonymous editors must enter anti-bot code (CAPTCHA)
* Use reCAPTCHA (Google recaptcha 3 and set your account information)
* Enable CAPTCHA questions and add some

On the registration page no questions is presented.
An error is displayed "You have mistyped the anti-bot verification code. Please try again."

Instance shows the issue (you will need to fill FIRST your recaptcha information).

On a tracker item with category field (multiselect) the admin can assign during the item creation different category to an item.

User with "Can admin categories (tiki_p_admin_categories)" and field editable perm can’t even see the categories.

I created an instance that show the issue.

!!!Update (27/07/2020)
It turns out that when you modify "this" tracker permission, the global permissions on "Can change the categories of an object (tiki_p_modify_object_categories)" won’t be applied and will be then "saved" disabled even if you didn’t change anything for it.

This is a bug. If you don’t change a perm for an object (in this case a tracker but it may be valid for any object) the global should keep being applied.

{syntax type="tiki" editor="plain"}
On a Tiki25, I create a tracker with a username selector to be the owner of the items.

In the tracker properties, I set "User can see his own items".
^
User can see his own items
The tracker needs a user field with the item-owner activated. No extra permission is needed at the tracker permissions level to allow a user to see just his own items through Plugin TrackerList with the param view=user
^

And so, user can see his items and I can unassigned any tracker global permission.

I also set Restrict non admins to wiki page access only
^
Restrict non admins to wiki page access only
Only users with admin tracker permission (tiki_p_admin_trackers) can use the built-in tracker interfaces (tiki-view_tracker.php and tiki-view_tracker_item.php). This is useful if you want the users of these trackers to only access them via wiki pages, where you can use the various tracker plugins to embed forms and reports.
^

So I understand that only Admins can use the tracker interface.

And it is working fine.

However, if I need user to update their existing items using a modal in a plugin List (tracker-update) or inline-editing format the user see a permission denied.

I have to assign to the group the permission can change item (tiki_p_modify_tracker_items) and this allows users to edit his items on a plugin list.

But now;
* Restrict non admins to wiki page access only as no more effect. (user sees the tracker interface (/trackers | list, the tracker content | /tiki-view_tracker.php?trackerId=xx and /itemxx | the tracker item)
* They can edit any items (other users)

Which is pretty bad because it just cancelled:
# User can see his own items
# Restrict non admins to wiki page access only

There may be more with the tracker field additional permissions and other workaround, but this is just digging deeper and deeper.

In my point of view, it should be possible for an admin to set that user cannot see the tracker interface and can see/edit only their own items quickly (in the tracker properties) without risking display to one user items of another.

Using a Tiki at tiki-admin.php?page=login you can set a tracker to collect users information.
In the group (registered) tiki-admingroups.php you can define what field to display in the registration form.

This work fine.

You can also use a tracker plugin in a wiki page to fill a tracker item and include a registration.
However the input field displayed are limited to :
* Username *
* Email *
* Passcode to register * (if set)
* New Password *
* Confirm password *

And NOT the list of field you set in your Group (as above).
The tracker plugin Registration option shouldn't modify the fields require for the registration and the way the admin has set it.

I created an instance to demonstrate.

While __you are not logged__ if you go to register :http://bsfez-11581-7961.show2.tikiwiki.org/tiki-register.php

The page show ALL the fields I added for registration at :http://bsfez-11581-7961.show2.tikiwiki.org/tiki-admingroups.php?group=Registered

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

Good.

Compare to the registrations fields proposed in the tracker plugin and you see all are missing.
http://bsfez-11581-7961.show2.tikiwiki.org/tiki-index.php?page=HomePage

{syntax type="tiki" editor="plain"}
~~#F00:Update still on Tiki26.x~~

On Tiki23 if I can have global Admin setting for the Wiki Page to Show page title (enable by default).
So the page "myitems-" will show the title (a link) on the top of the page.

On the properties of the page "myitems-" I can individually turn it off for this page.
So the page "myitems-" doesn't show the title (a link) on the top of the page.

The page can be used as a template to displays items from a tracker using the an alias.
The URL then will become "myitems-4" and now the page title is displayed which is wrong.

Any idea why this page: https://info.tiki.org/Add-Consultant
has a wrong browser title: "File Upload | Tiki Wiki CMS Groupware :: Community"
???
It should be: "Add Consultant | Tiki Wiki CMS Groupware :: Community"

See live example here:
http://moviments.net/cursos/IMDIG-I-Apunts

Wysiwyg editor is enabled, and those are the general wysiwyg settings on the site:
|| Wysiwyg Editor is optional: | X
... and is displayed by default: |
Reopen with the same editor: | X
Content is parsed like wiki page: | X
Content is partially parsed: | X ||

The wiki page http://moviments.net/cursos/IMDIG-I-Apunts was last edited using normal editor, keeping "allow html" checkbox as enabled on that page. When you write
{CODE()}
{maketoc}
{CODE}

The string ~np~{maketoc}~/np~ is displayed, but the table of contents fort that page.

This bug happens when you have WYSIWYG editing enabled, and a wiki page template that looks like this:

{CODE()}
[tiki-index.php?page=HomePage#SomeSection]
{CODE}

i.e., it contains a link to a page section.

If you setup a quickedit module to create a page with that template, then when you save the page, the #SomeSection part of the link gets deleted. So the link points to HomePage instead of HomePage#SomeSection.

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section.

Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button.

Adding many users at once to a group fails in 12.x, and it used to work nicely in 9.x LTS at least.

I had Jquery Chosen enabled, and when I disabled it, I was able to add them to a group through tiki-adminusers.php as usual.


To reproduce, go to:
http://xavi-9794-5163.show.tikiwiki.org/tiki-adminusers.php

u: admin
p: 12345

select both users (user1 & user2), click at "Manage group assignments", and choose to assign them to group "Admins". Validate the confirmation step. Nothing happens (they are not added to the Admins group).

Repeat without JQuery Chosen, and it will work as expected.
---
Update {sign user="xavi" datetime="2014-04-07T07:44:15+00:00"}
Actions on multiple users with chosen and sortable tables work, but the second dropdown is not shown properly:
{img fileId="742" thumb="y" rel="box[g]"}
---
Update {sign user="xavi" datetime="2015-04-02T08:04:24+00:00"}
You can't even select any groups at the step to choose group in the multi selection combo box.
{img fileId="992" thumb="y" rel="box[g]"}
---
Update {sign user="lindon" datetime="2015-04-07T03:41:55+00:00"}
I am not able to recreate this [[the former issue report related to jquery sortable tables] using my local 12x - I am able to add or remove multiple users to multiple groups. Did it with 25 users with no issue. The list of groups came up properly and I was able to multi-select.
---
Update {sign user="xavi" datetime="2015-12-16T07:59:32+00:00"}: removed references to Tablesorter as I could confirm that at least with current code (thanks lindon for checking!) the issue seems to be attibuted to Chosen only.

Going to Admin Categories > Bug on dev.tiki.org returns alerts on top of the page:
{CODE()}
ErrorErrorError
Tracker list_items ran out of memory after 0 items.Malformed search query: Parsing search query failed: "org.elasticsearch.common.ParsingException: [_na] query malformed, must start with start_object"Notice: invalid variable value: $_GET["maxRecords"] = undefined
{CODE}

At tiki-admin.php?page=login , Username, when I enable "Use email as username" some username settings are now hidden (meaning not in use) but they are still applied.

Minimum length
Maximum length
(And may be "Force lowercase")

I created an instance to test and reproduce.
You need to "really" register a user, not using the admin user to create new users.

How to reproduce :
# Go to Admin, Control Panels and switch to "Advanced" (to see advanced preferences)
# Go to log-in : tiki-admin.php?page=login, Registration & Log in
# Enable : Users can register
# Disable : Validate new user registrations by email (we don't want to validate email)
# Go to : Username and set "Maximum length" to 6
# Apply (save)
# Use a different browser (check you are not logged), go to the Tiki and register a new user
# Try to input more than 6 characters for the username, you will see this error:
+ {img fileId="1689" thumb="box"}
# Go back to your previous browser (logged as admin), log-in : tiki-admin.php?page=login, Username
# Enable "Use email as username" option
+ The parameters Minimum length, Maximum length, (And may be "Force lowercase") will be hidden has not relevant anymore.
# Go back to your different browser (check you are not logged)
# Create a new user with an email for login (obviously longer than 6 characters).
+ You won't see an error on focus
# Submit your registration and you will see the error:
+ {img fileId="1690" thumb="box"}

The difference of treatment in the process make me think there is some wrong additional condition that should be cancelled if "Use email as username" is enable.

Have been trying to fix for several weeks, still can't manage it, but it's quite important i think (more or less has lost a Tiki client for me) {sign user="jonnybradley" datetime="2014-01-07T13:43:51+00:00"}

I get an annoying "Error" AJAX: error 0 (rejected) for URL: tiki-search-lookup?... on top of pages when requesting some query/navigating away from the page before it finished loading.

Is this necessary to show when I do not care if something did not finished loading yet and I simply want to take another action than waiting till the page finishes loading ajax in the background?

On a Tiki20 I can edit the default Wiki page, select text and create an external hyperlink using the toolbar button.

If I do that with "Ajax auto-save" enable (by default) all goes well.
If "Ajax auto-save" is disable I got the following alert;
{img fileId="1308" thumb="box"}

{syntax type="tiki" editor="plain"}
On ui.tikiwiki.org, I noticed some issues about the annotation plugin stuff not appearing properly when a page is cached.

I turned off cache for now

When antibot is in effect on tracker creation it will mess up the rendering of the "create" button (esp. depending on browser dimensions).

The following change (below) to ''insert_item.tpl'' makes me happy enough but I'm sure a more experienced dev may have a better idea about how to fix. Still, for consideration....

-+@@ -28,6 +28,7 @@
{/if}
{if !$user and $prefs.feature_antibot eq 'y'}
{include file='antibot.tpl'}
+ <div class="form-group clearfix"></div>
{/if}
<div class="submit">
<input type="hidden" name="trackerId" value="{$trackerId|escape}">
+-

Tiki Articles do not support the FOOTNOTEAREA plugin. In Tiki 5 and 6 I used:
{CODE()}
foo bar {FOOTNOTE()}http://www.foo.bar{FOOTNOTE}
---
{FOOTNOTEAREA() /}
{CODE}

Tiki renders the footnote (superscript) properly, but does not include a Footnote area at the bottom of the article.

Tested & confirmed on info.tw.o using Tiki 5 and 6

If you have an article listing on your front page, and you create a "breakout" page with older articles, you want to skip those that have already been presented on the front page. In order to achieve this, you can instruct the plugin to skip a number of articles (or a period). But this does not work together with pagination...

{CODE(Colors="Tiki")}
{articles max="6" topicId="2" largefirstimage="y" actions="n" title="News" quiet periodQuantity=3 start=5 periodUnit="week" more=y}
{CODE}

would be the code to display articles older than 5 weeks. And this works. But displays only 6 articles (as instructed). Once you add

{CODE(Colors="Tiki")}
usePagination="y"
{CODE}

The articles plugin no longer skips older news, but starts with the very same, newest article like to front page does... It does paginate, but it starts at the wrong article...