Category: 25.x

Wouldn't it be great if a wiki link (the standard [] syntax) would check whether the current user has rights to the page that it links to? THat way we could turn off the hyperlink if the user cannot open the page anyway...THat would add some processing overhead, but I am sure that would be manageable.

Don't know where to begin, though, I do not really understand the wiki processing in Tiki...

When the calendar is in year view, all 365 days are displayed in one horizontal row. A look at the page source shows -+ tbody role="presentation" +- contains -+ tr role="row" +-, which contains many, many instances of -+ td class="fc-daygrid-day fc-day fc-day-sat fc-day-past" +- , not just seven instances for the seven days of the week as is done in the semester view.

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.

You can use Tiki articles in multilingual website having article for several language.
The usual process is to create a main article (default language) then create other articles with different language and assign them as translation of the previous article.
Article => Edit => Advanced, Attach existing article ID as translation

You have to insert the ID of the article and that really not user friendly.

You should be able to retrieve articles by name in a select.

---

On second thought...

If wed really like to improve we could reuse the same interface/system we have with wiki pages (translation) as it is working fine is much better (proposing translation if missing and displaying set of translated documents) and will be better for UX (consistency).
I just wonder if it worth the investment.

On article you can set the image, Own Image and you can set Read Article, Maximum dimensions of custom image in view mode, Width.

If this field had a value and you empty it and save you the article may display a random image.
This because reseting to an empty value broke the linkeage between the article and the previously uploaded image.

It is happening randomly (happened to me twice)

On next we have an article; https://next.tiki.org/article497-Biggest-Tiki-Release-Ever-Tiki-25
''To be sure I can see what is happening with the maximum width available I disabled fixed width''

As you can see on the video, the image displayed width is 555px. (fixed with disabled + 27inch screen)

