Category: 25.x

At https://doc.tiki.org/PluginCode the different samples with colors parameters are not doing anything.

Using tiki 25.3, I can add the duration field to the tracker and set second,hour,day,week,month,, yes/no etc.
I have all the recommended settings: CDN set to Non. VUE.js enabled. One preference hover comment says to enable vue.js integration, I do not have that preference.
So no widget appears in the form next to the field label.

See attachments for more

https://github.com/Drive4ik/simple-tab-groups/issues/794

We should consider this for Tiki.

Step #1: Make a list of all features and contexts that have this search as you type feature.

As of 21.x and 22.x the elFinder gallery url's have changed. This has created issues with existing menu items that were pointing to a file gallery. The url's used before would have a trailing /file1 for a gallery.
Now using elFinder their is an extra trailing url attached that looks like this:

/file1#elf_f1_MQ

A show instance will be created, at the show instance you can turn elFinder on and off, and view the gallery url's change.

any time I login to my own corporate tiki or the tiki.org website for the first time, I get the "Request could not be completed due to problems encountered in the security check. The security ticket included in the request does not match the ticket on the server. Reloading the page may help."
Reloading does help but seeing this error on your first use of this website is not great. Is there a way to stop this from happening ?
{img fileId="2052" thumb="box"}

The syntax:

-+ ~np~{filter field="tracker_field_permName" content="NOT "}~/np~+-

No longer works in plugin list in 23.x (and possibly 22.x) with elasticsearch.

It still works fine with the mysql engine, but it definitely fails (and finds everything, empty or not) in es7, 6 and 5.

More... finally confirmed the last version it worked in was 18.x, 21.x is broken too (also that i could only get 18.x to work properly with es5, 6 and 7 refused to index successfully) {sign user="jonnybradley" datetime="2021-08-09T17:41:43+00:00"}

Trackers are the de facto way Tiki treats data collected from users. These are personal data that directly fall under ''__many__'' legislative and other regulations. Primarily the EU GDPR, but -here- more importantly under the PCI, if they contain credit card or other payment data like bank account numbers.

Under PCI DSS credit card data must not be kept in the same database as personal data. They must be separated on all levels of processing, from technical to organizational. They cannot be processed under group logins, logins to systems carrying card data must use personalized login accounts etc. et. al.

There is one problem with trackers here: To my knowledge all trackers are kept in one DB, which is the DB the Tiki runs from. In order to comply with PCI DSS it will be necessary to have trackers with card data in a separate DB...

https://www.pcisecuritystandards.org/

Thanks
hman

When I try to access d.t.o. to make comments or file bugs, I get very many "Err_Tunnel_Connection_Failed" error messages instead of the the content requested. Looks like there is a hiccup in hosting d.t.o. ...

Having this code on a page:

{CODE(theme="default")}{EVENTS(calendarid="2" datetime="1" max="10" usePagination="y")}{EVENTS}{CODE}

Will work fine when logged in, but will generate a db_error when not logged in.

Also, tiki-calendar.php is generating a php error on line 284, as TikiLib::date_format('m', $dday) returns 'm'. I changed this line of code to instead use %m, and that seemed to fix the problem.

BigBlueButton 2.4 comes with a new feature called __Learning Analytics Dashboard__ (LAD from now on)
https://docs.bigbluebutton.org/2.4/new.html#learning-analytics-dashboard

{img src="https://docs.bigbluebutton.org/images/24-learning-dashboard-2.png"}

By default, the data behind this dashboard is deleted 2 minutes after the meeting finishes, but there is preference in bbb that can be changed to avoid deleting this meeting data.
https://higheredlab.com/how-to-check-bigbluebutton-learning-dashboard-after-the-session/

{CODE()}
By default data for the Learning Dashboard are kept for 2 minutes after a session ends and then are removed permanently.

In order to make the Learning dashboard persistent, you need to change the variable learningDashboardCleanupDelayInMinutes in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties.


To keep the learning dashboard data permanently, change the value to 0: LearningDashboardCleanupDelayInMinutes=0.

Once you make this please restart the bbb by running bbb-conf –restart.

In order to access the dashboard data you need to supply

1. The internal meeting id of the meeting, which is same as the directory name under /var/bigbluebutton/learning-dashboard/ on your server
2. The access token for the learning dashload, which is same as the subdirectory name under /var/bigbluebutton/learning-dashboard/<internal meeting Id>/

Then the learning dashboard can be accessed through https://your.bbb.com/learning-dashboard/?meeting=<internal meeting Id>&report=<access token>

If you wish to see the learning dashboard in your preferred language then you can an addition parameter to above url &lang=<language code>Then complete url would look like this : https://your.bbb.com/learning-dashboard/?meeting=<internal meeting Id>&report=<access token>&lang=<language code>
{CODE}

