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

{syntax type="tiki" editor="plain"}
When using "Theme control" together with a Category, the *.tpl files in templates/styles/{mytheme}/ are not considered for the pages attached to the category.

To see this, create a testcategory and a testpage. Then use "Theme control" and configure a theme having some *.tpl files in templates/styles/{mytheme}/ to be used for the testcategory.

Go to the testpage and it will show in the style. Now try to change one of the *.tpl files. The changes do not take effect.

Note that this is not about emptying the cache.

You can try and use mytheme as main theme and the one you used previously as main theme as "Theme controlled" one. You will now be able to edit the templates/sytles/{mystyle}/ files with the edits being picked up, but now changes to files in the former maintemplate cease to be considered.

{syntax type="tiki" editor="plain"}
Screenshot here: https://matrix.to/#/!SLEgqpTNTlGYAhzNvK:gitter.im/$lGdaEU57JgMoRiZO4C1Z0RK37MPiQSdOTzkRUP0z2yM?via=gitter.im&via=matrix.org&via=sans-nuage.fr

RecordRTC must be enabled to reproduce the issue
Preference name: fgal_use_record_rtc_screen

There is conflicting rule on line 96 of -+themes/base_files/feature_css/recordrtc.css+-:
{CODE()}
@media (max-width: 640px) {
button[id^="btn-"] {
width: 100% !important;
min-height: 48px !important;
font-size: 16px !important;
}
}
{CODE}

If I create a file -+ themes/css/custom.css +- I can customise my Tiki whatever theme is currently being used. That is fine and very useful.

If afterwards I create a file -+ themes/mytheme/css/custom.css +-, the file contents of -+ themes/css/custom.css +- are completely ignored. This is contrary to user's expectations and caused a bug in at least one site I know of.
Both file contents should be taken into account.

{syntax type="tiki" editor="plain"}
Hello,

I have yet redacted quite the same text three month ago, about 4.1, 4.2... Because i could never start these versions, try to find bugs... submit but no answers.

My original text has been lost because of the bugs of the bugs reports management (author not stored - corrected, no capability to sort the items by date, no capability to sort anyway and search) nevertheless, too much to do elsewhere...

__Lest's go to the problem, which is a major one :__