On article settings (https://next.tiki.org/tiki-edit_article.php?articleId=497#content-edit_article1-4), Read Article: Maximum dimensions of custom image in view mode, Width = 720px.
Visibly (fill-width with a very wide scree) this is not applied.

Demonstrated on next.t.o
{mediaplayer src="display2131"}

''Reviewed with Tiki25''

--If the auto-assign is set to "Creator" and the admin edit an existing item with a null username (creator deleted, error with duplicate feature, etc), the admin username will be assigned and saved. This can happen even if admin doesn't see the field (if he use a modal to modify some preferences or part of the item).--
''Not able to reproduce anymore, may have been fixed''


If the admin duplicate an item that has a another user selected in a user selector field, the new item (the clone) will be saved with the admin for user.

{FADE(label="Instance")}
__Tiki show trunk and Tiki show 24 are not working as expected__ but I could reproduce the bug on a Tiki24 instance:
http://bsfez-11581-7751.show2.tiki.org/tiki-view_tracker.php?trackerId=1

If you want to reproduce you can log as admin/12345 go to the tracker a duplicate an item from a different user using:
http://bsfez-11581-7751.show2.tiki.org/tiki-tracker-clone_item?trackerId=1&itemId=1&modal=1
{FADE}
{img fileId="2021" thumb="box"}

Is it possible to automate the creation of a structure(s) eg( run every night as a cronjob). I really like the keyword concept list and I think this could be deployed as a feature for sites that are drowning in wikipage content and maintaining menus is just too trouble sum.
Is the keyword page auto generated? If you could set a category to include all pages in that category in the auto-maintained structure.

{syntax type="tiki" editor="plain"}
When you create a wikipage its title is available instantly in for example a tracker page selector.
Would it be possible to add/remove a Mathematical Calculation Tracker Field to this system?

When the wiki page contains HTML headings, autotoc fails to display. It doesn't matter if the HTML plugin is used, or if HTML is activated for the page (and the plugin not used), in both cases the content of the page will narrow to make space for the autotoc, but the autotoc doesn't appear. If there is a combination of wiki syntax headings and HTML headings, autotoc will not appear. If there are only wiki syntax headings, then autotoc displays normally.

We have a few boutons, menus and menu-items that are displayed in Tiki while there is nothing doable.

For example at : https://tiki.org/Donation

Some are just overloading the screen.
Some have a very little interest (informative)
Some have an informative value (but a button or an item menu is not the right way)

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

--

Another example is the structure menu displaying __only__ an item for the page I'm on and clicking on it just doesn't do anything but reloading the page. (check as anonymous)

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

It is not possible to change the image banner once one has been uploaded.
See : http://bsfez-11581-7922.show2.tikiwiki.org/tiki-edit_banner.php?bannerId=1
Try to change the banner it shouldn't work.

There is an issue with the image upload.

I tried to understand if it was possible and how to use the tablesorter with tracker filter plugin.

The trackerfilter modal is NOT user-friendly.
Too long list of things the user may not necessarily needed (menu child accordions would definitely help reducing the tremendous amount of information visible there)
The explanation have been copied and pasted as is from another place and hardly make sense.
Fields are not grouped together, naming is not helping (table sorter is hardly if ever found in the options and parameters list or help)... It is a mess and it took me 30mn of test to make a sample visible here : https://doc.tiki.org/PluginTrackerFilter#Trackerfilter_with_table_sorter_setting_to_perform_calculations

We have in Tiki a way to submit and approval Wiki page revisions.
Unfortunately the naming and labelling of things make hard for new coming (and oder) to find documentation and the feature on the Tiki preferences;

Related
*https://tiki.org/forumthread77682-Information-Documentation-on-Tiki-wiki-staging-and-approval
*https://doc.tiki.org/Flagged-Revisions
*https://doc.tiki.org/Wiki-Page-Staging-and-Approval
*https://doc.tiki.org/Wiki+Page+Staging+and+Approval
*https://dev.tiki.org/Flagged%20revisions%20tab
*https://profiles.tiki.org/Staging_and_Approval
*https://doc.tiki.org/Staging-Approving-Group-Category-Permissions
*https://doc.tiki.org/tiki-searchindex.php?filter%7Econtent=staging

We should decide a name for this and use it everywhere.

Currently, the blog feature features only limited information, both for users and for admins.

For users, new blog entries should IMHO be listed in the since last visit module, currently they aren't.

For admins, blogs AND blog entries should be part of the statistics page, currently both aren't, so as admin, you only see the total number of blog page views, and have no clue, which of your blogs is more popular, and inside blogs, which entries generated the biggest audience...

From my understanding and after a discussion with Gary.

Tiki25 is supposed to work with bootstrap 5.2.x
Tiki26 is supposed to work with bootstrap 5.3.x

As discussed in the matrix chat, it seems that setup.sh / composer has been updated to use Tiki26 dependencies.

{CODE()}
Bernard Sfez
I'm setting a theme on a brand new tiki25. (from git)
I'm facing several issues about Undefined variable...

$primary-text-emphasis-dark
$primary-bg-subtle-dark:
...

$min-contrast-ratio: 1.8

I tried to compile as is the tuften them and I have the same errors...

Some collisions between bootstrap5.2 tiki25 and tiki26 ?
---
gary_c-l
Those variables are new in Bootstrap 5.3, to support color modes .../...
---
Bernard Sfez
I see that tuften v25 is different from tuften v26 (variable_dark and others are missing)
---
gary_c-l
Interesting. I'm going to try compiling Tiki 25 Tuften in a Tiki 25 instance here.
gary_c-l
Well, tuften compiles without errors here, in branch 25.
---
Bernard Sfez
... did you run setup.sh ?
It is possible that the vendor package is updated (for bs5.3)
gary_c-l
Yeah, I didn't run setup .sh. The Bootstrap version in vendor is Bootstrap v5.2.2, in my branch 25 instance. Maybe composer isn't configured right, if setup .sh results in having the wrong Bootstrap files for branch 25.
{CODE}

Tiki25 code (composer packages) that is our last stable version should not be changed by Tiki26 requirement.

Tiki25 being the only Stable version between Tiki24 (old) and Tiki25 (unstable) it should be at least working as it was,
---
Below, just after a second fresh install (nothing else was done, not preference changed) I tried to compile an existing theme.
{img fileId="2065" thumb="box"}

Is it a bug or a feature, that truncates the output of strings after a pipe symbol?
Example to illustrate: /lib/prefs/feature, line 2425:
{CODE(Colors="Tiki")}
'feature_wiki_argvariable' => [
'name' => tra('Wiki argument variables'),
'description' => tra('Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}'),
'type' => 'flag',
'help' => 'Advanced+Wiki+Syntax+usage+examples',
'default' => 'n',
'keywords' => 'arg var vars',
],
{CODE}

The output of this descriptions stops at the pipe symbol between paramname and default, supposedly in all languages, including English. I cannot translate into German with this entry in custom.php:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname|standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
but when I replace the pipe with a slash, all is well:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname/standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
So please check whether this is a bug or a feature of tra(), and depending on this check either fix it or change in English this description, to use text without a pipe.

Side remark: The pipe doesn't show here, just as the the arguments in double curly braces! Although I enclosed my code sample in CODE tags! ({sign user="Jyhem" datetime="2022-03-03T14:30:00+00:00"} Arguments are interpreted first before anything else. That's what ~np~~~/np~np~nonparsed~np~~~/np~/np~ is for)