It would be nice to see a summary of attendance to a meeting, which would help to make meeting notes in use cases in which that document is needed and needs to be written: and recording needs to be played again to catch all attendants to a meeting, and eventually who where just listeners and which ones participated in any form (audio, chat, etc)

This extra information could be linked somehow from the report shown through ((doc:PluginBigBlueButton)) next to the recordings of a room, so that, besides the recording, you could access the log of that LAD.
Storing LAD data could be made optional (like the recording currently is) from within the PluginBigBlueButton in Tiki. If enabled, then the link to display the LAD would be shown next to the recording link, for those users in groups with the perm to see the recording.

Additionally, the bigbluebutton-api-php already has params to control LAD. Example:
https://github.com/bigbluebutton/bigbluebutton-api-php/blob/42e9455db8141176e7f349e64bdb53b1b7e5dfaa/src/Parameters/CreateMeetingParameters.php#L659


Does it make sense?

On a new ubuntu 22.04 aws server apache2 php7.4
Clean build
Installing tiki for first time on this machine
The following is shown on https://mysite/tiki-install.php

Notice: errortracking library not found. This may be due to a typo or caused by a recent update. in /var/www/tiki.squadron6.com/tiki-25.2/lib/tikilib.php on line 88

Fatal error: Uncaught Error: Call to a member function handleError() on null in /var/www/tiki.squadron6.com/tiki-25.2/lib/init/initlib.php:104 Stack trace: #0 [internal function]: tiki_error_handling() #1 /var/www/tiki.squadron6.com/tiki-25.2/lib/tikilib.php(88): trigger_error() #2 /var/www/tiki.squadron6.com/tiki-25.2/installer/tiki-installer.php(217): TikiLib::lib() #3 /var/www/tiki.squadron6.com/tiki-25.2/tiki-install.php(120): include_once('/var/www/tiki.s...') #4 {main} thrown in /var/www/tiki.squadron6.com/tiki-25.2/lib/init/initlib.php on line 104

clean setup first time run of of tiki25.2 php8.1-fpm nginx

Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /var/www/tiki/tiki-25.2/temp/templates_c/en_classic^91f439aaf06630c3b75af65f02a2b0910ea664a7_0.file.footer.tpl.php:117 Stack trace: #0 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_651d975eb4dd85_74914763() #1 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #2 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #3 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render() #4 /var/www/tiki/tiki-25.2/temp/templates_c/en_classic^8bc5c3b8d55e995fd256f4e80ad11e7d885d4a56_0.file.tiki-install_screens.tpl.php(42): Smarty_Internal_Template->_subTemplateRender() #5 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_651d975ea958a1_27233795() #6 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #7 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #8 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render() #9 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute() #10 /var/www/tiki/tiki-25.2/lib/init/smarty.php(472): Smarty_Internal_TemplateBase->display() #11 /var/www/tiki/tiki-25.2/installer/tiki-installer.php(900): Smarty_Tiki->display() #12 /var/www/tiki/tiki-25.2/tiki-install.php(120): include_once('...') #13 {main} thrown in /var/www/tiki/tiki-25.2/temp/templates_c/en_classic^91f439aaf06630c3b75af65f02a2b0910ea664a7_0.file.footer.tpl.php on line 117

Currently, Tiki does not have a feature to lock a specific user account.

Such locks can be essential. E.g. when you created a user account, but the user doesn't use it. For security reasons, you must lock it after a certain grace period. Either automatically or, as a fallback, manually.

Deleting is not a way to do this, because then you delete all preferences, so in order to preserve user preferences, but secure the site, a lock feature is IMHO essential. Admins should have the ability to lock user accounts. Actually this should be a perm of its own "Can lock user accounts", given by default only to members of the Admin group.

As a workaround, an Admin can create a new password (only known by him/her), but I believe a locking mechanism is more elegant. Also it removes the necessity for the user to re-establish his/her password after the lock gets lifted.

In a more sophisticated version, Tiki could inform members of the Admin group if a user that has a lock imposed on his/her account tries to login, that a login attempt was made.

When certain high-level events occur where the internet community wants to express protest, switching a website to show it's content on black is an often used measure.

Most of the time, some message will be displayed additional to the content (or instead of the content).

Therefore I like to propose the following be added to the banner feature: Turn the Tiki black.

It involves much labour to rebuild a CSS to reflect this. This could be automated. So flicking a switch on the banner feature might compile the previous CSS to one temporal CSS in which each and every colour gets inverted.

As most Tikis will render text mainly as mostly black letters on (kind of) white, such a colour reversal would automatically yield white on black, and even let contrast unchanged, so no areas that become hard to read will spring up.

And the deactivation is even easier to implement, simply go back to the original CSS.

Caches should be cleared after CSS manipulation, of course.

{syntax type="tiki" editor="plain"}
After being uploaded it should be possible to categorise ALL files of a Gallery or to select several and categorise them with 1 or 2 clicks.