!!The fact :
If any fields which is stored into sessions->data contains an " ' ", it is impossible to restart TIKI (always automatically and by evidence crashes if TIKI tries to restore these session.

!!The reason :
The text is stored with is " ' " and included "simply" into the query which resets the prefs.
By evidence this simple quote " ' " creates a query error and a crash of tiki (often APACHE).
this " ' " is interpreted as the end of the query, and the remaining a non-sense.

!!!Example :
With 5.0 if you are just installing with an upgrade of database, into the session query you will find the third data_text-block
$plugstring = <<<PLUGINTEXT
...
alt:
required: false
name: Alternate text
description: Alternate text that displays image doesn't load.
...

the " ' " of "doesn't" crashes the first run.

!!!The same happens when you have a header page with a title containing a simple quote " ' "

!!Solution :

!!!technical point of view
I have just found a lonely solution :

* the first, simple : any sessions->data content must be pre-translated with doubled simple quotes (which is the SQL syntax).
* any read of sessions->data doubled simple quotes must be set back to a unique one.

This possible solution offers too the capability to find fields with quotes by any query, if the data sent into queries are pre-translated (if not it is a crash).

A back translation after reading is not need only in some cases (the prefs restoration for example), for a search query the results will come back with their simple quotes...

!!!Who acts ?
It is very simple.
There are not many place where the problem occurs;
But I I have lost so much time because of the bug of 4.x and now 5.0RC and 5.0 Stable that I could not make the work I had programmed to do.
In my opinion it should be better that people who have written the SQL requests, make the change.

If they are not ready, I can submit patches (tikisession particularly)

Bye

trebly

{syntax type="tiki" editor="plain"}
Tiki and Pear::Auth (LDAP) authentication doesn't work together in
version 3.0. A tiki local user can't log in anymore if the Pear::Auth
method is set, except admin.

Text in a plugin alias body within ~np~~tc~~/np~tags ~np~~/tc~~/np~ appears in the page

Hi:

I wanted to test the new features coming along in BBB 2.3 & 2.4, so that I installed a new server with BBB 2.4. Everything from the BBB side did run smoothly, but the integration with tiki is not fully working as expected. I mean, after connectinng the tiki to bbb 2.4 server (providing the new url and bbb salt in the tiki control panel), I can see the recordings listed in the plugin bigbluebutton parsed content, but I'm never able to create a new meeting (when clicking to the create button shown by plugin bbb).

I had a look at the [https://docs.bigbluebutton.org/dev/api.html|bbb documentation], and I see that some changes are reported to the API in bbb 2.3 and 2.4.:
{CODE()}
Updated in 2.3:

create - Renamed keepEvents to meetingKeepEvents, removed joinViaHtml5, added endWhenNoModeratorDelayInMinutes
getDefaultConfigXML obsolete, not used in HTML5 client
setConfigXML obsolete, not used in HTML5 client

Updated in 2.4 (under development):

getDefaultConfigXML Removed, not used in HTML5 client
setConfigXML Removed, not used in HTML5 client
create - Added meetingLayout, activityReportTracking
{CODE}

I had a look i Tiki21 LTS, for instance, and I see that there are references to -+getDefaultConfigXML+- and -+setConfigXML+- in __lib/bigbluebuttonlib.php__

{CODE()}
(...)
173: $content = $this->performRequest('getDefaultConfigXML', ['random' => '1'], false);
(...)
192: $client = $tikilib->get_http_client($this->getBaseUrl('/api/setConfigXML.xml') . '?');
(...)
{CODE}

Could this be the reason why tiki is not creating the new room in the bbb-2.4-powered server?

If that hypothesis is confirmed, then we might hit a problem in the tiki community in the afew months whenever Fred Dixon and the BBB team upgrades the bbb instance we use in the "Tiki Roundtable Meetings" and TAG meetings, etc.

I can share the details of my bbb2.4 test server (url and salt) with any dev willing to debug and fix this issue.

If ''tablesorter'' is active (pref -+ feature_jquery_tablesorter +-), the group management page is unusable except for Tikis with a small number of groups.

The reason is, there is no search box and no pagination. Therefore, there is no way of knowing if there are more hidden groups. And no way of accessing the hidden groups.

This can be experienced on [http://dev.tiki.org/tiki-admingroups.php] for instance.

http://sourceforge.net/p/tikiwiki/code/47487/
was reverted by:
http://sourceforge.net/p/tikiwiki/code/48265/

But we would want this in Tiki Check standalone

This comes out with new Chosen lib
{img fileId="256"}

It is also strange in mobile mode.

There should be a note, only visible to tiki_p_admin that the anti-bot code is not currently here because the GD lib is not there.

When a pref has a help text, this text must not contain colons, because Tikis help system separates a help headline from body text with a colon. Unfortunately there are texts containing colons, and where they could not be easily avoided, for instance for the setting of namespace separators.

/templates/admin/include_general.tpl contains this:

{CODE(Colors="Tiki")}
{preference name=namespace_indicator_in_structure}
{preference name=feature_use_three_colon_centertag}
{preference name=wiki_pagename_strip}
{remarksbox type="note" title="{tr}Information{/tr}"}
{tr}To use :: as a separator, you should also use ::: as the wiki center tag syntax{/tr}.<br/>
{tr}Note: a conversion of :: to ::: for existing pages must be done manually{/tr}.<br/>
{tr}If the page name display stripper conflicts with the namespace separator, the namespace is used and the page name display is not stripped.{/tr}
{/remarksbox}
{CODE}

This results in a headline "To use " and body text ": as a separator, you should also use ::: as the wiki center tag syntax" which is destroying the crucial information. The number of colons is vital here! And it likewise affects all translations as well...

Enable multilingual, create a tracker create a text field and set it as mandatory.
You can’t save without filling the field. (good and normal)

Turn the field to multilingual and dont set title for other language.
You can’t save an item anymore.

While they can be a discussion about the logic, having a title in every language used in that case shouldn’t be mandatory and one should be use as default when other don’t exist.

I remember it was once useable, if you had at least one field with a value it was good enough to allow saving.


http://bsfez-11581-7539.show2.tikiwiki.org/tiki-view_tracker.php?trackerId=1
You can’t save an item with only one language title

{syntax type="tiki" editor="plain"}
((doc:Together)) works for tracker items. No reason for it not to work for wiki pages

Let's coordinate ((Together|here))

Since unified searches are done against an index for performance and scalability instead of against the whole content of the database as before, every new or changed content needs to be indexed. When someone imports a bunch of tracker items through the csv import feature, Tiki knows better than to index all at once, and it indexes 10 items and queues the rest for later indexing (10 at a time). There were 592 items in the queue!

When we edit a page and save it afterwards, there is a bug: Tiki forgets to be clever and presumably tries to index the new page content as well as the whole queue on unindexed data. So, it times out with the following message:
Fatal error: Maximum execution time of 90 seconds exceeded in /data/root_www/promusa.alsawiki.com/20140801_www.promusa.org/vendor/bombayworks/zendframework1/library/Zend/Search/Lucene/Search/QueryLexer.php on line 348

Raising Maximum execution time is no solution: it only blows after more time.

The page is actually saved

Going to the admin → Search → Index maintenance → reindex All
empties the queue and aftewards editing wiki pages is possible again.

WYSIWYG toolbar for the text_area field is not working if field is set to multilingual.

Check the instance: http://bsfez-11581-5068.show.tikiwiki.org/tiki-list_trackers.php

I have set 3 trackers.

One with 2 text area and 2 with a single text area (one set multilingual yes, one with multilingual no).
Only the single one with multilingual = no work properly.

Today in the https://tiki.org/Roundtable-Meeting-2020-09 we noticed that a plain registered user is not able to see the forum post "type" dropdown when starting a a new topic (the first message of a new forum thread). Reproduced with user @xavi . However, when listing the topics of a forum, the first column is shown for that same user (as well as anons) indicating the topic type: all say "normal" here:
https://tiki.org/forum4


However, a user with admin rights (for instance @xavidp ) is able to see the dropdown of topic type: Normal | Announce | Hot | Sticky | Deliberation.

Reproduced here:
https://tiki.org/tiki-view_forum.php?openpost=1&forumId=4&comments_threadId=0&comments_threshold=0&comments_offset=0&thread_sort_mode=lastPost_desc&comments_per_page=20

I've checked in the forum edition page, or forums control panel, or forum4 permissions, and I couldn't find anything to explain that behavior. Maybe some bug in some tpl or php code which control which permissions are needed to display that dropdown field?

Tracker field 'Date and Time (Date Picker)' gets current time as default value in mobile mode (12.x) even if set pref to 'None'.

This implies that if users only saves a few fields of the tracker form, and doesn't plan to set value for the date and time (date picker) fields, they will get stored current date value, even if that can be a wrong value (it should be empty).

Reproduced here:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

See field 14, in standard desktop-computer mode, and compare with Mobile mode (siwtch with link in module in left column)

Tracker field with Multiple selection list cannot be displayed in mobile mode, in 12.x

(untested in 14.x)

See it reproduced in:
http://xavi-9794-5642.show.tikiwiki.org/tiki-index.php
u: admin
p: 12345

# Switch to mobile mode (see link at the bottom on central column of page).
# choose "case A", and then,
# try to see the values for the field: "Case A. Multiple Selection List". Only one is shown.

Tracker fields textarea content wiki parsing doesn't work the same as wiki page content parsing when using a page as a Smarty template with the ''wiki'' Smarty block. For example consider we have a textarea field and this wiki syntax in the page named "User Profile TPL":
{CODE()}{wiki}{$f_358}{/wiki}{CODE}

The code above indicates we want the field value to be wiki parsed using the Smarty wiki block.

This is the code to reproduce using PluginTrackerlist (I know it is not PluginList ;-) ... but the wiki parsing should behave everywhere in Tiki the same no matter what you prefer to use):
{CODE()}{trackerlist trackerId=38 list_mode=csv view=user wiki="User Profile TPL"}{CODE}

__The input:__
{CODE()}Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit "amet libero" vitae turpis mattis eleifend.

* meh 50%
* 123
* blah blah

Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.{CODE}

__The expected result:__
{HTML()}<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit "amet libero" vitae turpis mattis eleifend.</p>
<ul>
<li>meh 50%
<li>123
<li>blah blah
</ul>
<p>Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.</p>{HTML}

__The actual result:__
{HTML()}<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit """"amet libero"""" vitae turpis mattis eleifend.<br /><br />* meh 50<br />%* 123<br />* blah blah<br /><br />Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.{HTML}

__Reproduced on the show instance__: http://luci-199-7045.show.tikiwiki.org/
(use show:show as user:password and for admin login use admin:12345 to play with it)

In a tracker you can use field type Header to set informal text (https://doc.tiki.org/Header-Tracker-Field)

In tracker you can also use fields that are looking for information from other tracker and other field like item link, item list, dynamic item list, etc. (https://doc.tiki.org/Tracker-Field-Type)

For example, in dynamic item list I can actually for the parameter "Field ID (Other tracker)" fields from the other tracker that are field type header.

Displaying those field type in a selector doesn’t make sense.

Tracker inline editing & Dynamic items list: Options in 2nd field are not updated when the first field is changed.

To be reproduced in a show.t.o instance.
u: admin
p: 12345

http://xavi-9794-5033.show.tikiwiki.org/tiki-view_tracker.php?trackerId=2

Change Product Name "PostgreSQL" to "Oracle DB". Therefore, Product Version should be changeable to "10.2.0.5", but it's not.
It doesn't even show in this show.t.o instance. In an intranet with other data, it shows, but witht the old values, not the new ones to be offered (10.2.0.5 in this case, for instance).

Tracker items Export after filtering fails (either all items or none exported, depending on how you create your plugin TrackerFilter call). That was known to work in the past (see ), and I recall using this type of feature long ago (years ago, maybe with tiki6???).

It seems as if minor fix was needed to have it export items filtered on the criteria indicated through either PluginTrackerFilter or based on the filtering in the tracker feature interface itself.

http://xavi-9794-5876.show.tikiwiki.org/
u: admin
p: 12345

!!! Fixed
!!!! Case 1: TrackerFilter using param "export=y"
This produces a button at the bottom to go to export, in theory, with the pre-selection of item filtered.

* Come here at the homepage:
+ http://xavi-9794-5876.show.tikiwiki.org/tiki-index.php?page=HomePage
* Filter for the word "topic". It will list just 3 items from the longer list of items in the tracker.
+ http://xavi-9794-5876.show.tikiwiki.org/tiki-index.php?trackerId=1#trackerFilter1-result
* click at the "Export" button at the bottom, which will load this page (should it be another url?), and apparently nothing happens: the same page is reloaded:
+ http://xavi-9794-5876.show.tikiwiki.org/tiki-index.php?controller=tracker&action=export&trackerId=1&displayedFields=4&f_4=topic


!!!! Case 2: TrackerFilter using param " export_action='Export it' "
* Come here at the Tracker_as_Calendar_12 page:
+ http://xavi-9794-5876.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12
* Type the word "topic" in the ext box and click at "Export it" button. The csv produced has no content.

!!!! Case 3
You want to do the same from the tracker feature itself: after listing items, you filter bsaed on some criteria, and you click at ecport, you expect to get that filtering applied to the csv to be exported.
The url might look like:
http://xavi-9794-5876.show.tikiwiki.org/tiki-ajax_services.php?controller=tracker&action=export&trackerId=1&status=o&sort_mode=f__asc&filterfield=4&filtervalue%5B1%5D=&filtervalue%5B2%5D=&filtervalue_other=&filtervalue%5B3%5D=5+%28high%29&filtervalue%5B4%5D=topic&filter=Filter

Couldn't we use these values in the arguments of the url to have a pre-selection of items to be exported?
---

!!! Pending Fixing
Update: Filter based on cases of "Multiple selection" fields do not work: nothing is exported or all is (filtering doesn't seem to be working). {sign user="xavi" datetime="2016-06-07T08:14:59+00:00"}
!!!! Case 11: TrackerFilter using param "export=y"
This produces a button at the bottom to go to export, in theory, with the pre-selection of item filtered.

* Come here at the homepage:
+ http://xavi-9794-5876.show.tikiwiki.org/tiki-index.php?page=HomePage
* Field 7 (multiselect): "Resources needed" produces:
+ {CODE()}__tracker field type not processed yet M__{CODE}

!!!! Case 12: TrackerFilter using param " export_action='Export it' "
* Come here at the Tracker_as_Calendar_12 page:
+ http://xavi-9794-5876.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12
*You can't see the form field to filter based on the multiselect field. You type Laser at the text field to filter, and a 0 byte file is produced.

!!!! Case 13
You want to do the same from the tracker feature itself:
http://xavi-9794-5876.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1
* Filter for the "Resources needed" Laser Pointer. 3 items will be shown (out of the 6 max).
* click at the "Export" button at the bottom. None is exported, just the header line with the variable names, but no record below.

I upgraded a Tiki18 to Tiki21 to find out that textArea multilingual is not filtered in the plugin List.

All languages are displayed in a customSearch instead of displaying the only language that correspond to the actual language. (I suspect it will be the same in a List plugin).

Here the tracker edit view showing different languages for different fields (title, abstract, ...)
{img fileId="1418" thumb="box"}

Here the tracker view with English language selected (content is displayed for english only that’s correct)
{img fileId="1419" thumb="box"}

Here the customSearch view with English language selected but all languages are displayed for the field Abstract (note that title, a text field, is working fine)
{img fileId="1417" thumb="box"}

On a Tiki24 with tracker and multilingual.
I have a tracker with a multilingual field Name and this field is selected as title.

So for my item237 the Name field has 3 values (one for each language I use):
English: Hourly hour
French: Taux horaire
Hebrew: תעריף לשעה

If I edit the item while the Tiki is set to English as pref.language , the title value saved in the unified-index will be "Hourly hour".
But If later I edit the same item while the Tiki is set to French as pref.language , the title value saved in the unified-index will be changed to "Taux horaire"... and so on.

{file type="gallery" fileId="1794" showicon="y"}

The unified-index "Title" should be consistent and shouldn't depend on the language the editor of an item is using.

Reproduced in the instance:
http://bsfez-11581-8140.show2.tiki.org/tiki-index.php