{file type="gallery" fileId="2080" showicon="y"}
Looking at the image you can see there is a weird way of showing the start and end time of the event. There doesn't seem to be a way to show normal start and end time of event.
These events are just coming from a calendar not a tracker etc..

Admin can set the days displayed in Tiki calendar.

It can be set from the calendar admin panel : tiki-admin.php?page=calendar#Calendar
{img fileId="1807" thumb="box"}

It can be set from each calendar edit settings (wrench => edit) : tiki-admin_calendars.php
{img fileId="1808" thumb="box"}

However the days are displayed in the calendar
{img fileId="1809" thumb="box"}


By extension they will be seen as "existing" days for a calendar event created/used with tracker field calendar item.

It is not possible to create or name a page "Sandbox".
If I do there is an error:

{REMARKSBOX(type="errors" title="Error")}The Sandbox is disabled{REMARKSBOX}

I tried to create Mail Accounts in a new Tiki instance and this is failing.
In my local instance it is not possible to add a mail account completely (IMAP + SMTP).
Although I __could add__ and succesfully test two __SMTP__ servers to Tiki webmail, ...

__Update: it worked in show2 ! Bug so far not reproducable. Will try to find a conflicting configuration locally.__

... it is __was possible to add__ the respective __IMAP__ servers and I did not find the related error message. I tried to switch on logging on the server and to display all errors in Tiki, but with both I did not succeed.

It is aswell not possible to add a new mail account. The appropriate 'create' button greys out and Tiki does nothing.

Now I will try to reproduce the error in a show2 instance and report back.
I'll use a temporary test-mail-account, I created on one of our servers.

^Mail = Username
~np~mailtest-mdxbtazct@relatorx.com~/np~

Password
QVrzEVC8NUoCCmAN

IMAP = SMTP
w01c65b0.kasserver.com^

After creating a zone and banner and using pluginBanner they will not display for me

I've followed the doc page to setup record rtc in tiki23 on a linux box (thanks for the documentation)
https://doc.tiki.org/Record-screen-audio-video

I can't succeed at my attempt to use Record RTC since the wiki page gets self-refreshed each time I click at the button to "Start Recording" before I can accept the firefox popup that asks me to grant perm to this page to record/use media or something (I can't read the message properly since the page is self-reloaded too quickly)

I have a valid https now (It was an invalid https in my first attemps)

Reproduced here in dev.t.o

{img src="display1562"}

Among several, there is one very big limitation of the shopping cart:

It cannot handle currencies! I wonder why no one saw this before (and I have to add, when debugging the translation of Tiki, it did not occur to me either). Cart must store the currency linked to all products. The currency of the user must be user-selectable (Of course, at the admin's discretion, the set of available currencies must be limited). We need to modify the data structure. The currency MUST become a separate field, and with that the price becomes strictly numeric (It could and should be discussed if we make that integer in the small currency units, but display it with the decimal comman/point inserted) and the currency should be strictly the three-letter ISO code, but a representation of that could be selectable (€ for EUR for instance).

If user currency and currency of any stock item differ, currencies must be converted. Currency conversion isn't easy. The first and easiest solution is having fixed conversion rates. These MUST be prominently and transparently displayed to the user, as they become part of the contract between the user and the admin/owner of the Tiki. Also, some sort of fee for currency conversion must be selectable by the admin (0 of course being the default), and it, too, must be prominently and transparently displayed.

When fixed rates have been established, the next level of comfort might be automatically set/updated rates. For that, we would have to find a reliable provider. Also, since all providers might for some reasons fail to supply data at any given time in the future, a default minimum and maximum rate must be selectable by the admin.

At first, I thought this could have been overlooked because of a domination by the US, but then it crossed my mind that even Americans have the need for currency conversion, because they got US and Canadian dollars, and when they sell internationally, also Australian and New Zealand dollars...

In Europe it is much more complex. Most countries have the Euro, but not all. Great Britain does not, but now it's not even part of the EU anymore. In the German speaking countries we have Euros (Germany, Austria) and Swiss Francs. Even though Switzerland is also no member of the EU, the fact that a large portion of Switzerland speaks German leads to Swiss users using German Tikis, and vice versa.