Category: Consistency

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)

This line dont work with tiki wiki: * ((Les fichiers d'Exportation (ADX)|Créer un fichier d'exportation (ADX) de la société.)) It's work iust if I remove ()

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

I have yet id3127 id3148 explained the problems of the bug and wishes list.

I returns on the subject :
*before if you were clicking on the column headers, which function is to allow to sort the displayed list, you where generating a crash by an SQL request error.
Somebody have done something.

*Now : When you use this feature the list is simply cleared (if error then return).

Either this tool is without any interest for development or not at all.
If it is without interest it must be suppressed...
if not it must normally function even simply.
Actually the function are very simple but they don't functions.

!!The list sort problem : a display simply cleared...

If it is, anybody can understand that the impossibility to sort a list which is always displayed as playing card poker, makes impossible any revue of a subject.

This is the main problem.

!!Minimum enhancements in my opinion
__A really minimum list :__
*Display the "id" and the "author"
*Display a full date (the day)
*Allow a direct access by the "id"
*Allow selection by check box and display only checked items
*Send by mail the current list
*Optionally send by mail the content of an id

This could allow to check this list...

Trebly

There are also those bugs, whose inner workings look like a miracle to someone who is not familiar with the code.

For instance, I cannot translate "Sticky Popup" from the admin page of calendar. There are two different features by the same GUI (!) name on lines 62 and 826 of /lib/wiki_plugins/wikiplugin_trackerlist.php:

{CODE(Colors="Tiki")}
'stickypopup' => [
'required' => false,
'name' => tra('Sticky Popup'),
'description' => tra('Choose whether the popup tooltip will stay displayed on mouse out (does not stay open by default)'),
'since' => '2.0',
'filter' => 'alpha',
'default' => '',
'options' => [
['text' => '', 'value' => ''],
['text' => tra('Yes'), 'value' => 'y'],
['text' => tra('No'), 'value' => 'n']
]
],

[...]

'calendarstickypopup' => [
'required' => false,
'name' => tra('Sticky Popup'),
'description' => tra('Calendar item popups will stay open if set to y (Yes). Not sticky by default'),
'since' => '6.0',
'doctype' => 'calendar',
'filter' => 'alpha',
'default' => 'n',
'options' => [
['text' => '', 'value' => ''],
['text' => tra('Yes'), 'value' => 'y'],
['text' => tra('No'), 'value' => 'n']
]
],

{CODE}

As you can see, both (!) call the translation subroutine, and both (!) have a description, so that help string should be visible under a blue question mark icon, next to the feature checkbox on tiki-admin.php?page=calendar, but they don't !! And I cannot translate the name, so it shows only "Sticky Popup" and the checkbox, and that's it.

The reason must lie deeper than what I can see in the code by going over it...

And yes, I did check that the space between "Sticky" and "Popup" is really a space (0x20) and not something weird like a shift-space...

Pls see the attachment.

I want to change the colours of buttons. Bootstrap has it's own colors for that (which I do not like), and I seem to be unable to change them. No matter whether I declare them in _variables.scss (which would load before bootstrap.scss - which in turn loads _buttons.scss) or in a separate file that gets loaded after bootstrap.scss, even when declaring them !important, bootstraps own colours always come through. Also, no matter whether I redefine a default colour or one of the dedicated colours like primary etc.

After some googling, this could be a bug in bootstrap. Since Tiki incorporated bootstrap, IMHO it's a Tiki bug now.

{CODE(Colors="Tiki")}
// Buttons
$btn-primary-color: #000000 !important;
$btn-primary-bg: #e7e7a1 !important;
$btn-primary-border: #999970 !important;
$btn-default-color: #000000 !important;
$btn-default-bg: #e7e7a1 !important;
$btn-default-border: #999970 !important;
{CODE}

They all come out, after transpiling, as #2255aa; or #212529; etc.:

{CODE(Colors="Tiki")}
.tiki-webmail .btn-primary, .tiki-cypht .btn-primary, .mobile.tiki-cypht .btn-primary, .inline-cypht .btn-primary {
color: #fff !important;
background-color: #2255aa !important;
border-color: #1c458a !important;
}
{CODE}

At dev on the buttons the light red is the main "call for action", "default action", primary background color button. The dark red is the secondary background color button.

When I edit/create an event in the calendar on dev.t.o at the bottom, this is what I see:
{img fileId="1497" thumb="box"}

Due to the placement buttons and the fact that there is 2 default action (primary color) the preview button seems to be the "default" one. That’s wrong UX.
"Save" should be the first (start - left direction) and only primary, "Preview" and "Copy to a new events" should come after with both secondary colors.

This is the same (worst) when editing a page at t.o (cancel doesn’t look like a "cancel" button, it is secondary):
{img fileId="1499" thumb="box"}

When I edit a tracker item this is what I have:
{img fileId="1498" thumb="box"}

The order is good but "Rename" and "Write together" have wrong colors. They should use the secondary color. (also the Lock button not shown here is primary color).