You can categorise a gallery BUT it will not apply the category change to the inner files of the gallery.
When you are in the gallery you can view the files in the gallery and can select several files to move them, delete them, etc but not to categorise them. This is really missing (after moving image gallery or reorganising a Tiki) as you have to edit one by one the file properties and categorise it.

On the Category Admin side there is not easy way to do this either. You can categorise a Gallery but not the files in it.
You have to search categorise each object one by one. Not humanly doable....

Logged as admin, when you navigate inside the File Galleries you can see the name of the Gallery you are in and close to it a wrench. The wrench tootip let you understand that you will be able to interact with THIS file gallery settings but in reality you are sent to the Admin Control Panel "File Galleries".
https://dev.tiki.org/tiki-admin.php?page=fgal#File%20Galleries

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

This is quite confusing for new Admins.

Once the file gallery batch feature is enabled:
At https://next.tiki.org/tiki-batch_upload_files.php?galleryId=17 at the bottom if you enable "Upload into galleries according to sub-directories" other options are displayed but the design alignment and position of sentence is broken. Col-4 and 8 are over lapping instead of being one next the other.

As the additional options are child of "Upload into galleries according to sub-directories" they should look like child options (indent)

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

When downloading file/files from the file gallery the actual download completes in ~1 second. The File Gallery UI download progress bar still thinks the download to progressing at a slower rate and shows 100% complete after 10 or so seconds.

I'm getting a 500 error trying to upload the screenshot so I'll attach

{syntax type="tiki" editor="plain"}
{img fileId="1787" thumb="box"}
{img fileId="1788" thumb="box"}
{img fileId="1789" thumb="box"}
{img fileId="1790" thumb="box"}

So tested with current master (25.x) and its the same behaviour.
Moving from db to dir works, but lable dont toggle. And pressing it again dont make files disappear in dir so I assume it might be that the function to move gallery items from directory back to database isn't working right now.

So its consistently wrong from at least from 21.x

{syntax type="tiki" editor="plain"}
On next tiki org I tested a bug about Archives and find out that all the new files I'll upload take the same filename and use the same date of the original and first file. (on the video you can see the "real" date is displayed for half of a second.

I really think it used to work properly, displaying the date of the upload of the next versions and the filename of the file (not the label of the file in Tiki).

{mediaplayer src="display1864"}

The general translation behaviour for Tiki features is to allow translations of titles and other labels.
Page title, trackers (title, field names), categories and eventually to allow wiki syntax that allow the admin to set TR tags where it is needed (tracker description, wiki page content, etc...).
But not for Tiki file gallery. ??‍♂️

The translation of term(s) is found in tiki lang/../language.php or lang/../custom.php

Following the discussion in the comments the conclusion is:
1/ There are reasons for this as it may be unwanted to automatically translate terms of a file title (file name on import if none is specified).

2/ To allow translation of file title and file description it will made sense and easier to do it at the wiki plugin level, something like:
{CODE()}
{file type="gallery" fileId="1225" browserdisplay="y" translatetitle="y"}
{CODE}

There is no option to display the file description using the plugin and it is not necessary to add one.

On Tiki 24 when I edit an existing file and try to edit the description it failed.

Reproducible and testable at https://doc.tiki.org/tiki-list_file_gallery.php?galleryId=1726

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

PS: On some other Tikis I tested, changing the file name didn't worked neither. (no error)

At dev.t.o there is now an upload limit for file size set at 8MB.

I tried to upload a 12MB file and Tiki refused/failed to complete the operation.
The output displayed (to the user) look like this:

{img type="fileId" fileId="2044" thumb="box"}

It doesn't the user to correct the problem.
It may seems like a technical problem happens (Tiki is to blame) while this limit is by admin configuration (part of the plan).

It should be something like:
"You tried to upload a larger file than the maximum size permitted.
Please reduce your file size."

If you are admin it could even also display:
"This is a server setting related to your server's php.ini "Upload file size" parameter, see https://doc.tiki.org/Upload-file-size#Upload_file_size to modify your server's php.ini file.

''(word-proofing is required)''

Using Tiki I upload a file and I want to place it in a specific gallery.
Next time I upload a file, I want to "remember" where I uploaded.

Use case; For this tracker I use the img plugin.
# Click on the icon
# Click on the browse gallery icon
# On the explorer path => bug report => bsfez
# Click the upload button
# Drag the file (automatic upload)
# Insert the syntax on the item

Such a simple action than adding an image to an item = 6 clicks !!!
If we didn't used Explorer path and if automatic upload wasn't check it would have been 9 clicks !!!

Video added: {file type="gallery" fileId="2043" showicon="y"}

Articles do not have history. With wiki pages, there is always an undo (and multistage, and with comparison etc.). Articles don't have that, and I believe they should, and it shouldn't be hard to add... The revision system could be shared, or at least recycled, from the one wiki pages have.