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

On a Tiki 18x REV 67053

On Admin Wiki, Display page name as page title is on by default.
On regular wiki page I can turn it off or back to default without problem.

When I use the wiki page as template (plugin list) to display an item using the semantic alias the title is always displayed even if I turn it off.

I set an instance to demonstrate but "Show" is not working with SEFurl.

The Paypal plugin seems to be incompatible to classic Tiki layout, as it paints the cart display partially __over__ the Tiki window and partially (lower left corner) __under__ the (middle section) Tiki window, see screenshot.

Two minor issues with this plugin: It ignores the global setting that decimal commas are to be used, and that the euro currency symbol is trailing (with a separating space).

Thanks
Hman

http://suite.tiki.org/Tiki+Suite is a perspective of http://tiki.org/

In mobile mode of http://suite.tiki.org/, we get "Too many redirects" or "This webpage has a redirect loop". You can also get this by going into mobile mode from suite.tiki.org

{flash type="url" movie="display665" width="1071" height="549"}

Thanks to Simon Boulet for reporting

If the configuration option Wiki argument variable is enabled (default is disabled), then the plugin CODE is parsing variables such as ~np~{{~/np~page~np~}}~/np~.

If Wiki argument variable is disabled, then ~np~{{~/np~page~np~}} ~/np~ appears as expected.

I'd happliy create a show instance but your system is showing


Show.tiki.org is not configured properly

The public/private keys configured to connect to show.tiki.org were not accepted. Please make sure you are using RSA keys. Thanks.

Once a tracker field is set as title, it turns to be a link to the tracker item.

In certain (but several) condition when using a plugin List, ListExecute or the plugin Map this field(link) will be inserted into another link and then the display will be broken and it will show code instead of item link. (a link within a link is bad)
Check the instance.

First problem: There is nothing that can tells you from where come the issue and only after several experience and Jonny’s help we found out what it was. Anyone else (and new comers) won't have any idea why the display is broken.

Second problem: __It is a pain !__

Workaround are messy; you have to duplicate fields (Name and Title), title has to be set to a different field (like Id) and start confusion or worst, previous setting that were ok turn to be broken.

Would it be possible to have some kind of strip there ?
(if the value is already a link, strip <a ...). There is a smarty function for that "Strip" couldn't it be easily set ?

Plugin List GUI minor improvements

--(1) expose the GUI through the modal popup also when through help icon--
So far, when you use the popup helper for the list plugin (through the help icon in the toolbar of a textarea) you cannot use the GUI (com jq missing or not working properly?), but only when you call the list plugin with no params and save the wiki page or tiki object with the textarea, in which you see some sort of jq in action showing the GUI controls and a way to switch back to "source" mode for the body.
{CODE()}
{list}
{CODE}

(2) Not easy to indicate "show me everything from tracker 1"
I couldn't find a way to indicate the trackerId as a first step to get a preliminary report. I was offered to select any from all the tracker fields, but how to indicate all the items from one tracker?

Ideally, the use would like to indicate first the type of tiki oject (wiki pages, one or many trackers, etc), and after that, narrow down which fields or which conditions need to be met, etc.
I couldn't find an easy way to do such task in my first experience with the list GUI. It seems as if tracker_id is missing from the dropdown of values for the filter field, since syntax seems that it should be.

{CODE()}
{filter field="tracker_id" content="1"}
{CODE}

(3) When you search for GUI in the control panel search box for admins, you no results, even if the pref seems to be called "GUI for the list plugin", and pref. filters are set to Advanced, and include Experimental, and the index has been rebuilt just in case.


To reproduce:
http://xavi-9794-6390.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

HTH

{syntax type="tiki" editor="plain"}
The mouseover plugin works well on its own, similarly, the tabs plugin works well too. But when a TAB includes a MOUSEOVER, the offset of the mouseover box shifts to the end of the page.

I tried to correct this by setting the offsety to a negative value, but apparently, a negative value is not accepted by the mouseover offset command. In fact, even if it did, it wouldn't matter, because the offset shifts as the page gets longer.


For example, this syntax:
{TABS(tabs=Tab1|Tab2)}
*{MOUSEOVER(label="Some label 1")} asdasdasdasd {MOUSEOVER} blah blah blah.....
/////
*{MOUSEOVER(label="Some label 2")} qwertqewrtqwe {MOUSEOVER} blah blah blah.....
{TABS}

results in the mouseover box appear down under the page end.

Plugin Slider interferes with expected behavior of ui for anon in homepages.

To see it reproduced, visit this site (with a plugin slider),
http://seeda4c.org

And try to switch language que the correspinding module.

Something similar can be reproduced applying one of the featured profiles. (Company Intranet, afair)