We should carefully design our buttons for a better UX.
Those elements a critical for new user approaching Tiki and partly explain why people feel uncomfortable and confused with Tiki.

Saying that Tiki is too big and there is too many options is just another way to say that the interface is too confusing. ?

https://uxplanet.org/focusing-on-buttons-e31d575953bd
https://courseux.com/best-practices-for-buttons-the-user-experience-of-colors/

I have installed TikiWiki 3rc1 on an IIS (Windows Server 2003) installation with PHP 5 and MySQL. This is a root-level installation. For some reason having to change PATH_TRANSLATED to SCRIPT_FILENAME in line 31 of lib/setup/tikisetup.class.php, which if I don't do I get errors relating to directories not existing and the site not loading at all; this is not the purpose of the support request.

Once I make these tweaks, as well as after setting the tweaks identified in tiki-filter-base.php (that is, changing forward slashes to double-backslashes in quotes), I get the site up and running. ***But*** on administration pages, the buttons created by lib/smarty_tiki/function.button.php (such as "CLEAR CACHE" on the Modules admin page) don't seem to work when accessing the site from Safari or Firefox (Internet Explorer works fine for this).

Instead, in Safari, the clicking on the button will load the script name where the domain name is supposed to go; if my site was on http://site.com/somescript.php?something, it would load http://otherscript.php?something. I don't have my machine handy, so I can't get the Firefox results up at the moment, but IIRC they involved the format http://site.com/\/otherscript.php?something (with a backslash and forward-slash inserted).

A Linux installation of TW3 works fine in Safari and Firefox, so my guess is that it's an IIS issue that has something to do with backslashes and root-directory determination, but I'm somewhat clueless here. I've examined lib/smarty_tiki/block.self_link.php and some tweaking there has produced no viable results.

Also note that this goes away when TikiWiki 3 is placed into a non-root directory; it only affects a root installation at /, rather than at a server subdirectory.

{syntax type="tiki" editor="plain"}
Fact : when you submit "preview" for a new event, a great part of data are lost, there is no real preview, and when you return to creation most of optional data are lost.

Too many things don't function : the job is not ended.

{syntax type="tiki" editor="plain"}
The fact (analysis result) : view from the popup od calendar module has no data set up

Details :
When you actions the into modules calendar the event from a date, you get the popup (if prefs) which shows the events of the day, then :

1- there is no choice for an event if an alone or several
2- the data of the event are not set up
3- the action button "view" shows a "pseudo empty event" the lonely data are the default value for a new event...

The function is not completely implemented. Job not ended. Functionality not operational.

It had no time to look at 6.0.

Calendar allows for event end to be before event start

also when asked for duration it asks for a time not an amount of time.

Sorry - these patches were committed quite a while ago - just forgot to close the item

-------------------------------------------------------------------

I have recently started to use the Calendar function in a new v2.2 site and I found a number of illogical/inconsistent functions that I changed by simply editing the .tpl files. I think some of these are sufficiently useful that I'm submitting them as patches - I'm not really set up to do the whole SVN/developer thing at present.

Here is a summary of the changes/adaptations

__tiki-calendar.tpl__ - original source {* $Id: tiki-calendar.tpl 13045 2008-05-29 07:07:56Z chibaguy $ *}
# logic changed so that Config/Options button is ONLY shown if the user is the admin
# logic changed so that Add Event button is only shown if $displayedcals|@count >0


__tiki-calendar_calmode.tpl__ - original source ?not shown?
# explicit ~np~%d/%m~/np~ used for day/month on each day 'cell' to show European style of date. This is just an interim patch to change the existing 'hard coded' version which shows ~np~%m/%d~/np~. It should be possible to change the logic to extract the right format from the General Admin time/date settings - am still looking at this
# logic changed for additional check to NOT show 'add event' in day cell icon if no calendar 'visible'


__tiki-calendar_nav.tpl__ - original source ?not shown?
# swap ~np~%B %e~/np~ to ~np~%e %B~/np~ in several lines in the "calnavigation" div - again to adopt a European style. Still looking to see how this can automatically extract the right info from the general Admin time/date settings

Calendar output (through the 'upcoming events' plugin) uses two differing formats for date output, ignoring the pref:

* Events spanning a whole day are output numerical, example: "03.02.2022".
* Events with beginning and ending at specific times are reported with weekday, but without year . Example: "Montag, 07. 02". Note the missing full stop after the month!

So factually dates are output (whole day) formatted as (strftime())
{CODE(Colors="Tiki")}
"%d.%m.%Y"
{CODE}
and with specific times formatted as (strftime())
{CODE(Colors="Tiki")}
"%A, %d. %m"
{CODE}

The pref (long date format) is set to
{CODE(Colors="Tiki")}
"%A, %e. %B %Y"
{CODE}
The pref (short date format) is set to
{CODE(Colors="Tiki")}
"%Y-%m-%d"
{CODE}
(the Japanese format, which has the beauty of automatically sorting alphabetically in correct order, because the most significant digit is on the far left).

