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

Essentially as the title says, I am unable to use the {maketoc} tag to work correctly on a page in a structure using the WYSIWYG editor. If I switch to the wiki markup, it works, but then I lose my WYSIWYG formatting (eg for tables and the like).

I've tried {toc} but it won't show headings in the page.

If I try {maketoc} on a wiki created page, the headings will be created in the WYSIWYG editor.

r45953

SVN (11.0svn): May 15 2013 - REV 45953

In a multitiki install of mine, I tested an upgrade from tiki9 to tiki11, and then, switching tabs in admin panels, stopped working.

Once I disabled the js minification setting, tabs worked again.

Tried in demo.t.o/Tiki11, and it works well with or without js minification. So I was that's where the issue must come from.
---

the issue is still present in : Monday 10 June, 2013 23:33:08 CEST- REV 46275, and seems related to the Catalan interface.
Once the interface is set to Catalan, and page reloaded twice, js features stop working.

Reproduced also here in dev.t.o

When I point an itemlist on a multilingual text field from another tracker, It does not show anything.
Doing the same on a non-multilingual tracker works fine.

See both in a show instance.

To reproduce the issue:

1- Apply profile http://profiles.tikiwiki.org/Jailroot_Demonstration on trunk

2- Pick perspective "B"

3- Search for "contentA1". You find

A1 and B1 (OK)
A1 A2 A3 (Not OK)

tiki-listpages.php exhibits the proper behavior.

I click the camera, but the grey selection box never appears.

I suspected recent upgrade in Java or jCapture, but it was multi-screen issue

jquery validation displays the error message below the wrong field in 14.x if using pretty tracker

See it reproduced here:
http://xavi-9794-5706.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

Set a negative number in the field which expects (and only allows) positive numbers, and the error message is shown below the field underneath (a dropdown box, not a numeric one). In other cases (not shown in this show instance), they can be shown further down, etc.

Example:
{img fileId="1001" thumb="y" rel="box[g]"}

jsCalendar widget unaware of time zones and recording event to one day earlier than selected (timezone difference of 6h)

When you use a KanBan board with multilingual fields all languages are displayed.

The value displayed for the field should be the one relevant to the site language as selected.

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

Instance here : http://bsfez-11581-8358.show2.tiki.org/tiki-index.php?page=All-items-displayed-for-admin

The cards labels and description shows all languages.

To reproduce.

As your Unified Index:
* Use Elasticsearch for a few days
* Switch to MySQL

Your setting will stay say that date of last re-index is the one from Elastic

If the translation feature i18n is active, in Wiki page history the GUI clashes with other features. Look at the screenshot attached. The small "A" that is visible next to the flag icon of i18n is actually the drop down menu containing all languages (starting with Albaninian, hence the "A".

{CODE()}PHP (5.5.3-1ubuntu2) NOTICE (E_DEPRECATED):
File: lib/shoutbox/shoutboxlib.php
Line: 57
Type: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead{CODE}

Please do in 12.x if easy / not risky, otherwise, just trunk

Visible on the footer of
http://tiki.org/tiki-admin.php

{img fileId="656"}

When you have a diagram in a wiki page (made with ((doc:PluginDiagram)) ), if you have permission to edit it, you see a link to "Edit Diagram" at the bottom right corner of the diagram displayed in the wiki page.

When you show that page content through ((doc:PluginSlideshow)), then you expect tiki to hide those links to edit wiki sections, edit plugins inline, etc. (which work well, they are hidden in the slideshow), but the diagram still shows the label and link to "Edit Diagram", and it should be hidden when you are inside the presentation.
---
Issue still confirmed in 24.x
Reproduced here:
http://xavi-9794-6688.show2.tikiwiki.org/tiki-slideshow.php?page=Tiki+Wiki+CMS+Groupware#/7
u: admin
p: 12345

If you allow wiki pages to be edited by anonymous, and you embed a diagram in that wiki page, then anonymous users will be shown the link to "Edit diagram" ni that page.

However, if your site has the feature that forces to enter some antibot captcha for anonymous users, that antibot captcha is not shown to the tiki-editdiagram.php UI. Thefore, the anonymous user doesn't know that when they hit the "save" or "save and exit", those changes made are not saved at all, without getting any warning that they are silently lost.

A quick workaround/partial solution would be to at least hide the link to "Edit diagram" to anons if the feature to request some antibot captcha is enabled.

{syntax type="tiki" editor="plain"}
In a bilingual English/French site built on Tiki 5.x, i18n was used to create direct article-to-article links between translation versions of the same article.

When viewing a paginated article with an associated translation, selecting the "switch language" link properly loads the appropriate language version of the article ONLY from the first page of the article.

If an article is broken into multiple pages, attempting to switch language fails when "switch language" is selected while viewing a subpage of the article.

Looks to me as if the pagination (&page=x) variable has not been accounted for when dealing with translations of articles.

Please contact me at dkennedy@pondstone.ca if more information is needed.

Thank you!

When I put the following LIST plugin showing the contents of a file gallery:
{CODE()}
{LIST()}
{filter field="gallery_id" content="4"}
{LIST}
{CODE}
I get a:
{CODE()}
System error.

The following error message was returned:

Unknown column 'created' in 'order clause'

The query was:
SELECT * FROM `index_57c5a14334249` WHERE 1=1 AND (`searchable` = 'y' AND `gallery_id` = '4') ORDER BY `created` desc

The built query was likely:
SELECT * FROM `index_57c5a14334249` WHERE 1=1 AND (`searchable` = 'y' AND `gallery_id` = '4') ORDER BY `created` desc
{CODE}

This does not happen in the blog post preview or in a wiki page.

On a Tiki25 I have tracker items created yesterday and today.


If I set a plugin List and filter using "day" argument to filter a date range it is working as expected for the "modification_date" but not for the "creation_date".

IE: These are the dates outputted by tiki-pluginlist_experiment.php
modification_date => "2023-02-28 06:01:22"
creation_date => "2023-02-27 14:05:01"

If I use
{filter range="modification_date" from="-2 day" to="-1 day"} ~~#090:it will output the items~~

If I use
{filter range="creation_date" from="-2 day" to="-1 day"} ~~#F00:0 results~~
(I also tried from="-3 day" to be sure it was not a timezone issue) ;-)