Currently, marking "Restrict non admins to wiki page access only " on a tracker breaks the TrackerCalendar plugin. Clicking a calendar item with the before mentioned option set in the tracker brings forward a screen saying that the user must be an admin. This is the conflict bug portion of this request.

The feature I am requesting will remedy the above mentioned bug. I am requesting a feature of making "read only" views of the calendar entry available for use after the calendar date item is clicked. This can be achieved through the addition of a "url" field in the TrackerCalendar plugin parameters that permits jumping to any link when the calendar date item is clicked. This feature would allow for linking to another wiki page that has a "TrackerList" plugin on it to show the related data, possibly through a pretty tracker.

I am attaching updated wikiplugin_trackercalendar.php and trackercalendar.tpl files that work to implement the feature/fix solution. I'm not checking them in because my javascript skills aren't what I would like them to be and I'm sure this provided solution can be improved upon with better use of the javascript fullCalendar event.url element. Feel free to reach out if I can provide any assitance or insights.

I gave "easy to solve" a score of siz as an average. It is a "1" for me or I would have done it, it might be "9" for someone who clearly understands javascript.

Plugin TrackerToggle doesn't display the hidden field if attempting to change value in a previously saved itemId

I followed the documentation found here:
https://doc.tiki.org/PluginTrackerToggle
with this type of syntax in a pretty tracker page:
{CODE()}{TRACKER(trackerId="1" fields="2:5:10:11" showtitle="n" showdesc="n" showfieldsdesc="y" showmandatory="y" showstatus="y" wiki="Template1")}{TRACKER}

{trackertoggle fieldId="5" value=1 visible="y" id="condiv"}
{CODE}

And the wiki page Template1 contains:
{CODE()}
Field 2: {$f_2}
Field 5: {$f_5}
{DIV(id=condiv)}Field 10: {$f_10}{DIV}
Field11: {$f_11}
{CODE}

and the field is hidden by default, however it doesn't get displayed when the radio button gets the value "1" (yes) when visiting a previously saved item; e.g., with the url like:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3