So the output is both inconsistent AND violates the setting in the pref...

strftime() constants:
https://www.geeksforgeeks.org/php-strftime-function/

The calendar feature does display the range it displays (I would like to be able to disable that, but that's minor. Perfect would be if I could disable to display of the year, or to disable the range in total. I find it to be redundant, because the calendar itself already displays that).

What's not so minor is that the dates shown there do follow the date display options of the Wiki, i.e. here in Germany date is followed by month.

But they are separated by slashes, which is not correct. It should be dots, and that is what is set in the preferences. All other date displays are correct (like the date of the last revision of a Wiki page), but calendar does not follow that rule.

Thanks
hman

{syntax type="tiki" editor="plain"}
When logging in and choosing calendar the upcoming events (selected to be shown on the right column) are visible, but are not visible in the calendar (table or graphical view) in the calendar view.

After editing and saving (without changing) an event, the event is and remains visible in the table or graphical view of the calendar. However after closing the browser and logon again the same problem returns.

{syntax type="tiki" editor="plain"}
After upgrade from 2.4 to 3.0 the MyTiki Mini Calendar no longer displays the very useful Caldendar-filter (small simple calendar interface). Otherwise the minicalendar feature works well.

I have done two fresh builds of Tiki 3.0 using "The News" theme.
In each build I have confirmed that the miniature, monthly-calendar
that appears under the heading "Calendar Filter" within the
personal calendar feature under MyTiki is missing. It's a handy
little calendar to have. I have been unable to determine what
php or javascript file creates this little gem. It would be nice
to have it back.

The calendar uses, when a new event is entered, a jquery date picker tool, to be precise it calls vendor_bundled/vendor/jquery/jquery-timepicker-addon/dist/index.html.

In this file I cannot find any localization tr() or tr in curly braces at all, thus all texts displayed like "Time" "Hour" and "Minute" are translated in no local language at all...

{syntax type="tiki" editor="plain"}
When I create a tracker, say trackerId=6, and populate it with a few items in a fieldId, say fieldId=10, and then go to a different tracker, say trackerId=7 and create a field of type "Item Link", with options 6,10 it works as I would expect. In particular, I am presented with a drop-down of the items in tracker 6, field 10. If I save an item using this drop-down in tracker 7 and try to then edit that item, the drop-down is blank.
In summary, the tracker type "Item Link" works as I would expect when adding items to a tracker, but does not work when attempting to edit the items in a tracker. When editing, the drop-down is blank.

{syntax type="tiki" editor="plain"}
Can't create a forum as a registered user. There is simply no button, unless you have administrative rights over the forum

While creating a new tracker in 1.10 error occurring.

An error occured in a database query!

Context:
File tiki-admin_trackers.php
Url tiki-admin_trackers.php
Query:
insert into `tiki_trackers`(`name`,`description`,`descriptionIsParsed`,`created`,`lastModif`) values(?,?,?,?,?)
Values:
0 daaku
1
2 NULL
3 1213325032
4 1213325032
Message:
Unknown column 'descriptionIsParsed' in 'field list'
Built query was probably:
insert into `tiki_trackers`(`name`,`description`,`descriptionIsParsed`,`created`,`lastModif`) values('daaku','',NULL,'1213325032','1213325032')

In database couldn't find 'descriptionIsParsed' field. Is it missed ?

If you write in a wiki page the following code:
~np~[http://website.com|~~#FF0000:Site~~]~/np~

Your link will not be colored as it should.

This has been tested on 1.9.7 and 1.9.10.1

It should work as with wiki links.

When an Admin or a Group Member who has permissions to upload/view/edit files in specified file galleries, uploads a file to a gallery, they themselves and other non-admin users cannot view the file.

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}

This is the case even if {if $tracker_info.showStatus eq 'y' or ($tracker_info.showStatusAdminOnly eq 'y' and $tiki_p_adm
in_trackers eq 'y')} is true.

In order to fix this I can think of 2 options:

option 1) have the status selector there in the edit/insert popup.

option 2) have on the tracker item view screen another button to toggle the status, depending on the perms the user has. Surely the user should only be able to change the status to statuses he has perms to view, right?

I actually like option 2 as it provides a separate tracker status switcher apart from the editing but that's just my opinion.

When you go to Products (the main shop) and click on a product, you get the products's page (Product), but that does not have a backlink to Products. Ideally it should backlink to the Products page that lead there (could be paginated), but a generic backlink to Products would be sufficient. This breaks the user experience that the backlink arrow leads back to all pages that linked to the current one. The browser's back button, of course, still works.

(CART is missing in the drop-down menu to indicate the feature to which this bug report relates to).

The localization of CART seemingly stopped right in the middle? Half of the GUI is localized, the other half is still in English.

That's no problem for me, but might be for others. And it's just inconsistent.

Also, some dialogs seem to be hardcoded in English, and remain in English even when the Wiki is set to, for instance, German: "No outstanding payments found" in the main screen of payments...

Thanks
hman