Both should work the same.

# having -+ALTERNATE+- block in the PluginList it gets removed when using the ListGUI
# the ALTERNATE block selection is missing in the ListGUI toolbar too afaics
# ...

LTS Regression: images not shown if align=center as param (reproduced in doc.t.o)

See this thread were it's explained:
https://tiki.org/tiki-view_forum_thread.php?forumId=2&comments_parentId=60647&threadId=60648&thread_sort_mode=commentDate_asc#threadId=60648

reproduced, also, here in doc.t.o, fixed by hand with that change:
https://doc.tiki.org/tiki-pagehistory.php?page=Newsletter+Admin&history_offset=1&paginate=on&history_pagesize=50&tra_lang=sq&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=31&confirmAction=

I mass replaced
{CODE()}
{img align="center" src="img/wiki_up/
{CODE}

with
{CODE()}
{img src="img/wiki_up/
{CODE}

in doc.t.o, but other tikis might be affected by that issue too. (I thought images were gone in some migration between servers or something when I first saw that)

We can't get diagrams printed in pdf pages (generated through mpdf) in a tiki23 site behind a firewall. We have setup proxy info in tiki, and then we can use tiki profiles control panel, for instance, but we can't use composer web interface/control panel because the system is not able to connect to composer.tiki.org. It seems as if the system is not ready to use the proxy info provided in the tiki ui.

We have been able to print diagrams in tiki master (tiki23 can't be used yet in show2.t.o) in a show2.t.o instance when using __Use draw.io public services to export images__ (reported [item7802-mpdf-generation-doesn-t-include-diagrams-if-only-local-casperjs-installed-but-not-remove-service-from-draw-io|here])
However, we haven't been able to achieve the same goal in a test tiki23 site behind a firewall. So probably the proxy info needs to be added (if present) in the commands that mpdf uses or somehow?

mpdf seems to faill to include images in the generated pdf file when you use:
* some self-signed https certificate, or
* a valid one but issued from a certification agency (like from a local public administration, in our case at work) which is not recognized by your browser by default unless you import a specific authority file in the right place (and I don't know how to do that for mpdf).

I wish there was some way to tell mpdf to avoid checking https certificate validity, like the option you can have in many other programs (wget, curl, git, ...). If that is possible, then a new option should be added in Tiki UI to let the tiki site admin enable it in those known use cases in which you need that feature.

As an example, that would have allowed to use mpdf successfully in the last couple of years at work. And we still can't use it normally due to this issue.

Before Composer (until Tiki10), if you try to run Tiki with a too old version of PHP, you get a clear warning. Now, with Composer, it's not so clear (you get the version warning of Composer instead of Tiki)

Note that the command line version of PHP may be different than the web version.
Command-Line PHP version: PHP 5.3 is needed Composer.
Web version of PHP: Tiki12 needs 5.3, Tiki13 will need 5.5

So perhaps for Tiki 13, it will be OK to have PHP 5.3 requirement on CLI, but 5.5 in web?

So for now, let's add a PHP CLI version check on sh setup.sh before running Composer.

Please see:
http://tiki.org/tiki-view_forum_thread.php?comments_parentId=48901

{syntax type="tiki" editor="plain"}
Full thread is here:
http://tiki.org/forumthread47305

"So should we have a new pref "unified_index" and add it as dependency for these features (PluginList, PluginListExecute, etc.), and thus people whose servers don't work with it have the option to turn them off? (effectively acting like a Tiki6)"

When including a maketoc into a page, the titles in the page are still parsed for WikiWords and Hotwords. This breaks HTML, links, and may decrease the readability of page TOC-s.

Upgraded Tik 9.3 to Tiki 12.2 in our test environment. We have a few wiki pages where we use PluginInclude to incorporate portions of other pages into another wiki page (mainly because the combined page ends up being too long for the database to store). The included text contains section headings that are nested to the proper levels. However, the maketoc plugin on the main page produces a mangled table of contents (all the included section headings are listed before the ones on the main page). Under 9.3, this worked as expected -- the included headings are listed in the proper place inline with those from the containing page. Note this behavior appears to be present in the version running doc.tiki.org as can be seen at http://doc.tiki.org/PluginMaketoc?structure=HomePage+Plugins. Notice that the Example section shows what the maketoc output for the current page would look like and the "Related Pages" heading is out of place.

! Example
Assuming that "HomePage" contains titles, a page with the following source would suffice to demonstrate the bug:
{CODE(colors="tiki" theme="default")}
{maketoc}

! Main section 1
Dummy content

! Main section 2
{include page="HomePage"}{CODE}

The bug can be observed on [http://user-11727-5496.show.tikiwiki.org/tiki-index.php?page=Issue5496|this test page].

This is a regression from Tiki 12.1, due to [https://sourceforge.net/p/tikiwiki/code/48937/|revision 48937].

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.