(please note that this itemId3 has field5 stored with value 0 (case A). That's why even if you click (at item edition time) to the second value of the radio button (value 1 - case B), nothing is shown (because field5 has value 0 stored or in the session or something).

---

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

You can see here: ((WantedPages))

Some wanted pages have links to the alias.

((doc:PluginDiagram)) in ((doc:Tiki20)) seems a very promising feature.
In my first test, I didnt' manage to make it work when choosing to save the diagram in a file gallery, I don't know why. It just doesn't display the diagram within the wiki page where the diagram was called.

If I choose to save the diagram within the wiki page, then everything works as expected.
If I manyally get the xml code from the diagram created in the file gallery, and place it inline within a new call of plugin diagram in the wiki page, the diagram displays as expected.
If I click at edit the diagram from the wiki page (even If I don't see the diagram displayed in the wiki page, I see the button to continue editing it), I can see it and edit it in the diagram ui editor, as expected.

Only issue is (apparently) to display in the wiki page the diagram stored in a file gallery.

HTH

((doc:PluginDiagram)) works when saving in wiki page but fails when saving to file gallery

PluginFiles: form to upload files below that table reports error due to defective indexing (file seems to be uploaded indeed, despite the error message).

I'm using that code in a wiki page:
{CODE()}
{files galleryId="8" showthumb="y" showaction="y" showupload="n" sort="lastModif_desc" showname="n" showfilename="y"}
{CODE}

The error shown is:
{QUOTE()}
Error
Indexació no en processar "AjBCN - Estació Lliure KUbuntu" (tipuswiki page) amb l'error "Could not perform index modification: Data too long for column 'contents' at row 1"
×
Error
Índex de cerca no es va poder actualitzar. El lloc està mal configurat. Poseu-vos en contacte amb l'administrador.
Could not perform index modification: Data too long for column 'contents' at row 1
{QUOTE}

Please, note that the wiki page "AjBCN - Estació Lliure KUbuntu" had nothing to do with the Wiki page where the Plugin Files call was present ("CityOS"), so it seems as if that form attempts to index a wrong object, and also, failing due to "Data too long for columns contents"?.

Addenda:
For your information, uploading the same file through the file gallery upload form no error is shown at all:
{CODE()}
{button href="tiki-upload_file.php?galleryId=8" _text="Puja-hi arxius" _icon_name="arrow-up" _type="primary" }
{CODE}

If PluginListPages is used when feature list pages (feature_listPages) is turned off, nothing happens. There should be an error message.

See:
http://marclaporte-11197-4964.show.tikiwiki.org/tiki-index.php

{flash type="url" movie="display292" width="589" height="633"}

Wasn't that fixed already in 15.x+?

To reproduce:
http://dev.tiki.org/Search+Wishes

# Search wishes for user "marclaporte"
# Click to sort by date

List is gone

That used to work in earlier LTS versions of Tiki (6.x, 9.x). It's currently also broken in 9.x LTS current code.

You indicate to preselct a value in a dropdown list in a tracker (foo,foo,bar). The field gets pre-selected in the tracker form itself when used direcetly through the tracker feature. But when used through the PluginTracker, no pre-selection is made.

See the show instance to get it reproduced
Go to the "Voting" page, and compare to the "tracker1" interface.

u: admin
p: 12345

You can also reproduce in your own Tiki by means of applying the Profile "Vote".
http://profiles.tiki.org/Vote

Preferences report reports "" when you run it on a multitiki based installation
{CODE()}
root@server:/var/www/tiki18farm# php doc/devtools/prefreport.php > prefreport.csv
root@server:/var/www/tiki18farm# cat prefreport.csv
Cannot initiate database. Tiki is not installed.
{CODE}

Or autodetect that it's on a multitiki install and prompt the user which tiki you want to have your report on (like with TRIM).
or just report them all, with suffixes corresponding to the multitiki names in the installation.

I tagged it also against "Community projects" after the discussions we had in the TAG meeting from today: https://tiki.org/20180808-TAG-Meeting.

Javascript tooltips (bootstrap pop-ups) can be disabled in a Preference but then various JavaScript pop-ups with edit options will also be hidden. This will disable all edit options in lists (examples: module editing, page editing, etc, etc).
This option, if kept, should ONLY affect front end where tooltips only provide visual feedback. Otherwise, this should not be an option at all.

Profiles wiki handler: translations param doesn't work. To reproduce, see and apply profile: http://profiles.tiki.org/Consensus+Forums

This page:
http://xavi-9794-5371.show.tikiwiki.org/tiki-index.php?page=Instructions+for+the+Consensus+Forums

should be in the same trnaslation set as the equivalent Spanish one:
http://xavi-9794-5371.show.tikiwiki.org/tiki-index.php?page=Instrucciones+de+los+Foros+de+Consenso

This is how the pages are defined in the profile decalaration:
{CODE()}
objects:
-
type: wiki_page
ref: consensus_forums_include
data:
name: Instructions for the Consensus Forums
description: Instructions on how to use forums to help users seek consensus on discussion threads
lang: en
mode: create_or_update
translations: consensus_forums_es_include
content: wikicontent:Consensus_Forums_Instructions
-
type: wiki_page
ref: consensus_forums_es_include
data:
name: Instrucciones de los Foros de Consenso
description: Instrucciones sobre como users los foros para ayudar a los usuarios a buscar consensos en cada hilos de debate
lang: es
mode: create_or_update
translations: consensus_forums_include
content: wikicontent:Consensus_Forums_Instrucciones
{CODE}

However, the "translations" keyword doesn't seem to take effect.

provide a clicable link to login to dev.t.o from a smartphone out of the menu icon at the top right corner

Have you tried recently (in the last several weeks?) {sign user="xavi" datetime="2016-04-06T15:43:28+00:00"}
Same issue when testing https://nextdev.tiki.org

You can't click there at any login link, it's hidden below the square icon of the collapsed menu at the topbar.

And ensure that this fix is applied to the main *.t.o sites , at least. (tiki.org, dev, doc, I would say)

The Tiki preference "Session storage location" must not be set to "database"

{QUOTE(replyto="kroky6" date="2023-03-10")}Debugged for some hours and came up with this:
- no problem in cypht code itself - reply details are sent to the session to be written and requested from session on the compose page but there are not there when requested
- session Tiki-Cypht integration - no problem as well, session is written when request finishes
- data that is written to the mysql sessions table (this Tiki stores sessions in db) is correct (contains the reply details)
- however, the data is not in mysql database after write

Tried to debug more with manual query, tried to simplify with select and then update or insert instead of replace type of query but again the same result.

I think this is what happens - every time this bug happens, there are multiple AJAX requests executed in the background. I think they overlap in time which results in the following race condition:
1. get message content cypht ajax request begins and is processing.
2. another ajax request begins and opens the session (reads the current session and there are no reply details there).
3. get message content cypht ajax request writes the session when completing and writes the reply details
4. the other ajax request finishes after that and writes the session but it doesn't have the reply details (effectively overwriting another process's session).

I think we switched for non-locking mode of db sessions to speed up this Tiki but when we face overlapping ajax requests this has adverse side effects. Do you remember why did we switch to non-locking mode? I think we should either update cypht-Tiki integration to send one ajax request at a time or switch to session lock mode the whole site.{QUOTE}

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.